GNOME Bugzilla – Bug 760520
Reorder items in Mail Show: combo box
Last modified: 2016-02-02 11:53:12 UTC
In some circumstances, e.g. when Evolution fills the screen and the currently selected category is low on the drop-down menu (such as Important) when the user wants to select a different category from the Show menu the drop-down is partly off-screen and needs to be scrolled to select one of the principal entries, including All Messages and Unread. Possible solutions would be one or more of: 1) Redesign the menu layout to put the most-used selectors at the bottom. 2) Collapse the labels into a sub-menu. 3) Allow keyboard shortcuts for the main selectors. If this is too difficult, a good compromise would be a keyboard toggle between Unread and the currently selected category.
Thanks for a bug report. The menu placement is fully up to the gtk+, evolution doesn't influence it, not with the Show: filter. I think you filled a different similar bug report already, or it was mentioned only on the evolution-list? I realized that moving labels into a sublevel might not work well, thus I reordered the list in a way that it is now: All Messages Unread messages Read Messages ------------------------- Last 5 Days' messages Messages with Attachments Messages with Notes Important Messages Messages Not Junk ------------------------- No Label <generated list of user labels> Created commit a6985cc in evo master (3.19.90+)
(In reply to Milan Crha from comment #1) > Thanks for a bug report. The menu placement is fully up to the gtk+, > evolution doesn't influence it, not with the Show: filter. > > I think you filled a different similar bug report already, or it was > mentioned only on the evolution-list? I basically copied the BZ report to the list. > I realized that moving labels into a sublevel might not work well, thus I > reordered the list in a way that it is now: > > All Messages > Unread messages > Read Messages > ------------------------- > Last 5 Days' messages > Messages with Attachments > Messages with Notes > Important Messages > Messages Not Junk > ------------------------- > No Label > <generated list of user labels> > > Created commit a6985cc in evo master (3.19.90+) That could work (because the most used options, at least for me, are close together) but I won't know till see it in action, which could take a while as I use the Fedora packaged version. It occurs to me that these selection criteria are not necessarily orthogonal, e.g. it could make sense to want to select Unread Messages with Attachments from the Last 5 Days that are labelled Important. That would mean using tick boxes rather than the current drop-down. Maybe something to consider.
(In reply to Patrick OCallaghan from comment #2) > I won't know till see it in action, which could take a while > as I use the Fedora packaged version. True, it's 3.20.x material, thus Fedora 24. > It occurs to me that these selection criteria are not necessarily > orthogonal, e.g. it could make sense to want to select Unread Messages with > Attachments from the Last 5 Days that are labelled Important. That would > mean using tick boxes rather than the current drop-down. Maybe something to > consider. Use advanced search for it, and eventually save it. Most easily (in sense of typing and clicking) can be used with Free Form Expression search, where you can put all things together with the and/or conjunctions. See bug #550796 comment #10, where [1] redirects right now (the Advanced Users notice there). [1] https://help.gnome.org/users/evolution/stable/mail-searching.html.en
(In reply to Milan Crha from comment #3) > (In reply to Patrick OCallaghan from comment #2) > > I won't know till see it in action, which could take a while > > as I use the Fedora packaged version. > > True, it's 3.20.x material, thus Fedora 24. > > > It occurs to me that these selection criteria are not necessarily > > orthogonal, e.g. it could make sense to want to select Unread Messages with > > Attachments from the Last 5 Days that are labelled Important. That would > > mean using tick boxes rather than the current drop-down. Maybe something to > > consider. > > Use advanced search for it, and eventually save it. Most easily (in sense of > typing and clicking) can be used with Free Form Expression search, where you > can put all things together with the and/or conjunctions. See bug #550796 > comment #10, where [1] redirects right now (the Advanced Users notice there). > > [1] https://help.gnome.org/users/evolution/stable/mail-searching.html.en I'll try that and see. Slightly OT: one thing I often want to do is change the current view to see all of a thread (and only that thread), including both read and unread messages. Think of it as analagous to "narrowing" in Emacs. Can the free-form expression syntax be used for that? I don't see a way to do it.
There are advanced searches for that, which you can combine with the Free Form Expression and save them, then activate them using Search->... menu. The problem is to pick the right reference for the thread, which none of these know about. I mean with that, that it needs to know what thread you want to only see, thus to have an information from one of the messages in that thread. I can imagine that the filter could be created on the fly, by using UID of the currently selected message(s), or Message-ID header(s), but this functionality is not available (yet).
(In reply to Milan Crha from comment #5) > There are advanced searches for that, which you can combine with the Free > Form Expression and save them, then activate them using Search->... menu. > The problem is to pick the right reference for the thread, which none of > these know about. > > I mean with that, that it needs to know what thread you want to only see, > thus to have an information from one of the messages in that thread. I can > imagine that the filter could be created on the fly, by using UID of the > currently selected message(s), or Message-ID header(s), but this > functionality is not available (yet). Yes, it would require the ability to read field values and use them in the expression, rather than just constants as at present.
(In reply to Patrick OCallaghan from comment #6) > Yes, it would require the ability to read field values and use them in the > expression, rather than just constants as at present. I think I would be able to create such thing, but I have an issue with wording, to choose a good wording which would be well-understood to users. If you think it might be useful for others too (I believe it would) and you are willing to help me from the user's point of view, then please file a new bug report and we can fine tune the idea there.
(In reply to Milan Crha from comment #7) > (In reply to Patrick OCallaghan from comment #6) > > Yes, it would require the ability to read field values and use them in the > > expression, rather than just constants as at present. > > I think I would be able to create such thing, but I have an issue with > wording, to choose a good wording which would be well-understood to users. > If you think it might be useful for others too (I believe it would) and you > are willing to help me from the user's point of view, then please file a new > bug report and we can fine tune the idea there. OK, I filed https://bugzilla.gnome.org/show_bug.cgi?id=761453 just as a placeholder. I don't have much idea of how to do this (because I realise I don't really understand the current syntax, so maybe that needs to be explained better), however I'm happy to be a sounding board for ideas. If you can get me to understand it, it's a good bet that other people will too :-)