GNOME Bugzilla – Bug 387315
New threads appear expanded
Last modified: 2007-08-23 14:38:06 UTC
1. Sort emails by date (newest first) 2. View -> Collapse all threads 3. Wait until an email appears that makes a new thread (together with an existing email) 4. This thread appears expanded I'd expect to see "Collapse all" to also collapse these new threads and just fix the sort order for those.
Confirmed. (FC6, i386/x86_64) - Gilboa
Can't confirm with neither Evo 2.11.4 nor Evo 2.10.0.
(In reply to comment #2): It's actually pretty easy to reproduce. Just follow Svens steps, but notice that you need a *single* email which gets expanded. So I wrote a patch which addresses this. I'd like someone to review it (so CCing srini :P ) :)
Created attachment 93161 [details] [review] Patch which saves whether to collapse or to expand threads by default, back to GConf and memory
Created attachment 93164 [details] [review] Patch which saves whether to collapse or to expand threads by default, back to GConf and memory G_STRLOC shows filename as well, so got rid of __FILE__
Tobias, the thread expand key was supposed to hold the default state of the thread state. I dont think you can relate it to the expand all/collapse all operations. Many users like to have the threads collapsed, but not the default state as collapsed (It has different behavior when new mails arrive etc) The expand/collapse all should be just operations and shouldn't be default states. The real problem as we discussed is that the state isn't synced to disk, which gets overwritten when a new mail comes.
Mueli, Im sorry for the confusion over irc. You are right. I was thinking of a different bug that we discussed at guadec and speaking to you. This bug is fixed with thread_expand key. Just that there is no UI element to it. It is sort of very advanced setting. I have a lot of advanced stuffs in gconf now and make sense to have a separate advanced config tool/guide to get over it.
cannot reproduce herzi's issue with 2.11.5, it works for me as expected.
Hi srini, thanks for clarifying. Actually I think it doesn't even depend on that key, since it works any thread_expanded setting. I have tested four scenarios with thread_expanded key set to true/false and expand/collapse all mail. Steps how to not reproduce this bug: 0. Have /apps/evolution/mail/display/thread_expanded set to true/false, start Evolution 1. Sort mail by date 2. Group by threads 3. Expand/Collapse all threads 4. Reply yourself to a single mail, which doesn't make a thread yet 5. Hit Send/Receive 6. See the expected behaviour Anyway, it's inconvenient to set thread_expanded via gconf-editor so I wrote an EPlugin which addresses this. It currently lacks a feature to write the changes directly to memory via e_tree_memory_set_expanded_default() but it's still an improvement over the gconf-editor way.
Created attachment 94017 [details] [review] Plugin which sets the thread_expand key A plugin which allows to edit the default thread behaviour in a more convenient way
UI Freeze. Also, it makes sense to add it part of Plugin configuration instead of the code mail-preferences.
(In reply to comment #11) > Also, it makes sense to add it part of Plugin configuration instead > of the code mail-preferences. > Hm. I don't fully agree. Right now it's just below the "thread_subject" thing. I think it perfectly fits there, since there are settings for "Message Display". And that's exactly what it is. I know that you don't want to mess up UI even further, but moving a single configuration option into a single plugin-configuration dialog is even more messy IMHO. (In reply to comment #7) > Just that there is no UI element to it. It is > sort of very advanced setting. I have a lot of advanced stuffs in gconf now and > make sense to have a separate advanced config tool/guide to get over it. > An "Advanced Mail Setting" page, in which you could put all those advanced stuff, might be nice, true. If there is such a page or plugin plannend, than this patch is indeed obsolete. Otherwise I wouldn't change it as stated above. > UI Freeze. A pity, true. But since it's a plugin, one could just disable it by default ;)
(In reply to comment #12) > (In reply to comment #7) > > Just that there is no UI element to it. It is > > sort of very advanced setting. I have a lot of advanced stuffs in gconf now and > > make sense to have a separate advanced config tool/guide to get over it. > > > > An "Advanced Mail Setting" page, in which you could put all those advanced > stuff, might be nice, true. If there is such a page or plugin plannend, than > this patch is indeed obsolete. Otherwise I wouldn't change it as stated above. An advanced mail configuration plugin sounds like a nice idea though. > > > > UI Freeze. > A pity, true. But since it's a plugin, one could just disable it by default ;) You are going to be fined by the release team for this ;-) >
yes, the release-team will kill you, i can promise. i know that gang and their big baseball bats. don't feel safe when you're on the street! ;-)
(In reply to comment #14) > yes, the release-team will kill you, i can promise. i know that gang and their > big baseball bats. don't feel safe when you're on the street! ;-) > Comeone honey, you just don't dare :> So for not exposing my evil secret plans to the even more evil r-t, I'll close this bug and secretly open a new one which is a blocker on an "Advanced Preferences" tracker bug. Also obsoleting the patch due to the new plans on the Advanced Configuration stuff.