tray: order unconfigured items alphabetically, log item keys - #5297
Open
Carltoffel wants to merge 1 commit into
Open
tray: order unconfigured items alphabetically, log item keys#5297Carltoffel wants to merge 1 commit into
Carltoffel wants to merge 1 commit into
Conversation
Two gaps around tray ordering, both from Alexays#4162. Ordering is only deterministic for items that appear in "orders". Everything else keeps the order in which the applications happened to win the race to register on D-Bus, which differs between restarts and even between the outputs of a single bar. To get a stable tray today you have to enumerate every item with an explicit integer, including the ones you do not care about. Sort items sharing an order value by their key instead of leaving them at insertion order. Items with no entry in "orders" all sit at 0, so they end up alphabetical between the negative and the positive ones, and the default layout is stable without any configuration. The second gap is that the key an item is addressed by is invisible. It is the SNI Id, or the lowercased tooltip for Chrome-based apps whose Id is not unique -- so the key for Rocket.Chat is "Rocket.Chat_status_icon_1", which nobody guesses, and there is nowhere to look it up. Log it once per key at info level, and document both the keys and the default order in the man page. Item::sort_key holds the key, deduplicated from the icon id because the two are only incidentally the same string.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #4162.
Two gaps around tray ordering.
Ordering is only deterministic for configured items
orderspins the items you name. Everything else keeps the order in which theapplications happened to win the race to register on D-Bus, which is what #4162
is about — it differs between restarts, and as noted in that thread it differs
between the outputs of a single bar, so two monitors show two different trays.
To get a stable layout today you have to enumerate every item with an explicit
integer, including the ones you have no opinion about.
This sorts items sharing an order value by their key instead of leaving them at
insertion order. Items with no entry in
ordersall sit at 0, so they end upalphabetical between the negative and the positive ones, and the default layout
is stable without any configuration at all.
The key an item is addressed by is invisible
ordersandiconsaddress an item by its SNIId, or by its lowercasedtooltip for Chrome-based apps whose
Idis not unique. Neither appears anywherein the UI, and the man page only said "name of item" — so configuring Rocket.Chat
means guessing
Rocket.Chat_status_icon_1.Log it once per key at info level:
Deduplicated on purpose: every bar runs its own
Hostwith its ownItemobjects, so an unguarded line fires once per output, and again on every
Idproperty update.
The man page gets a section documenting both the keys and the default order.
Notes
Item::sort_keyholds the key separately from the icon id. The two are onlyincidentally the same string — the icon id is what gets looked up in
icons,and tying the sort order to it would mean an icon config change silently
reshuffles the tray.
No new config options.
Testing
Against a live tray with six items (gammastep, nm-applet, Telegram, and three
Electron apps):
ordersat all →Claude_status_icon_1,gammastep,nm-applet,Rocket.Chat_status_icon_1,TelegramDesktop,vesktop_status_icon_1{"gammastep": -5, "nm-applet": 10, "Claude_status_icon_1": 20}→ gammastep,then the alphabetical remainder, then nm-applet, then Claude