Relocate contextual toolbars into the preview panels, part 2
This is a follow-up to issue #2140 (closed).
There are a couple of issues here, that make it for a bad "default" (out-of-the-box) user experience... now we accidentally have three toolbars, as observed in 3.47.1 on the Fedora 38 beta, as per the default UI layout the app presents (I checked by resetting the ui-related gsettings using dconf-editor):
Here are my suggestions of what to fix:
- The old secondary toolbar (
org.gnome.evolution.shell toolbar-visible
) should really be disabled automatically/by default, in favor of the in-preview-pane toolbar being enabled by default. - If GUI config options remain for these, they should be mutually exclusive, maybe using a radiobuttons group or combobox rather than checkboxes; it does not make sense to have both at the same time. For brevity I won't reiterate the various theoretical scenarios here as they've been discussed in #2140 (closed) already.
- When the preview pane is present and shows this toolbar:
- When the preview pane is in "Classic View" layout mode (below the messages list), since there is plenty of horizontal space, the headerbar's Reply/Reply-all/Forward buttons should be moved there (as Milan heard complaints about those buttons being too far from the message when present in the headerbar only). And since that view layout has plenty of horizontal space for that toolbar, it could show labels on a couple more buttons (such as Delete, maybe Archive, etc.)
- When the preview pane is in "Vertical View" (aka widescreen) layout mode (on the right of the messages list), while technically you could still rip out the Reply/Reply-all/Forward buttons and stuff them all in there... I would like to suggest that you instead leave those in the headerbar, hide them from the in-previewer toolbar, and enable labels on the other buttons of that in-previewer sub-toolbar instead. That way, you would make the best use of the limited horizontal space while still being to show some labels for an additional few important buttons (such as Delete, maybe Archive, maybe Load images... see also issue #2295 !)
- Please also apply this toolbar relocation concept to the non-email modules (contacts, tasks, memos), for consistency, as those would be much more straightforward (less buttons anyway) and the space savings would be significant. The only exception, I would say, would be the calendar (which does not have a preview pane to put the toolbar into and has many buttons, so it's still worth showing its traditional toolbar below its headerbar)
- When a message is displayed in a standalone window (instead of the previewing panes), it could probably always display the toolbar no matter what the user stored setting is, because the traditional vs contextual toolbar location would be identical in that case.
Here's my previous mockup for what the change would look like in the tasks component/view:
Thanks
Edited by Jeff Fortin