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

List:       kde-look
Subject:    Re: Dialogs: How to layout
From:       Espen Sand <espen.sand () neo ! no>
Date:       1999-09-14 9:20:26
[Download RAW message or body]

Below I have added a mail I sent to core-devel yesterday. I hope that
the button order eventually can be controlled from the Control Center. Then we
can all use what we prefer ourself!

<MESSAGE>

Ok, I am making a base dialog class that will extend the current 
DialogBase widget in a number or areas. (Mirko, have you tried the 
one I sent you?)

As a part of this dialog I have made a flexible action button layout/order
mechanism. The order is controlled by a stylehint and can be changed while 
the dialog is visible. This make it possible to configure the layout from the
Control Center or some theme tool.

Here are the layouts I have seen been proposed various places. The <User>
is something I have added to allow configurable button names. Hopefully this
can be used kill of the (endless) discussions abot this topic. If you have
another proposal, speak up, it is trivial to add another one (price: 40 bytes)

|OK|Apply|Cancel|<USER>|-----|Default|Help|
|OK|Cancel|Apply|<USER>|-----|Default|Help|
|Help|Default|-----<USER>|Apply|OK|Cancel|
|Help|Default|-----<USER>|Cancel|Apply|OK|
|Help|----<USER>|Defaults|Apply|Cancel|OK|

where <USER> is |User|User2|User1
and ---- id stretchable space

NOTE: I do not use the KButtonBox widget for this. Perhaps this widget 
should be modified/revised.


Here is a short description of code that already exists and works!
----------------------------------------------

static int layoutRule[5][8] =
{
{Ok,Apply|Try,Cancel|Close,User3,User2,User1|Stretch,Default,Help},
{Ok,Cancel|Close,Apply|Try,User3,User2,User1|Stretch,Default,Help},
{Help,Default|Stretch,User3,User2,User1,Ok,Apply|Try,Cancel|Close},
{Help,Default|Stretch,User3,User2,User1,Cancel|Close,Apply|Try,Ok},
{Help,Default|Stretch,User3,User2,User1,Apply|Try,Cancel|Close,Ok},
};


Rules
-----
The user will decide which buttons are required so every button can be 
masked away (but Cancel will always be added, see below).

eg a mask of Ok|Apply|Cancel can be shown as (using the rules)
|Ok|Apply|Cancel|----
|Ok|Cancel|Apply|----
----|Ok|Apply|Cancel|
----|Cancel|Apply|Ok|
----|Apply|Cancel|Ok|


Cancel and Close can not be present at the same time, if they are
Cancel is selected. If none, Cancel is added.

Apply and Try can not be present at the same time, if they are
Apply is selected.


</MESSAGE>







On tir, 14 sep 1999, Peter Penz wrote:
>I know the current standards about the dialogs are very weak. I collect
>all mails about the UI-Standards discussion (I've now more than 100
>mails with suggestions...), but it's not easy to find a common line,
>especially for dialogs.
>
>It would be great, if someone could make a draft how to layout/use
>dialogs, which I could put into the web-page for discussion (the webpage
>is downloadable as tarball on
>http://www.esh.uni-linz.ac.at/~mother/hci/basics/index.html).
>
>Some suggestions to the person who wants to do this job :-)
>- if you want to change an old standard, it's 
>  necessary that the new standard is MUCH BETTER,
>  otherwise nobody will change old apps.
>- take a look at around 5-10 applications to find out
>  how dialogs are used and check weak points.
>


-- 
Espen Sand

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