EShellHeaderBar: Show button labels adaptively
The CSDs/headerbar-based UI layout that landed in Evolution 3.46.x is a good step forward, though we all agree it can be refined a little bit to bring the best of both worlds into it. Besides needing to relocate the contextual toolbar buttons to their right context (issue #2140 (closed)), there is the question of button labels in a constrained space.
Indeed, Evolution used to have visible labels for most of its toolbar buttons when they were all on one line, and that was still the case in the original implementation of headerbars in @gnumdk's !108 (merged) ; however, in issue #2022 (closed) it was pointed out that the "labels on every button" approach caused problems with verbose languages and small screen resolutions, so they were then removed in favor of icons-only buttons.
However, I believe it is possible to do better, with a UI that detects if there is enough available screen space for some those widgets to have labels or not. And we could make it happen in "tiers", i.e. the most important buttons could get labels first, then if enough space still is available the 2nd tier of buttons could get labels, and so on; if only a tiny amount of space is available, only the most important buttons would get labels, until the window gets sized wider.
Usually this has been seen in libAdwaita applications, but this is technically not required (if you prefer to not require/use that library), it is entirely possible to do app-side. As far as I know, GTK allows you to query it for the space a widget would take, etc. At least, we did manage to do that in GTG with GTK3 (this was the pull request, and this is the state of the file as of the 0.6 release where it had some fixes applied on top).
Here are the button adaptive "tiers" I would recommend, based on the needs of non-technical users I regularly support.
Mail component
- New message, Reply, Forward, Delete (reply vs forward are super confusing because they're just arrows so it's hard to differentiate)
- Group reply
- Archive, Show images, Mark as spam/not-spam
- Print (even though I hate this button, old-timers around me like to print things)
Notice that the "Send/Receive" headerbar button is not among those 4 tiers of "labelling depending on the available space" list. That's because I consider that feature to be very much "corner-case" and used by a specific niche of users (most folks have automatic email checking, and IMAP IDLE/push support, so the emails effectively come in near-instantaneously as they are received by the server, or otherwise within a few minutes), and those who use Send/Receive for some very specific needs will tend to be more technical users who can find that button and recognize it with the GtkTooltip even if it doesn't have a label, or use the F12
keyboard shortcut.
There are some buttons that I'd actually recommend removing entirely from the toolbar in the main window, too:
- Previous (
<
) and Next (>
) when the message preview is embedded in the main window, because users can already click the message they want in the list of messages or use keyboard shortcuts to navigate; I think it only makes sense to show those arrow buttons in the toolbar of an email shown as a standalone window if the message preview pane is disabled. - I'm not sure how much the "Stop" button is useful/relevant, since there are individual stop buttons for every operation happening in the statusbar already; if it is about stopping a global refresh triggered by the "Send/Receive" button (or
F12
) then it would make more sense for that button to be temporarily shown instead of the Send/Receive button, and then revert to the Send/Receive button when the operation is completed.
Addressbook/Contacts component
- "New contact"
- "Delete selected contact"
I'm honestly not sure how relevant the Print button is for contacts in this day and age, nor the stop button in that component. Couldn't the Print button there be delegated to simply the menubutton (which already has File > Print...
), and the Stop button be removed (since it already is available for the statusbar items anyway), allowing the "Delete selected contact" button to be moved to the headerbar and getting rid of the secondary toolbar in the Addressbooks module, since it eats so much space for so few buttons?
Particularly if the Stop button can be removed there, the alternative is to put the Delete and Print buttons inside the selected contact's preview pane (like what is proposed in issue #2140 (closed)), instead of on a toolbar that spans the entire width of the window and wastes precious vertical space.
Calendar component
- "New appointment"
- "Today" button
The rest of the toolbar buttons already have labels.
Again I'm unsure the Print and Stop buttons are actively used by the userbase, but I guess we could leave them there as icons-only buttons, since that secondary toolbar already has enough buttons to justify the continued existence of the toolbar. I would suggest at least moving the Print and Stop buttons to the end of the toolbar (after a separator) instead of keeping them at the beginning of the toolbar, because they're really rarely used compared to the rest.
Tasks component, and Memos component
- "New"
- Cut/Copy/Paste buttons on the secondary toolbar could probably all have labels, as there's lots of space