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

List:       kde-usability
Subject:    Re: Fwd: [Kwin]  [Bug 56922] New: double click in title bar menuicon
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2003-04-08 2:10:32
[Download RAW message or body]

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

On Monday 07 April 2003 10:45, Lubos Lunak wrote:
> In bug #48835, the comment was made:
> "That feature was removed for usability reasons, and only the styles that
> are copies of systems which have this feature still have it (Redmond,
> CDE)."
>
> Please, add this feature back for all themes, at least as a preference that
>  is disabled by default.  I consider this change a usability regression,
> and I don't want to be stuck with the appearance of the Redmond and CDE
> themes just to get it back.

actually, it's a usability improvement, and not one that was done to reach 
some sort of abstract usability purity but based users reporting it being a 
problem. many people double click almost at random on UI elements because 
they aren't sure when to single or double click (thanks to another poor 
usability choice); when they did this on the window menu *poof* the window 
would disappear, much to their surprise and consternation. it's invisible 
destructive behaviour that is accomplished by overloading a UI item. we do 
have a close button on windows for a reason!

so, while it's a feature change it's also a usability improvement; of course, 
those styles that mimic environments with that particular behaviour (MS 
Windows and CDE) keep it. kde should not be required to mimic poorly chosen 
behaviours in other environments simply and only because some people are used 
to it.

how difficult is it to click on the close button?

as for making it a configuration option, it's another familiar conversation:

 o it's a microconfiguration that therefore probably doesn't belong in the 
kwin decorations control panel
 o as such very few will use it
 o as such it adds more code and move runtime overhead just for those few 
people
 o it isn't an improvement, while this behaviour is available with certain 
decorations that maintain it for platform compatibility

> Also, it's rather counterintuitive that the actual behavior depends on the
>  theme in use.  Most people consider themes to be sets of icons and
> graphics -- eye candyb-- not fundamental behavioral changes.

this is obviously not how it works in KDE. different window decoration styles 
do indeed behave differently, and not just in this way. the buttons available 
vary, functionality like movable tabs or drag bars vary, etc... heck, some 
window decorations don't even *have* a window menu button. whether this is a 
good thing or a bad thing is debatable, i suppose, though personally i look 
at it this way: it ensures we allow different ways of working for different 
sorts of people, and each theme is self-consistent with the default theme 
being that which most people will use.

note that widget themes are similarly behaviour-dynamic.

on a side note, if you compile KDE (or even just the kwin decorations) from 
source the patch is trivial ...

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

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ki+Y1rcusafx20MRArbMAKCO0s56E9MJvbdn6h9XGyGNf3h2jwCfUyVC
Q+c8vhY0ZwJctmfABDdtEJE=
=O+k3
-----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]