I'd love to see this feature too.  Currently older unread emails in Geary get buried (certainly in my inbox), and it's very difficult for me to find them.  Having an 'unread' section, or sort, would make Geary a viable email client for me.

So I've posted a bounty on this bug, in the hope that it might help:

https://www.bountysource.com/issues/1501516-add-option-to-sort-folder-into-unread-read

Currently as far as I can see it, geary has no option to choose the sorting column and no option to filter the messages (except by search). Any ideas how this should look GUI-wise?

There are two related tickets: bug #713654 and bug #713883.  Both deal in sorting messages.  This one deals with filtering.

One possibility is to break up the conversation list (the middle column) into two lists, one stacked on top of the other (unread and read messages).  I'm less enthused about this, but it should be considered.

As far as activating this (and the other sorting options, if/when done), w drop-down menu of sorting and filtering options (like the Mark menu) could be added to the toolbar.  The menu could look something like this:

[X] Show all messages
[ ] Show only unread messages

... where these are radio buttons.  The other options for sorting could be added as well.

That's my general vision, although I'm open to other suggestions.

Personally, I'd be happy with a magic 'Unread' filtered folder just showing me my unread messages.  

That'd avoid the need for any big interface changes at this point, and the concept could also work in the future for supporting user defined filters (e.g. the user could create a 'from Bob' filtered folder, only showing messages from bob@example.com)

I'm interested in having a crack at this, and am currently just looking at sorting existing folders (not implementing "filtered" virtual folders at this stage). It's easy enough to implement a sort on the contents of existing folders, but where it becomes tricky is with the lazy loading of additional emails when you scroll to the bottom of the conversation list.

For example, if Geary is setup to show the last 2 weeks of emails sorted by Unread/Read, what should happen when you scroll to load more emails and some are unread? I think it could either:

- Integrate the new emails into the existing list, so they all show in the right order (i.e. unread emails put in the top of the list).
- Or, they new set of emails is sorted independently and appended to the end of the existing list.

I'd prefer the second personally. The first option doesn't really "append" to the list as you would expect lazy loading to do, and if you were sorting by something like Subject would make finding what you are after a nightmare. Fore the second, you could also add a subtle separator between the existing list and the newly created list that signals to the user that they are sorted separately.

I'm pretty unenthusiastic about the second option.  That would mean as I scroll down my conversation list forms "stripes" of read and unread messages, each stripe sorted by time/date and the stripes themselves roughly chronological, but only roughly.

This doesn't strike me as useful when I'm looking for a particular message or attempting to focus on only my unread messages.  I've also not seen any other application do things that way.

The key thing to understand about the conversation list is that it is not constrained to load mail of a particular duration (i.e. 2 weeks or what-not).  It loads enough email to generate the scroll bars.  That way, when you scroll further, that signals to load more messages.  Because messages can be grouped into conversations, there's no firm number of messages that must be loaded for this to happen.  Geary must load a batch of messages, sort them into conversations, add them into the list, and then see if the scroll bars are present.  If not, it repeats the process.

As I mentioned in commit #3, I think the easiest (and most painless) thing to do is pure filtering.  Use radio menu items to filter out conversations by their read/unread state.  Choose one item, see all unread messages.  Choose another, see all read messages.  Chose another, see everything.  I suspect that would solve most people's use-case requirements.  It's intuitive, easy to use, and easy to maintain.

Bug #737115 is asking for something similar, but with starred messages, so I'm changing the title of this ticket to reflect that.

*** Bug 737115 has been marked as a duplicate of this bug. ***

I can do this. I will add a drop down menu in toolbar which will contain filtering and sorting options, something like Jim already suggested:

[*] Show all messages
[ ] Show only unread messages
-----------------------------
[*] Sort by date
-----------------------------
[ ] Ascending sort
[*] Descending sort

The menu will also offer a sort by date function.

If you're up for it, go for it.  Please include an option for only showing starred messages as well.

OK. The menu will now look like:

[ ] Show all messages
[X] Show unread messages
[X] Show starred messages
-----------------------------
[*] Sort by date
-----------------------------
[ ] Ascending sort
[*] Descending sort

Note that the unread/stared options are not exclusive (however ticking "Show all messages" will clear the two).

If messages are filtered and user selects another folder, then I propose that the filter should be cleared (i.e. all messages will be shown). I think that such behavior is consistent with many other email clients and is probably something that an average user would expect.

Something I missed the last time through: If "Sort by date" is unchecked, what is the expected behavior?

I added that entry just to make it clear that the messages are sorted by date, so it will always be checked. If you find it confusing, I can remove it:

[ ] Show all messages
[X] Show unread messages
[X] Show starred messages
-----------------------------
[ ] Ascending sort
[*] Descending sort

Yeah, we shouldn't include it if it can't be selected.

In fact, let's just stick with Show all/unread/starred for now.  Sorting is separate tickets (see above) and I think we should take this one step at a time.

Done. Please check https://github.com/geekvigilante/geary.git for details.

This seems like a good start to me but it appears the filter and .ui aren't hooked up to the main application yet.  Is there more you haven't pushed up yet?

Yeah. A few things obviously slipped out while committing. Sorry for the inconvenience and please check once again.

Ok, that's much better.  I've taken your github branch, tweaked it slightly to match our coding guidelines and a little code reduction, and pushed it to git.gnome.org at wip/713872-filtering.

There's two issues remaining before I can merge this into master:

* We need to find a better icon for the filtering button.  The magnifying-glass icon is better used for search, not filtering.  I've been unable to find a good system icon for this, so might need to look outside the project (or even design our own).  Some ideas I've seen at the Noun Project:

http://thenounproject.com/term/filter/36193/
http://thenounproject.com/term/funnel/36191/

I welcome any other suggestions from you (or others).

* If I go to a folder with a lot of messages (like Gmail's All Mail) and filter, the conversation list is reduced considerably.  For example, if I select Only Starred in All Mail, I might get a list of two conversations.

The problem is that Geary will only load more conversations when the user scrolls down.  But with a list this short, there are no scroll bars, and so there's no way to do that.

What needs to happen is for the client code to continue loading messages into the ConversationMonitor until (a) there are no more messages to load from the folder or (b) the scrollbars appear so the user can initiate this action.

Look at the "load_more" signal in ConversationListView and how it's handled by GearyController.  That's the loop that causes more conversations to be loaded until the scrollbars appear.  In essence, you'll need to trigger "load_more" after refiltering.

These are the two issues I see so far.  That said, this is a nice starting point because once all this is in place, it will be easy to add other kinds of filtering later (if so required).

If you want to continue working on github, that's fine by me, but please base future work off of wip/713872-filtering.  Alternately, you can submit diffs here if you want; either is fine for me.

Jim, are you sure that wip/713872-filtering contains the patch? I can't see any difference and can't find the commit.

This is one of my favorite missing features.

I'm having troubles loggin' in with my github account here:
https://www.bountysource.com/issues/1501516-add-option-to-sort-folder-into-unread-read-starred

But I'll add my bounty offer as anonymous in a minute.
Hope to see it committed to master soon.

Yeah, it's in there.  The commit is 3ec1f6d, a squash commit of the two patches from the github account.

Note that some time has passed and that branch won't work with databases from the latest master.  I recommend backing up your database before trying.

I just rebased the WIP branch against current master and pushed it here: https://github.com/mjog/geary/tree/wip/713872-filtering (Using Github until I get a GNOME account).

That branch also fixes the first point in Comment #18 by assuming the filter menu is effectively acting as a HeaderBar menu, and hence putting it all the way over to the right and using the open-menu-symbolic icon.

Jim's second point still stands however, so if anyone wants to work on that they you now have a shiny, up-to-date branch to do it from. I'd live love to land this on master ASAP.

Just updated the WIP branch to merge the filter and empty spam/trash menu together.

The empty menu kind of sticks out a bit for an operation that should be used somewhat infrequently. Move its menu items to the filter menu and turn that into a label menu. They doesn't really belong there as-is either - the two items should get merged into one that is context sensitive and apply to only to the current folder, but it's better than having it sit out on the header bar.

Alright, so I just took a stab at fixing Jim's second issue in the way mentioned, and I don't think it's going to work out.

If we trigger another load in the same way as for the load_more signal then another batch of messages will be loaded, but if do not fill up the available space then another batch should be loaded, but again that might not fill it up either, and so on. If you have a really big folder with only a few unread or starred messages, the whole folder will eventually be loaded into memory before finding that out.

So I think the only solution is to go back to the DB and perform a query when the filter changes. Which means making every folder searchable, or at least filterable - perhaps defining a Geary.FolderSupport.Filter class and implementing it where it makes sense - for minimal and search folders, at least?

Looking into this further, adding a Geary.FolderSupport.Filter would mean implementing that on GenericFolder, and then passing on filter changes to the local folder when listing emails for the folder - i.e. Geary.ImapDB.Folder. However, many different methods in that class talk to the database - making for a large change to the class, and it's not terribly clear what would want to have the filter applied and what would not - presumably ::list_email_by_id_async does, but what if it's called from some context other than the conversation monitor. What about ::get_email_count_async? How do newly appended messages get filtered?

So maybe the correct level to do this at is actually the conversation monitor. It after all manages all of the seen conversations, so maybe that should be orchestrating the filtering as well. I'll have a go at that.

In the end, the conversation monitor has the same but worse problem, since we want to also pull in conversations that meet the filter requirements due to messages that are out-of-folder. For example, if filtering by unread, every email in the current folder, regardless of whether it is itself unread, needs to have its conversation expanded just in case other messages in its conversation are unread.

The current DB schema may allow a join to be used to achieve this efficiently, but someone would need to look into that, and the way the conversation monitor and message retrieval works significantly re-worked.

Another solution would be to make conversations actual objects in the DB. These would need to include enough flags and pseudo-flags (e.g. has attachments) to be able to make a single query to meet the DB requirements. Again, this is some major re-working.

A shorter-term solution is to just apply the filter to messages in the current folder and let the conversation expand those conversations. This is inconsistent with other aspects of the UI but might be good enough as a workaround.

Since this has become about filtering rather than the original reporter's request for sorting, I've filed Bug 766357 to take care of that.

NB Bug 713150 covers adding a DB table to track conversations, with a good argument for doing so.

*** Bug 714983 has been marked as a duplicate of this bug. ***

NB my current thinking about this is over at: https://gitlab.gnome.org/GNOME/geary/issues/85 and when this bug is imported this will be marked as a dup of that. The technical issue still remains, but I'll still like us to get to this ASAP.

In brief: Since filtering is already handed by search operators (`is:unread`, `is:starred`, etc.) there's no point adding more UI for that. Instead, we'll add support for grouping (a.k.a. "sorting with headers") for common things like unread state, starred, etc.

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/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/geary/-/issues/

Thank you for your understanding and your help.