kwin default window button order.

[Aaron J. Seigo]

On Thursday 15 November 2007, Lubos Lunak wrote:
> On Thursday 15 of November 2007, Aaron J. Seigo wrote:
> > hi all ...
> >
> > something that i've been wanting to see happen for a while is our window
> > button order modified a bit. in particular, the defaults would be changed
> > to "maximize, minimize, sticky, spacer*2, help, menu" on the left and
> > "close" on the right.
>
>  I might perhaps point out at this point that the Oxygen windecoration at
> this moment actually has a rather limited button list and doesn't have e.g.
> sticky.

yeah, i've noticed =/

> > the reasons for this layout are:
> >
> > * close is a destructive action and should therefore be kept away from
> > other buttons. we do this in our menus as well.
>
>  But in the menu it's moved only a bit away, and it can be done for
> titlebar buttons as well (as seen e.g. in this openSUSE screenshot
> http://en.opensuse.org/Image:Screeny102_KDE_k3b.jpg).

yes, this is better .. but misses some of the other benefits i outlined.

as a side note, i think this is one of the things Apple screwed up in OS X; it 
OS 9 they had close away from max/min ... very smart. then they put them on 
the same side for (afaik) purely visual reasons. bleh.

> > * in our dialogs we put "go away" buttons on the right (e.g. Ok, Cancel)
> > and action buttons to the left (Help, Defaults, etc). we usually put our
> > clear buttons on the right in line edits, etc ... this brings the window
> > decorations into line with this concept.
>
>  These two may be easily outweighted by the annoying inconvenience of
> making it very different from other commonly used desktops (GNOME,MS
> Windows, KDE3). Probably very annoying, given how often these are used.

close remains where it was, people can if they wish set it back and it's very 
easy to get used to ... i received a lot of positive (and unussually: no 
negative) feedback when i first blogged about it over a year ago; several 
people who tried it (including some who said they were initially sceptical) 
said they liked it... 

i think it comes down the usability bonuses pointed out, which includes not 
only proximity to close (which is important) but also better uses of the 
corners and semantic alignment with how we place buttons in dialogs, menus, 
etc.

> > attached is a patch that accomplishes this. the patch does four things:
>
>  I like the patch.

cool

> > * it changes the defaults to the above
>
>  With the exception of this item, unless there's stronger support for it.
> I'd personally prefer the using of spacers to separate the close button.

ok, i'll commit everything, but with the current defaults (just so i'm not 
holding on to the larger patch locally) and we can work on figuring out the 
defaults issue more.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071115/52a96084/attachment.sig>