--===============50536559636544887==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_ohtM/jItqtkYZ9M";
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


--Boundary-02=_ohtM/jItqtkYZ9M
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 =3D mNested !=3D 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=20
user has no indication that he's missing something). Instead options=20
should just be disabled if they don't apply. Then the user has the=20
chance to notice that there are disabled options and if he wants those=20
options enabled then he'll begin to search where they can be enabled.

> - it if is globally on, you can disable it on a per=20
> folder basis and additionally disable subject threading for this
> folder
> - bool threaded =3D 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=20
few of my 100+ folders I have HTML rendering enabled. With your=20
proposal I would have to turn HTML globally on and then turn if off for=20
each and every folder (except for the few were I really want it).

With threading this is probably slightly different because not many=20
people would want to turn on threading only for a minority of their=20
folders. Most people will more likely either not use threading at all=20
or use if for the majority of their folders.

So at least for the HTML setting the current solution is IMO preferable.=20
And for threading I also tend to keep the current solution.

> 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=20
somewhere else. Especially the Folders section acted as a dumpster for=20
every option that didn't fit somewhere else. Actually most options in=20
=46olders affect the behavior of KMail and therefore we should probably=20
simply rename Folders to Behavior (and move the default mailbox format=20
selection somewhere else).

Regards,
Ingo


--Boundary-02=_ohtM/jItqtkYZ9M
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3rc1 (GNU/Linux)

iD8DBQA/MthoGnR+RTDgudgRAieEAKDjtXKF5z/uNkJ0AWZ3neBzbni3tQCeNJEj
jOTqvVJKhHhMeDAje7xcBeg=
=Y0GU
-----END PGP SIGNATURE-----

--Boundary-02=_ohtM/jItqtkYZ9M--

--===============50536559636544887==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

--===============50536559636544887==--