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

List:       kde-usability
Subject:    Re: Minicli Polishing
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-09-15 6:53:33
[Download RAW message or body]

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

On Sunday 15 September 2002 09:48, Martijn Klingens wrote:
> 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. 

unless the widget is defined as not having a frame. like, say, a checkbox. =)

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

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

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

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

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.

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

expanding spacers can do wonders =)

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

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.

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

it was just a comment.

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

ooh! another opportunity to use our new "Changes To Styleguide" process.. any 
takers for taking care of this one? 

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

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.

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

same in the rest of KDE. and therefore my concern.

> And
> it only makes the Qt apps look a bit less beautiful, it doesn't make them
> feel 'incompatible'...

look is indeed part of feeling 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.

hrm... this sucks; i honestly expected someway of knowing this info, since you 
can do so for most other situations (e.g. checkboxes in treeviews, text in 
buttons....)

> 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 :(

*nods*

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

iD8DBQE9hC5u1rcusafx20MRAmboAJ4yhSmK8iMMU4sL10bwtyvxfvpybACbBBqz
qigUStAB5kVhXhcE/Okl/50=
=1rrf
-----END PGP SIGNATURE-----

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