[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 15:48:00
[Download RAW message or body]

On Sunday 15 September 2002 05:29, Aaron J. Seigo wrote:
>  o i have thought about the group box replacement thing and came to what
> now seems to me to be the obvious realization: this is a style thing.

Hmm, a widget style ignoring the frame style sounds like a grave bug to me, 
actually. 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.

I do agree that having this standardized is good, but I am not sure if it can 
actually be done. Not to mention that in some cases group boxes work out 
better and in other cases they clearly do not. Having one setting might have 
unwanted side effects.

Definitely not something to change so close before release. Anything 
(including using a plain QGroupBox which I utterly dislike here) is better 
than introducing such a thing now.

>  o the space between the label and the widget (e.g. User&name: and the
> lineedit) is not good. they should be close for association. the widgets
> can still line up on their left edge, but there is no reason for them to be
> shoved to the right edge of the dialog.

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.

>  o speaking of style issues, sliders with the ranges to the left and right
> of the slider are not optimal IMO. the clash with the label (e.g. Priority)
> and don't work if you have more than one. if you have three labelled
> positions, they have to appear below. this should probably be stuck to even
> in the case of 2 labelled positions. using a 0 spacing layout to group the
> labels and slider make for a nice tight layout, i have discovered.

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.)

>  o we need an "advanced" icon. using "Configure" for "Advanced" doesn't
> help the meaning of the icon (multiple meanings per icon is bad, and should
> be avoided if possible)

True. But until there is one I don't consider this one a showstopper.

And given the upcoming message freeze I might commit early and polish the GUI 
later so at least the messages are in. It seems at least the overall idea is 
worth continuing to code.

> yes. we've been practicing and advocating this style on the list. the label
> and the widget are a single logical unit and should behave together. this
> will help users with association and improve clarity by keeping windows
> cleaner when options are off. if this isn't in the style guide, it ought to
> be.

Can someone update the style guide? It's not mentioned yet.

> unless we do this everywhere, i'd recommend against it.  i do like the
> look, but i'm always concerned about consistency: once users see it a
> certain way changing it (esp for the better) will inspire thoughts of "the
> rest sucks" ;-) i don't think it enhances usaiblity tremendously, and it
> will always break w/Qt only apps (if that matters to you)

It is not about usability per se, but more about polishing the looks in each 
and every detail. Details count too when it comes to a user percieving a 
dialog as 'messy' or 'crowded' instead of 'organized' and 'well-layouted'. 
The few pixels that we're talking about might not be noticable at first 
sight, but subconsciously they definitely are for most people.

And wrt to Qt compatibility, we're talking widget placement here so it can't 
be done compatibly anyway without changing .ui files or C++ code. And it only 
makes the Qt apps look a bit less beautiful, it doesn't make them feel 
'incompatible'...

> using a spacer size that == the width of the checkbox as brought back by
> QStyle's pixel parameter method?

That's what I said, that's not possible. The checkbox width can be queried. 
But there is a whitespace between the checkbox and the caption, and that 
spacing can not be queried in any way. It is hardcoded in the styles and one 
can only hope the value is the same for each style if we want to take this 
route.

I'd love to see something better, but for accurate label placement the checbox 
proxy is the only reliable way, but both approaches are essentially hacks, 
each in their own respect. I haven't found a non-hack way yet :(
-- 
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]