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

List:       kmail-devel
Subject:    Re: mime tree layout
From:       Karl-Heinz Zimmer <khz () kde ! org>
Date:       2002-09-10 20:59:43
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[cc'ing the non-private parts of your mail to the list]

On Tuesday 10 September 2002 22:44, Aaron J. Seigo wrote:
> On Tuesday 10 September 2002 02:17, you wrote:
> > > it is your answer which dictates whether i contemplate removal of
> > > that configurability or not.
> >
> > Please do not remove that configurability: Originally the plan (and a
> > 1st implementation tested that) was a _fully_ configurable layout but
> > this had some drawbacks so we changed to a simpler solution.
>
> this can be achieved if desired, but the current method is not great. the
> buttons  in the layout page are completely undecipherable. not one person
> i've walked through the kmail config could figure out what those buttons
> do; some didn't even get it after i asked them to experiment with it.

So they _must_ be improved or replaced by something that can be understood.

> hell, *i* only knew what they do because i was around when those design
> decisions were made and so have an insight into the code itself, but if i
> hadn't been around kmail devel i would be equally clueless without
> experimenting...

> based on this insight into the innefectivity of the current solution, a
> complete and proper solution should be provided, or none at all. both end
> up with those options in the config dialog being removed and the
> mainwindow layout stuff rethought.

OK, I have no problem with the idea of getting a better solution.  :-)

But (of course) I would be frustrated to loose functionality _without_
getting a replacement that serves the same purpose but does it better.

So please make the following (if you have time to do so):

1. Find out how the configurable layout can be described visually so
   that most people will find it intuitive.

2. Present your findings here.

3. Implement this better way as a patch so we can try it.

4. Get the OK, so it will go both into your branch and (after
   feature freeze is over) also into HEAD.

By following these 4 steps you would gain enormous benefits:

* Get your changes supported by both the branch and the HEAD developers.
* Save time when it comes about merging both.

Does that sound good?   :-)

Karl-Heinz
- -- 
Karl-Heinz Zimmer, Senior Software Engineer, Klarälvdalens Datakonsult AB
<mailto:khz@klaralvdalens-datakonsult.se>            <mailto:khz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.1.91 (GNU/Linux)

iD8DBQE9fl1CCcaVnbvggDcRAhiiAKDky+S6WAn/sY4iWD57PecXa4liMwCeNEqX
lEWbuh1QESKZqe8cmgWKCLg=
=v5+e
-----END PGP SIGNATURE-----

_______________________________________________
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]