In pickers the window ID is only there for Swayr's benefit-- it is visual clutter for the user, but there's a way to remove it.
A number of pickers support an "index mode" that returns the index of the item selected rather than the text selected. The feature exists for tools like swayr to build more attractive menus. It would be used like this:
Here's the syntax to use the feature in some common pickers:
Bemenu and wofi don't seem to support this option.
The current behavior can remain as option for pickers without index mode.
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?
Thanks for the reply.
Your suggestion to include an ID only when necessary to uniquely identify a window would also be welcome and would address the goal in most cases.
Good idea!
Tassilo Horn referenced this ticket in commit d74355b.
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.
I have tested this, and can't confirm that it is working as intended. I used this window format and then tried the window switcher:
window_format = "{app_name:{:<11.11}} “{title:{:<60.60}...}” on {workspace_name:{:<13.13}}\u0000icon\u001f{app_icon}"I then carefully made sure I was using the newly built binaries and restarted the swayrd service.
I launched two fish shells in terminals on the same workspace and confirmed that they had the same string displayed my picker, Fuzzel-- I expected one of the entries to have the unique string added to them, but neither one did.
Tassilo Horn referenced this ticket in commit f03a0fb.
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.
Tested to work now. Thanks!