From kde-devel  Thu Jan 06 14:37:14 2005
From: "Friedrich W. H. Kossebau" <Friedrich.W.H () kossebau ! de>
Date: Thu, 06 Jan 2005 14:37:14 +0000
To: kde-devel
Subject: Re: Superlous configuration?
Message-Id: <200501061537.15237.Friedrich.W.H () kossebau ! de>
X-MARC-Message: https://marc.info/?l=kde-devel&m=110502230500232
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0560151508=="

--===============0560151508==
Content-Type: multipart/signed;
  boundary="nextPart1438651.73rf9MIlV8";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1438651.73rf9MIlV8
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Donnerstag, 6. Januar 2005 15:12, schrieb Waldo Bastian:
> On Thursday 06 January 2005 14:48, Friedrich W. H. Kossebau wrote:
> > As IMHO the majority of today's config dialogs do everything but look
> > decent the danger to do worse is not that great.
>
> The goal is to do better.

Of course. I just wanted to calm those who fear worse dialogs :)

> > Just have a look at the "Look'n'Feel" dialogs and analyse them: They all
> > do the same (from an abstract POV). But each has a different handling,
> > layout and so. If all would be generated by such a framework you would
> > not have to relearn for every single dialog.
>
> KConfigXT can already take care of the handling for a great deal, the rest
> is a matter of proper style guides and careful UI design.=20

Which could be enforced/overtaken by a framework.

> And yes, I agree=20
> with you that a lot of dialogs aren't very good, the solution for that is
> that developers start to take their dialog design more serious instead of
> treating it as a dumping ground for features. The current prevailing
> mentality is too much oriented to adding feature after feature after
> feature till such dialogs have become way too big and confused. What is
> lacking is some more thought on how a certain set of features comes
> together and how to present that to the user as a consistent whole.

Because this is not the fun part? A framework as proposed would easen this=
=20
problem for the feature writer as he might be able to hand over this part t=
o=20
those who are better at this.

> Unfortunately all I see in these discussions is people looking for cheap
> technical solutions that allow them to keep dumping feature on feature
> without tackling the hard part of designing a well-balanced whole.

Because they do not like writing the docs and painting the icons, too? The=
=20
icons are already done by artists, the docs often by doc writer, why should=
=20
there not be layouter for the layout of the configuration?=20

Besides, the problem with the Delete entry might have never come up if ther=
e=20
was an editor for the popup menus. So this is rather a lack of a feature ;)

=46riedrich

--nextPart1438651.73rf9MIlV8
Content-Type: application/pgp-signature

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

iD8DBQBB3U0bECqmVFXwdrMRAtIzAKCErFNaTAQJL8yCez1UfOSoMwpIVwCdG8Mj
ac4TKSatLpwNfUOZbfQfPFc=
=ux0m
-----END PGP SIGNATURE-----

--nextPart1438651.73rf9MIlV8--

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

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============0560151508==--