Version: (using KDE KDE 3.1.1) Installed from: Gentoo Packages Compiler: gcc 3.2 OS: Linux 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. 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 the reason I still use CDE actually. I'd more than love to see this reimplemented.
Subject: Re: Fwd: [Kwin] New: double click in title bar menu icon doesn't close window 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, First of all, thanks for taking the time to respond. I appreciate your attention even though we have a legitimate difference of opinion. > actually, it's a usability improvement And while we're on the subject, vi is more usable than emacs. :) Seriously, though, one person's improvement is another's regression. Now, if I were the only person who thought so, I would just patch my own copy of KDE and let it go. But this a complaint I see coming up again and again on the comp.windows.x.kde newsgroup. These are the cases where a preference is called for, (IMHO) because there are clearly substantial numbers of people who feel strongly both ways. (see comment #2 for another example) Also I think the case for this particular preference is made stronger by the fact that it was normal behavior in previous KDE releases, as opposed to some random new feature request. > of course, those styles that mimic environments with that particular > behaviour (MS Windows and CDE) keep it. Actually, I would be okay with that philosophy if it were applied a little more consistently. IceWM (which I have been happily using for a long time before trying out KDE) has this behavior, so I would happily consider this bug resolved if the IceWM themes did this. :) Along the same lines, the KDE2 theme probably should as well, since, well KDE2 users would be used to this too. And maybe others, I haven't tried every system out there... > this is obviously not how it works in KDE. different window decoration > styles do indeed behave differently Well, one humble user disagrees that this is how it should be, but I won't press this point any further. > on a side note, if you compile KDE (or even just the kwin decorations) from > source the patch is trivial ... Point noted, thanks for the advice.
Subject: Re: double click in title bar menu icon doesn't close window On Monday 07 April 2003 8:10, you wrote: > > actually, it's a usability improvement > > Seriously, though, one person's improvement is another's regression. Given that, and at least I and Tom here both agree that double-click to close are good features, and definitely not usability regressions, perhaps it'd be wise to make it optional? I have never seen anyone who would even consider double clicking there, ever, but I'd be happy to just see it optional. - -Charles
Created attachment 1322 [details] fix for IceWM and KDE2 themes Patch for IceWM and KDE2 themes.
A couple of notes about my patch: This patch only affects the KDE2 and IceWM clients, both of which historically have the double click to close behavior, and thus seem to be justified by the comments that Aaron posted. For both, I added a checkbox into the theme-specific preference tab to enable/disable double click to close, and the default is disabled (KDE 3.1.1 behavior) Is this a reasonable compromise?
Created attachment 1323 [details] fix for IceWM and KDE2 themes 2nd try, using gzip wasn't such a good idea...
Subject: Re: Fwd: [Kwin] New: double click in title bar menuicon doesn't close window I agree mostly with what you're saying here, Aaron. A compromise plan is to allow the user to have multiple close buttons on the titlebar. That way, those who want the double-click close over on the left side can still have what they want. I've always found it rather strange that one could not have more than one of any button. Naturally by default, we wouldn't have any duplicates, but IMHO it would be quite convenient to have the minimize, maximize, close on both the left and right sides of a window. --- "Aaron J. Seigo" <aseigo@olympusproject.org> wrote: > -----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 __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
*** Bug 53486 has been marked as a duplicate of this bug. ***
I like to reduce the number of widgets on the window title bar, and removing the close widget and using a double click to close windows is fine with me. Actually, since I rarely use the menu anyway, it provides a sort of safety against unwanted window closes.
Aaron sais: > o as such very few will use it On what facts do you base this claim and how do you explain the many votes and duplicates on this bug? Usually, I'm no big double-click fan, but this is a special case because closing a window is both a very often needed and a destructive action. That's why I like to be able to close a window on both upper edges, especially on the left where the mouse-pointer tends to be more often. I'm also one of those who uses the CDE-theme because it's one of the 2 available themes that offers this. Unfortunately both (Redmond and CDE) do not come with a "sticky" button which I would also like. In desperation I tried all window decoration, but no luck. What would be even better and would really improve the situation would be the availability of one or 2 fully configurable themes (preferrably the default and the klassic theme) which also offer full configuration of buttons.
Subject: Re: double click in title bar menu icon doesn't close window On Monday 28 April 2003 12:54, you wrote: > I'm also one of those who uses the CDE-theme because it's one of the 2 > available themes that offers this. Unfortunately both (Redmond and CDE) do > not come with a "sticky" button which I would also like. In desperation I > tried all window decoration, but no luck. Finally, someone else who values usability over appearance! -Charles
Subject: Re: double click in title bar menu icon doesn't close window 10:12, luned
well, do whatever you want. it's really not worth my efforts to try and make KDE more usable if that means constantly arguing the bleeding obvious with people everytime their pet feature changes. the fact is that overloading a GUI element is bad and down right stupid when it's a destructive action. the fact is that people DO close their windows by accident because of this. theory predicts it, and i've witnessed it occur with my own eyes more than once. the fact is that FEW people have noticed, let along complained, that this behavior has changed. that does not mean that FEW people have benefitted, especially since those who benefit are likely the least to notice the change. the fact that FEW people complain is significant, however, since its a fairly visible change to those who had grown used to this interface mistake. the fact is that adding a configuration option to control the behaviour of a double click on one button in a window title bar is insanity. the fact that there are dozens of other settings for window behavior does not make it right; in fact it lends weight to the concept that we shouldn't make the matter worse. there has not been a single sensicle argument for keeping the double click closes behaviour that doesn't boil down to, "i'm used to it that way". but whatever. take KDE even further into the configuration hell hole and add an option to every single window decoration and their corresponding configuration page in the Window Decorations / Configure tab. just please keep it OFF by default. i'm sure the addition of this is as an option will make a dozen or so people in the world happy.
Created attachment 1469 [details] Implement menu dblclick action for the b2 theme It works as it is now, but may be cleaned up a bit. In particualr, I have the sensation that widgets should be autodeleted by the parent widget, however in the original config panels, all widgets are explicitly deleted by the destructor.
This behaviour being optional and off by default is ok with me. All I want is being able to use it. In fact, I am using it right now. This option makes kwin more usable for me, and for others, apparently. And I don't see how an option buried in the third tab of a configuration panel, that is off by default could reduce usability.
This is the second most voted whish for kwin, by the way.
I think the idea of canceling double-click close is a good idea. However, there is a compromise solution which would not involve adding a new UI option. All we need to do is allow the user to have more than one button of each kind. As it is now, I love having a close button on the left side but miss it on the right. It makes more sense to allow the user to put the close buttons wherever he or she pleases. In fact, why do we even have the control menu at all? It's totally useless since the exact same functionality can be achieved with Alt-F3 or mod-click on the titlebar.
FWIW, my $0.02 as a humble user: Aaron J. Seigo is 100% right. If I could spend some of my votes as negative votes that subtract from this item I would do it.
I found this feature very useful and I do not see why it was removed. Think to people who have this reflex and add it back to KDE ! Thanks.
ok, have restored emulation behaviour for KDE2 and iceWM styles to bring them in line with other emulation styles. the rest will remain as is.
Since keramik is pretty wide used, it should offer the choice to the user as a configuration check box. And redmond style should have this by default, I think. Even since I dont really care about this style.
oh sorry for this second posting but it appear that redmond style already as it as default behaviour.