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

List:       kde-usability
Subject:    Re: Minicli Polishing
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-09-15 17:53:35
[Download RAW message or body]

On Sunday 15 September 2002 08:53, Aaron J. Seigo wrote:
> > What we need is a frame style 'Auto' which means as much as "pick
> > your own preferred look" so the other styles can and will be honoured by
> > the style at any cost when explicitly requested.
>
> perhaps. again we end up with a mish-mash and depend on the developers to
> get the work done consistently and thoroughly. that's a tall order.

Not necessarily. If the Qt default is 'Auto' most of the work is done rather 
quickly. Only a few programmers explicitly set a border style, and even less 
do it when they actually just want the default setting. Only those cases need 
fixing AFAICS.

It changes semantics in a way that can not be done in the Qt 3.x series 
though, so it would have to wait for 4.0. The 'Auto' style can be added, but 
not as default.

> there is only one way to find out. i just got a patch for keramik that
> isn't perfect, but allows one to start to see the effect...

Hmm, can you post the patch here or mail me in private?

> of course not this close to release. the concern about having different
> styles of layout emerge throughout the codebase remains in my mind, though.
> down this pathway lies a kde which has a patchwork of styles in a couple of
> years.

Yeah, the same thing that more and more is turning Windows from a very 
consistent environment into a horrible patchwork of several different 
generations of GUI styles. I rather stay away from that, too :-)

> > I can play a bit with resize policies to get that straight. It's QLayout
> > that does this, it's not on purpose. I noticed it too.
>
> expanding spacers can do wonders =)

You mean with whitespace on the right edge? Hmm, that's another option. Need 
to try it to see the effect. I actually wanted to have it to be 
right-aligned, but it's an option, at least until I've seen the effect ;-)

> > How do you do such a thing in the code? (I agree with you here, but I
> > don't know whether that can be done.)
>
> i've done it several times in designer =) never done it hand-coded. doing
> such things by hand is an annoyance and a trouble. doing it with desginer
> takes a fraction of the time.

Hmm, it was code and I originally wanted to make the patch non-intrusive. If 
you think it's fine to convert it to .ui files it will be my greatest 
pleasure, since it's not kdelibs stuff and coded widgets are a royal pain in 
the ass to maintain and to write.

> i understand that. that sidesteps my concern completely, which was: by
> being different than the rest of KDE, it shows up these issues in the rest
> of KDE =) doing things one way in one place and another in another sucks...
> are we, and can we, do this sort of polish everywhere? is the checkbox
> proxy a good solution and one that should be used elsewhere? i'm looking a
> bit bigger picture here, but not disagreeing that it looks nicer.

The checkbox proxy is a remarkably easy class to use, so that shouldn't be the 
problem. You simply connect your signals to the real checkbox on the left and 
the label passes them on when appropriate. It's basically a QLabel in buddy 
mode's behaviour on steroids.

The only downside is a severe one though: some styles make checkbox captions 
look slightly different from plain QLabels and/or add mouseover effects to 
them. Without changing the widget style itself in one way or another it's 
impossible to achieve that using the proxy. It can be kept as simple as 
providing a unique 'name' parameter  to QWidgets's ctor, like prefixing it 
with "checkboxproxy: ", but still.

-- 
Martijn


_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]