GNOME Bugzilla – Bug 593890
New folder window is not in focus in filter dialog
Last modified: 2010-10-31 13:08:53 UTC
Evolution 2.29.1 1. Edit > Message filter > Add 2. Add condition 3. In 'add action', click on button which says 'click here to select a folder' 4. Click on 'New' as i want to create a new folder as destination folder 5. I cann't write folder name as it's not in focus 6. I have to close 'select folder' window
This bug is valid in search folder dialog also.
I think this bug also exists in 2.27.
It works fine in 2.27.91 for me.
Hmm, perhaps I dropped another patch then. Will hunt for it.
So this problem is not limited to just editing filters. It also occurs when moving a folder or messages to another folder via "Copy to Folder" or "Move to Folder" menu items. There is no easy fix here -- we need to rethink how to handle the use cases behind this dialog. Some thoughts: - Desktop-wide authentication prompts are the only use case for modal dialogs, and Gnome-Keyring and PolicyKit cover them. Any other modal dialog is a bug, and should not be part of a solution to another bug. - It appears you cannot have a transient window for another transient window. I think the only reason the filter dialog case is working in 2.28 is because the "Choose Folder" dialog is made modal instead of transient, which itself is a bug. And I haven't checked this but I bet the "Copy to Folder" and "Move to Folder" dialogs in 2.28 still exhibit this bug. - Since dialogs categorically suck, the ideal solution is to provide a way to choose a folder without popping up a dialog at all. With Bonobo now gone, we can do this. Based on how Apple Mail handles this, I recommend the following: 1) Drop the capability to create a New folder while picking a target folder. And kill the "Choose Folder" dialog altogether. 2) Convert the "Copy to Folder" and "Move to Folder" menu items to submenus, and have the submenu reflect the folder tree: Message -> Copy to Folder -> On This Computer (grayed out) Inbox Drafts Outbox Sent Templates ---------------- My IMAP Account (grayed out) Inbox Drafts Subfolder Nested Subfolder ... There's some logistics to work out here. For example, virtual folders (including Junk and Trash) would be absent. We'd also have to figure out how to deal with accounts that do and don't let you combine messages and subfolders in the same folder. 3) For the filter rule window and similar cases, convert the <click here to select a folder> button to a combo box that shows the folder hierarchy similar to the menu above. EMFolderTreeModel implements the GtkTreeModel interface and already has all the information we need, so I think we can easily build GtkAction and GtkComboBox subclasses around it.
Created attachment 143840 [details] screenshot of the Thunderbird Nostalgy plugin Just to record alternative keyboard-friendly method of working with MANY folders.
Untagging this as a regression since the problem exists in 2.28 but is masked by improper use of modality. This is a usability issue.
(In reply to comment #7) > Untagging this as a regression since the problem exists in 2.28 but is masked > by improper use of modality. This is a usability issue. I do not think it's wrong, or "improper use of modality". See in what level of window hierarchy you are in Message filters, it is "Message Filters"->"Edit rule"->"Choose folder window"->"New folder window". It's deep enough to believe user is really willing to enter the new folder name first, then playing with mails in the main window. Also, setting transient as it is now and having the "New folder" shown modal means you are still able to move with background windows. With respect of comment #5, it doesn't sound bad, but only for small folder hierarchies. When you've more than 5 accounts and in each of them say 30 folders, it would be quite hard to find it in the menu, not talking about an inability of showing it "nicely" as a submenu with deep folder hierarchy. Talking about this, I know I was fixing it already, maybe it explains it worked fine in 2.27.91 for Akhil.
Created attachment 160223 [details] [review] evo patch for evolution; I'm committing this. Feel free to disagree, but it's too late for stable (2.30) anyway, and I believe there will not be enough time to make this behave as you suggested in 2.31. But I can be wrong. Do not hesitate to reopen.
Created commit 0a06578 in evo master (2.31.2+) Created commit 4993d81 in evo gnome-2-30 (2.30.2+)
*** Bug 620745 has been marked as a duplicate of this bug. ***
*** Bug 621621 has been marked as a duplicate of this bug. ***
*** Bug 622560 has been marked as a duplicate of this bug. ***
*** Bug 633607 has been marked as a duplicate of this bug. ***