GNOME Bugzilla – Bug 339629
[KB-Fixed] Create New Folder parent dir inconsistent
Last modified: 2009-08-30 05:53:49 UTC
When creating a new folder, the dialog automatically selects the currently active folder as parent folder to create the new folder in. This behavior is *not* true for the Account root node (if supported) and thus inconstent. Steps to reproduce: * Right click on any Folder, for example your Inbox or Sent folder. In the context menu, select New Folder. The dialog default to the active folder, selected before (by right clicking). * Now do the same , but right click the On This Computer root node. The dialog defaults to Inbox. This is inconsistent behavior, because the On This Computer node perfectly can hold new mail folders.
*** Bug 337524 has been marked as a duplicate of this bug. ***
also see bug 330163, bug 346126, bug 339629
*** Bug 349936 has been marked as a duplicate of this bug. ***
I've been researching this one a bit, learning as I go. I thought I'd try to summarize my progress without rambling on too much. Clicking the "New Folder..." pop-up item calls emft_popup_new_folder(), which in turn calls em_folder_tree_get_selected_folder_info() and passes the returned CamelFolderInfo (a tree-like structure) to em_folder_utils_create_folder(). The CamelFolderInfo contains a URI that specifies which folder gets highlighted in the "Create folder" dialog. Backing up a bit, em_folder_tree_get_selected_folder_info() calls the get_folder_info() method on the appropriate CamelStore object. I think the various implementations of this method in Camel is where the problem lies. I've only looked at CamelVeeStore in detail so far, but there does not seem to be a way to represent the "Search Folders" item as a CamelFolderInfo. So when given NULL for the "top" argument (top==NULL means start from the top of the folder tree), vee_get_folder_info() -- CamelVeeStore's implementation of the get_folder_info() method -- assembles the entire folder tree minus a root node. I imagine a similar situation exists for "On This Computer" in that there's no way to represent that item as a CamelFolderInfo. This might be a design flaw in Camel. I'm not yet familiar enough with the library to say for sure. Stepping back from Camel though, this whole process seems to entail an awful lot of unnecessary work just to highlight a row in a dialog window. So I'm not sure what angle to try to approach this problem from: fix Camel or fix Evolution's Mail component directly.
Bug Report from Ubuntu: http://launchpad.net/bugs/65991
Fixed on the kill-bonobo branch.
The "kill-bonobo" branch has been merged into "master" and will debut as Evolution 2.29.1. We believe the branch has addressed the reported issue. If you find the issue still exists in version 2.29 or later please feel free to re-open this bug. Closing as FIXED.