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

List:       kmail-devel
Subject:    Fwd: Re: kmfolder::properties
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-09-18 20:50:33
[Download RAW message or body]

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

arg... why is everyone CC'ing me?

On Wednesday 18 September 2002 12:55, Marc Mutz wrote:
> > i've got to do some testing and then i will commit to make_it_cool
>
> <snip>
>
> That's nice.
>
> But when you go about redesigning dialogs, keep in mind that .ui files
> are not as cool as they look.

i'm not using them because they look or sound cool. i'm using them because
i've done it both ways and have discovered which is best for my needs.

and  they are as cool as they look. ;-)

> 1. You can't use KDialogBase as base and the "make a QWidget and plug it
> in" works only for plain dialogs and gets messy with tabbed dialogs or
> - horror - tabbed pages plus icon list. Or take the current
> ConfigureDialog. Each page or tab is a subclass of ConfigurationPage,
> which has methods apply(), setup(), dismiss() etc. You'd have to take
> the FooDialogImpl and stuff it into a ConfigurationPage frame. That's
> so butt-ugly, I don't want t think about it.

or create a template that subclasses from ConfigurationPage instead.
or don't do an Impl step at all and either use the ui.h capabilities or put
all the logic into the ConfigurationPage subclass, using the designer widget
as a "container" of sorts (means prefixing all accesses to widgets with ui->
or whatever you call it)

on the other hand, once could also bitch and moan all day (and be completely
justified in doing so) about what a mess having complex layouts hand coded
is. you can't tell where the ui layout ends and the data interaction begins,
maintenance is an annoyance, refactoring a nightmare, layout experimentation
frighteningly expensive, not accessable to anyone but developers.........

> 2. You have to hard-code layout spacing and margins and can't use
> KDialog::*Hint();

wrong. take a look at the form settings, in the layouts groupbox.

> 3. Last time I looked, Designed/uic couldn't put dialogs in namespaces.

still doesn't, AFAIK. but i don't see how that is a problem here.

> 4. Layout handling is largely non-existant. All boils down to setting
> sizePolicy's instead of using stretch factors in layouts, which almost
> everyone uses instead.

you can set both stretch and size policies. i have no idea what you are
talking about when you say layout handling is largely non-existent. in fact,
i dare you to do by hand some of the more annoyingly complex layout feats
that are extremeley easy to do in designer. perhaps you don't know how to use
designer fully?

> That means that I'm quite a bit opposed to introducing .ui files in
> KMail. Instead I prefer coding them by hand.

that's nice.   ;-P

too bad complex hand-written dialogs are not only dog-slow to create, but
raise the cost of maintenance while making experimentation and  refactoring
hardly even worth it.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9iOca1rcusafx20MRAgjAAJ9arMZUvAPhSVV5zXNzLWqhbsP00gCeKzCF
SPO7gjI/I2/uCFXGuBV2qJE=
=UOXv
-----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]