near Koblenz, Germany
Free software hacker, Emacs addict, hobbyist beekeeper and chicken farmer
Comment by ~tsdh on ~tsdh/swayr
I think it wouldn't take much, probably a good first-contribution task.
The difference to the
pactlandwpctlmodules is that those audio modules control some default source and sink but there is no default output (display) to control the brightness of. So I think it would be sensible to add one instance of a futurebrightnessctlmodule per display you use. If the display of one such module isn't plugged right now, it'll just return the empty string, otherwise the brightness value. Then you can define different on-click-behavior per instance to change the brightness of a certain display.That said, I think you can already use the generic
cmdmodule to achive what you want to do. But of course, a custom module which works out of the box would be nice.
Comment by ~tsdh on ~tsdh/swayr
Ah, indeed, one thing I missed is that when the display string ends in this
\0icon...thingy, then the uniquifying number has to go before the icon escape sequence. Should be fixed now.
Comment by ~tsdh on ~tsdh/swayr
Tassilo Horn referenced this ticket in commit f03a0fb.
RESOLVED IMPLEMENTED RESOLVED IMPLEMENTED
Comment by ~tsdh on ~tsdh/swayr
I've implemented that, please test.
Note that it doesn't add the sway con ID to uniquify textually identical choices but just an increasing number. The reason is that the switcher function is generic: it might be used to choose a window, a swayr command, a swaymsg command, or something else. The list of items to choose from just have to implement a certain trait which is very simple but doesn't allow poking in the details of each concrete type.
Comment by ~tsdh on ~tsdh/swayr
Tassilo Horn referenced this ticket in commit d74355b.
REPORTED RESOLVED IMPLEMENTED
Comment by ~tsdh on ~tsdh/swayr
No, thank you. I don't think it's worth it to add so much complexity for a few reasons.
- As you say, it's only supported by few pickers whereas the current variant is the absolute minimum requirement one can have with a picker and therefore works with all of them.
- It provides a likely way to shot yourself in the foot, i.e., the new setting
menu.index_modewould need to be in sync withmenu.args. That is, if and only if you want to use this new index-mode with fuzzel, you need to make sure that"--index"is inmenu.args.- Being able to omit the
{id}(the so-called con id in sway parlance) in formats doesn't strike me as important. Depending on the picker you use, you might be able to make that text invisible, e.g., using pango markup with wofi.- You can already omit the
{id}in your formats and it will be fine except in the edge case where you have many windows of the same application with the same title on the same workspace. But that would be problematic with your approach, too, in that the user cannot distinguish between those windows.What could work without any complex changes was dynamically adding some sequence number to what's displayed in the picker only in the case that multiple candidates have the very same display string. For example, say you have 3 foot terminal windows with the same title
~, those would be displayed in the picker as:
~ -- foot~ -- foot 2~ -- foot 3Would that be fine, too?
enhancement added by ~tsdh on ~tsdh/swayr