GNOME Bugzilla – Bug 271482
Move component selection button preferences from menu to the Edit->Preferences dialog.
Last modified: 2021-05-19 11:37:12 UTC
In Evolution 2.1.3.1 there is a submenu: "View->Window Buttons" containing radio menu items for configuring how the component selection buttons should appear - Text & Icons, Icons only, Text only, Toolbar style plus a toggle to make them invisible. Should this really be in the menu? It feels like a rarely-changed user preference to me, and hence I think it should go into the Edit->Preferences dialog, perhaps a new "General" page (since "Shell" is probably a word that isn't meaningful to the average end-user).
in 2.3.7, it's in "view | windows" which is quite good i think.
forget my last comment, you're totally right. in order to destroy the UI component (as discussed with jpr, dobey, and nags), changing component to shell and reassigning. adding usability keyword. developers please reassign appropriately if necessary. adding dependency.
Bumping version to a stable release.
Same goes for "View->Switcher Appearance", yeah? Is there still interest in this or is the Preferences window already too crowded? I'm in the midst of rewriting the shell, so now's the time.
(In reply to comment #4) > Same goes for "View->Switcher Appearance", yeah? I guess so. > Is there still interest in this or is the Preferences window already too > crowded? I'm in the midst of rewriting the shell, so now's the time. Current situation: View [...] Layout Show Tool Bar Show Status Bar Show Side Bar Switcher Appearance [...] [...] A proposal: [...] Layout Show Tool Bar Show Status Bar Show Side Bar Show Switcher [...] In this proposal the Switcher can allow just one style (and not the current choice between three styles, or is it four styles?). Which style that should be is another question. (However, since the Switcher is not a Toolbar (or "Tool Bar"?), the "Toolbar Style" looks like a bad choice.)
This is good. Note that I recently copied the vertical view feature from Mail to Contacts, Memos and Tasks. So maybe we should merge the View -> Preview menu under Layout as well? Something like: [...] Layout [x] Show Preview <--+ [x] Show Tool Bar | [x] Show Status Bar | [x] Show Side Bar | Not shown in Calendar since [x] Show Switcher | there's no preview panel. ------------------- | (o) Classic View <--+ ( ) Vertical View <--+ The "Classic View" and "Vertical View" items should be disabled when the preview panel is hidden, since the two modes are indistinguishable without it. I don't want to ditch the switcher style options completely since that's the first thing a lot of users customize, if they don't hide it altogether. What we could do though is move the options to a right-click menu on the switcher itself. Kind of hidden, but still fairly discoverable.
Another interaction is unchecking "Show Side Bar" should disable "Show Switcher". But Evolution (especially the mailer) is pretty useless without a side bar, other than for maybe the most basic of use cases. Is "Show Side Bar" worth keeping?
(In reply to comment #7) > Another interaction is unchecking "Show Side Bar" should disable "Show > Switcher". I forgot that. > But Evolution (especially the mailer) is pretty useless without a > side bar, other than for maybe the most basic of use cases. Is "Show Side Bar" > worth keeping? I think it's pretty useless without a side bar too, so I guess "Show Side Bar" is not worth keeping. Note that "Show Side Bar" is global, though the side bars for the different components are differ quite a lot. (Also note that "Show Preview" is local to each component.)
(In reply to comment #6) > Note that I recently copied the vertical view feature from Mail > to Contacts, Memos and Tasks. So maybe we should merge the View -> Preview > menu under Layout as well? Something like: > > [...] > Layout > [x] Show Preview <--+ > [x] Show Tool Bar | > [x] Show Status Bar | > [x] Show Side Bar | Not shown in Calendar since > [x] Show Switcher | there's no preview panel. > ------------------- | > (o) Classic View <--+ > ( ) Vertical View <--+ > > The "Classic View" and "Vertical View" items should be disabled when the > preview panel is hidden, since the two modes are indistinguishable without it. Should that be a separate issue? Anyhow: 1) "Show Preview" should be the fifth item (so the first four items are the same for all components) 2) What is the background of the "Classical View" and the "Vertical View" options? Why is this choice needed? (I only use Classical View.) > I don't want to ditch the switcher style options completely since that's the > first thing a lot of users customize, How do you know? > if they don't hide it altogether. What > we could do though is move the options to a right-click menu on the switcher > itself. Kind of hidden, but still fairly discoverable. Why was it actually decided to make it configurable in such detail? How many lines of code are used to make this configurable in such detail?
(In reply to comment #9) > 1) "Show Preview" should be the fifth item (so the first four items are the > same for all components) Good point. > 2) What is the background of the "Classical View" and the "Vertical View" > options? Why is this choice needed? (I only use Classical View.) Some users (including my boss) highly prefer the vertical view. It's especially nice for wide-screen monitors and the feature has been requested several times for the other components (which is now fulfilled). Earliest reference I could find in the archives dates back to 2004. Even then most other popular mail programs already supported it. http://lists.ximian.com/pipermail/evolution-hackers/2004-August/004178.html > How do you know? Talking to and watching people. Several Red Hat desktop team members use Evolution and I often try to sit next to them in meetings and spy on their usage patterns. > Why was it actually decided to make it configurable in such detail? How many > lines of code are used to make this configurable in such detail? Because screen space in PIM applications is very valuable and a lot of users prefer icon-only switcher buttons (or hiding them entirely and using shortcut keys) to maximize side bar space. The code to implement this is a lot simpler than it used to be. It's all pretty much self-contained in the EShellSwitcher widget: http://git.gnome.org/cgit/evolution/tree/shell/e-shell-switcher.c
(In reply to comment #8) > Note that "Show Side Bar" is global, though the side bars for the different > components are differ quite a lot. (Also note that "Show Preview" is local to > each component.) That's another good point. Best leave "Show Side Bar" alone for now, I guess. Instead of "Show Preview" we could use "Show Mail Preview", "Show Task Preview", etc. to help clarify that it's not global like the other options are.
(In reply to comment #11) > Best leave "Show Side Bar" alone for now, I guess. Why? Can't it just always be shown? > Instead of "Show Preview" we could use "Show Mail Preview", "Show Task > Preview", etc. to help clarify that it's not global like the other options are. So, to summarize and to move things forward, my current suggestion is: View [...] Layout [x] Show Tool Bar [x] Show Status Bar [x] Show Switcher ------------------- [x] Show $COMPONENT Preview [(o) Classic View] [( ) Vertical View] Switcher sub-options in a context menu and/or in Preferences? Not sure ... (Above the separator is global, below is local to each component.)
Not sure about ditching Show Side Bar yet. I'll have to think on that. I like how you grouped the preview checkbox with the preview style options. Could we also do that with switcher style options? View [...] Layout [x] Show Tool Bar [x] Show Status Bar ------------------- [x] Show $COMPONENT Preview (o) Classic View } Disabled if checkbox ( ) Vertical View } is unchecked. ------------------- [x] Show Switcher (o) Icons and Text } ( ) Icons Only } Disabled if checkbox ( ) Text Only } is unchecked. ( ) Toolbar Style } I'm also warming up to the idea of converting the Layout submenu to a Customize Layout menu item that opens a nicely designed dialog with all these options, and everything is instant-apply. The Preferences dialog is already overcrowded so I'd be opposed to adding anything more to it. I'm already looking for clever ways to de-populate it and integrate the options where they make sense.
*** Bug 560726 has been marked as a duplicate of this bug. ***
So I tried implementing comment #13 tonight with mixed results. It helps to actually see the thing running. Some observations: - The View menu looks much cleaner. I like that. - The preview options should come last since they're not always present. - The radio items are calling out to be indented further so they're more strongly associated with the checkbox, like you would see in a dialog. There's no way to do that with the stock menu item widgets so I'd have to write my own. (Is is worth it?) - "Classic View" and "Vertical View" need reworded. I tried to come up with "Below..." and "Next to..." items but got stuck on what to call the area the preview is below or next to. Message List is fine, but Memo List and Task List is slightly overloaded, and Contact List is -really- overloaded to the point of confusion. Not sure where to go from here. Clearly this stuff belongs in Preferences but I really feel like Preferences is just too overcrowded to accommodate it right now. I'm not as fond of the unified Layout menu as I thought I'd be, and my stand-alone dialog idea would work but feels kind of ad-hoc. We're -years- overdue for a Preferences redesign, and I think solving this bug correctly is blocked on that redesign.
Created attachment 149885 [details] [review] Unfinished patch Just so you can see what I'm seeing, here's my unfinished patch. It implements the unified Layout menu but stops short of renaming all the menu items we talked about.
Thunderbird 3.0 uses the same terms: "Classic View" and "Vertical View" (and "Wide View" for the message pane to have full screen width).
(In reply to comment #15) > Not sure where to go from here. Clearly this stuff belongs in Preferences but > I really feel like Preferences is just too overcrowded to accommodate it right > now. [...]. > > We're -years- overdue for a Preferences redesign, and I think solving this bug > correctly is blocked on that redesign. I can't argue against the need for a Preferences redesign: that redesign is simply needed. But could little HIG deviations and/or outright GUI bloopers in related areas still get fixed as long as that redesign isn't yet done?
(In reply to comment #15) >I'm not as fond of the unified Layout menu as I thought I'd be, and my > stand-alone dialog idea would work but feels kind of ad-hoc. An example: the browser I'm editing this in now (Firefox 3.5.x) uses this structure: View Toolbars [x] Navigation Toolbar [x] Bookmarks Toolbar --------------------- Customize... [...] Customize... launches a dialog that allows one to customize those tool bars. That dialog is not without its flaws, but the main idea itself seems sound: use a single purpose dialog to simplify a (sub) menu. What are the reservations about uisng a stand-alone dialog here?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.