GNOME Bugzilla – Bug 524365
Expand folder tree for message Move/Copy folder selector
Last modified: 2018-06-11 06:28:46 UTC
Please describe the problem: The "select folder" dialog for the "Message->Move/Copy to folder" is great for keyboard-only moving and copying of messages as it supports keyboard look ups of folders - but only if the required folder is not under a collapsed folder in dialog's folder tree (i.e. not visible). The problem is that the state of the folder tree is not kept between calls to move/copy - if the state of folder tree in the main mailer window is modified by closing and opening folders, then the state of the folder tree in the "select folder" is modified to match, but not vice versa. The use case is that normally I file messages from the inbox away to other folders under a complex folder tree using the "select folder" dialog - for easy access the folder tree in the main mailer window is always collapsed and the folder tree in the "Selecte folder" dialog is always fully expanded. Sometimes I use the main mailer UI to go to a sub folder to read something and then I close the main folder tree when I'm done and back at the inbox. After I do that, the next time I need to move/copy a message to a sub folder I have to again open all the folders I previously had open in the "select folder" dialog. Steps to reproduce: 1. with a multi-level folder hierarchy select a message and move it to some deep folder using CTRL-SHIFT-V and browsing for the target folder in the "select folder" dialog. 2. in the main view go to that sub folder by expanding the relevant parent folders. 3. in the main view collapse the folder tree back. 4. select another message in one of the top folders and use CTRL-SHIFT-V top bring up the "select folder" dialog 5. try to use keyboard lookup to get to the previously chosen sub folder Actual results: The sub folder that was previously visible in the "select folder" dialog is no longer visible and can't be found using only keyboard lookup Expected results: The sub folder that was previously visible should still be visible and accessible using keyboard lookup Does this happen every time? Yes Other information:
> The sub folder that was previously visible in the "select folder" dialog is no > longer visible and can't be found using only keyboard lookup I'm not sure I understand what you mean by that last part about "can't be found using only keyboard lookup". You can use + and - to expand and collapse folders in the Select Folder dialog. But I think I follow the behavior you're describing. Are you suggesting the expanded state of folders in the Select Folder dialog should be independent of the folder tree in the main window?
Yes. The problem I have is that with a complex tree, I know where I want to store my message but most times I can't quickly find it just by typing the folder name - I have to: 1. locate the top parent folder by typing its name 2. hit ESC to cancel the current keyboard name lookup 3. hit + to expand the parent folder 4. go to 1 to locate the next parent folder and on and on until I reach my folder (currently sometimes 4 levels deep). The next time I use "move/copy to" I may have to do it all over again. Ideally I would like the "Select Folder" dialog's tree to be always fully expanded, but at worst it should maintain a separate state so that if I once expand all the folders, it should stay that way for the duration of the session. I think that the "Select Folder" tree has a different use case then the main window's tree and thus should not follow the same behavior. As I explained above one use case is too keep the main window folder always collapsed to minimize clutter and to expand it only when actually looking for a previously filed message (which is rare). Additionally each incoming message is moved to a deeply nested folder for archiving immediately after reading/handling it. In this use case synchronizing the tree state between "Select Folder" and the main window causes a lot of extra work.
This report is probably similar (if not identical) to bug #509919, though I believe that that bug report talks about storing state between sessions (i.e. have the tree maintain the state that it was before a restart of Evolution) while I would be perfectly satisfied with maintaining the "select folder" view state in the same session.
This issue looks to be fixed in 2.24.2 (after a recent Fedora update). Whoever fixed the problem, thank you for working on this! :-)
Thanks for the update. Closing as FIXED then.
Maybe this was just a fluke or something - but in 2.26 the problematic behavior is still apparent in some cases. I have yet to nail down all cases, but one problematic case is when shutting down Evolution and restarting it: when evo restarts the folder tree in the mailbox folders pane is open as it was in the "select folder" dialog at the time of shutdown and not like the folders pane was open at the time of shutdown. If I immediately open the "select folders" dialog I see the tree is open like I expect it would, but if I instead collapse the tree in the folders pane and then open "select folder", then the tree is collapsed. After that, opening and closing the tree seems independent in most cases except in some rare cases which I currently have yet to be able to reproduce reliably.
Still in 3.2.3
*** Bug 509919 has been marked as a duplicate of this bug. ***
I made the change to expand the tree in the Move/Copy to folder dialog and added a code to preselect the currently chosen folder in the mail reader, if there was no folder selected yet (that was already there). I also removed unnecessary code duplication. Created commit f287965 in evo master (3.13.9+) [1] Created commit 201ad06 in evo evolution-3-12 (3.12.9+) [1] https://git.gnome.org/browse/evolution/commit/?id=f287965
*** Bug 592145 has been marked as a duplicate of this bug. ***