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

List:       kde-core-devel
Subject:    Re: User Interface standards: Dialogs
From:       Mario Weilguni <mweilguni () sime ! com>
Date:       1999-09-10 7:05:27
[Download RAW message or body]

At Fre, 10 Sep 1999 Espen Sand wrote:
> On tor, 09 sep 1999, Mario Weilguni wrote:
> >
> >I agree, 10 pixel is simply too much.
> >
> >Some other problem with the proposals:
> >* "Don't autosave options" - IMO, it's annoying to have to save options
> >manually, and it's really not userfriendly. Options should be autosaved, and
> >changes should apply immidiatly (if possible).
> >
> >* "Help|Defaults|----|OK|Apply|Cancel". This ordering of buttons is not good.
> >This was a year ago already discussed on the lists - IMO the best is
> >"Help|----|Defaults|Apply|Cancel|OK".
> >Why: "OK" is the most used button in dialogs, not "Cancel" (at least not when
> >you know what you are doing), and reading goes from left-to-right (in western
> >countries), so the if you think of a dialog being similar to a form on a piece
> >of paper, you'll read from top-down, left-right. Macs use this, and while I was
> >very sceptic first, now I think it's a better choice (though I still hate Macs)
> >
> 
> Since I work on a base dialog class (which will basically extend the current
> DialogBase class) it is no problem for me to change the layout. But the layout
> that is finally choosen must be identical to the one used in the Control
> Center. Currently CC uses "Help|Defaults|----|OK|Apply|Cancel".
> 
> Actually, I could imagine an actionButtonStyleHint() method that determines the
> order. Using the class I make, it could even be a simple task of
> reordering  the buttons while the app i running (I only need to delete a
> QLayout of a box widget and re-add all the childern of the box widget to a new
> QLayout but in a different order - I don't use the KButtonBox for this btw)

Apropos kbuttonbox: I was once playing with the idea of adding a few static
methods to kbuttonbox, e.g.
* yesNoCancel()
* yesNo()
* okCancel()
...

Can save quite some space in the applications. If we combine this with the
ability of an area of user-defined buttons (e.g. userArea()), this will improve
the consistency of the applications, and will make programming easier.

KButtonBox should be expanded to take advantage of such a
actionButtonStyleHint() 

Ciao,
	Mario

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