[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Proposal to change the way threading settings work
From:       "Carsten Burghardt" <cb () magic-shop ! de>
Date:       2003-08-08 7:23:00
[Download RAW message or body]

Ingo Klöcker sagte:
> On Thursday 07 August 2003 23:53, Till Adam wrote:
>> Folks,
>>
>> while entertaining myself with breaking threading I noticed that the
>> way the threading (and html) options are handled really is rather
>> confusing if not plain wrong. What we curently have is a global
>> threading, saved in
>>
>> [Geometry]
>> nestedMessages
>>
>> Per Folder, there is an additional setting which is an _override_ of
>> the gloabl setting. That means that kmheaders.cpp does:
>>
>> bool threaded = mNested != mNestedOverride
>>
>> to figure out if the headers are threaded. Now, that means you
>> actually have to turn the per folder option _off_, if the global
>> option is on, to get threaded behaviour. Same for html. The gui tries
>> to work around that and partially fails, resulting in much fun with
>> out of sync .sorted files (which store the threading status also) and
>> the infamous "threading actions out of sync" bugs.
>>
>> Now, I'd like to propose to change this to work as follows:
>> - the global option turns threading globally on or off
>> - if it is globally off, there are not threading options in the
>> folder menus
>
> AFAIU GUI guidelines, hiding options is a bad thing (because then the
> user has no indication that he's missing something). Instead options
> should just be disabled if they don't apply. Then the user has the
> chance to notice that there are disabled options and if he wants those
> options enabled then he'll begin to search where they can be enabled.

Just a sidenote: this "guideline" changes with every GUI guru you're
talking to. I think it's better to hide them because otherwise you'll
cluster your GUI with greyed out options and the user doesn't now how to
enable them.

>> - it if is globally on, you can disable it on a per
>> folder basis and additionally disable subject threading for this
>> folder
>> - bool threaded = mThreaded && mFolderThreaded
>>
>> Same for html. That would simplify things and get rid of some bugs as
>> well.
>
> Especially for the html setting this doesn't make sense. Only for very
> few of my 100+ folders I have HTML rendering enabled. With your
> proposal I would have to turn HTML globally on and then turn if off for
> each and every folder (except for the few were I really want it).
>
> With threading this is probably slightly different because not many
> people would want to turn on threading only for a minority of their
> folders. Most people will more likely either not use threading at all
> or use if for the majority of their folders.
>
> So at least for the HTML setting the current solution is IMO preferable.
> And for threading I also tend to keep the current solution.

At least it doesn't make sense to have different kind of behaviours for
different switches. Perhaps it would be good if folders inherit such
changes from their parents?

>> Additionally I would propose to move the global threading option out
>> of geometry and into behaviour.
>
> This makes sense. But there are more options that should be moved
> somewhere else. Especially the Folders section acted as a dumpster for
> every option that didn't fit somewhere else. Actually most options in
> Folders affect the behavior of KMail and therefore we should probably
> simply rename Folders to Behavior (and move the default mailbox format
> selection somewhere else).
>
> Regards,
> Ingo
>
> _______________________________________________
> KMail Developers mailing list
> kmail@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kmail
>


-- 
Carsten Burghardt
PGP: http://www.magic-shop.de/Carsten_Burghardt.asc
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]