> On May 15, 2013, 6:06 a.m., Aaron J. Seigo wrote: > > I am not in favour of this patch for a couple of reasons. First, there is a > > port underway to QML which does not need to be delayed further by adding > > more features. More importantly, however, "middle click" is a special case > > of "not the first two mouse buttons" (should we support N button mice?) and > > it adds yet more configuration to an already complex and full configuration > > dialog. It also conflicts with the meaning of middle click to expand / > > collapse groups (a fairly hidden feature I also was not particularly happy > > with tbh). > > Albert Vaca Cintora wrote: > Hello Aaron and thank for your reply. > > Let me defend the inclusion of this patch from the problems you mention: > > - Difficulty to port to QML: This feature is implemented in a ~10 lines > switch (not counting the GUI-related code), so porting it should not be a > problem (I could do it, if needed). > > - Support for N button mice: The desktop should adapt to the current > hardware, and nowadays most mice have 3 buttons (not N, but neither only 2). > Moreover, lots of apps have adopted the behaviour of closing tabs with a > middle click, so adding this feature for applications in the taskbar is > consistent with them. > > - Complexity of the configuration dialog: I agree that we should try to > keep all the configuration dialogs simple, but not adding new features > because of that reminds me of Gnome3 ;) I think this is not solution for the > long-discussed problem of the user-friendliness. > > Finally, and more important, it has 2 open bugs (+ 4 duplicates) so there > are real users requesting it. If it's not going to be added, those bugs > should be marked as wontfix. > > Aaron J. Seigo wrote: > "porting it should not be a problem (I could do it, if needed)." > > that is definitely a point in your favor. assuming this feature addition > is accepted: there's little point to putting it in the c++ version, however, > only to put it later in the qml version (which is supposed to be in 4.11). so > putting it directly in the QML version would make the most sense. > > "Moreover, lots of apps have adopted the behaviour of closing tabs with a > middle click" > > to point out the obvious: windows are not tabs. this also implies that > middle click to close is actually a *good* feature. i think it is for power > users .. but i have seen too many instances where these kinds of magic "click > that button and magically something happens" features lead to confusion, and > confusion leads to distrust of the system as a whole. > > yes, the default is to do nothing in your patch (+1 for that), but if > sitting down to someone else's system results in wildly unpredictable > behaviour .... ... keep in mind this is not a random component, but a default > part of every plasma desktop installation, so it has to work better than most. > > how much faster is middle click versus right-click->close? fast enough to > warrant the risk of surprising behaviour for people who aren't expecting it? > > "Complexity of the configuration dialog: I agree that we should try to > keep all the configuration dialogs simple" > > currently that page has 11 settings. ad-hoc testing i've done in the past > hints that many of these settings are already not understandable to many > users. i really don't want to make this worse. several of the plasmoids have > "room" for more options. the taskbar, folderview, clock and system tray are > four that really don't. adding feature over feature is leading to an > increasing mess that nobody cares to clean up. > > if this patch introduced a re-think of the configuration presentation so > that it is easier to understand and more approachable, i would consider that > a fair trade for accepting a feature i'm not particularly in favour of :) > > "but not adding new features because of that reminds me of Gnome3" > > for future reference: when i see this kind of statement made, i usually > add -1 to my overall weighting. i do not agree with many design decisions in > other projects, but design can not be done well if it is primarily directed > by "not being that other group". common sense and reasoning should be applied > to each case without the justification of "not like them", otherwise we just > create the opposite kind of error. > > "it has 2 open bugs (+ 4 duplicates) so there are real users requesting > it." > > for any product with a large enough user base, given enough time and an > open feature request tracker, any possible feature will be requested (usually > multiple times). this means that any feature, regardless of intrinsic value, > can be justified using this argument. > > (the least useful case of this i've seen is when people submit the > feature request, then later a patch and then use the feature request as > evidence it is wanted ;) > > > > Martin Gräßlin wrote: > > if this patch introduced a re-think of the configuration presentation > so that it is easier to understand and more approachable, i would consider > that a fair trade for accepting a feature i'm not particularly in favour of :) > Just an idea: an own tab called "Mouse Actions" and make it visually > similar (or best reuse) the mouse actions dialog of Plasma desktop. I'm not a > fan of using the middle mouse button as it has a very defined behavior on X11 > (copy/paste selection) and the close on middle click violates that. A user > might expect that it pastes the current selection into the window and not > closing the window. So I'd rather like to see it use the extra buttons. > > But anyway, I think it should be done in the QML version and that's at > least with QtQuick1 still rather limited for mouse button use. So that's more > a point for QtQuick2.
Aaron: I don't agree with your focus on unexperienced users because I think that what makes KDE awesome is its 'tweakability' for power-users, while having a good by-default settings for normal users (that won't even open the configuration dialog). I'm sorry you didn't appreciate my joke regarding Gnome 3, but I really think their way is not the good way in terms of usability (applying all the common sense that I can apply) and that KDE should try to avoid going in the same direction. However, I don't want to discuss any longer about usability here, since it has already been long discussed in more appropriate places. Maybe we can chat about it in the next Akademy? :) Martin: In KDE3 this feature was like you are saying, configurable for each of the buttons: It was customizable to the point you could make your primary button open the context menu and your middle button raise the app, or any other combination. I don't think we need that crazy (and unmaintainable) level of customization that KDE3 had, but something in between. I will follow the QML port of this applet and see if I can help there. If no more comments are added in the next days, I will close this review board. Please mark the bug reports as wontfix to prevent people creating new patches for them. - Albert ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/#review32545 ----------------------------------------------------------- On May 14, 2013, 10:35 p.m., Albert Vaca Cintora wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110430/ > ----------------------------------------------------------- > > (Updated May 14, 2013, 10:35 p.m.) > > > Review request for kde-workspace and Plasma. > > > Description > ------- > > This patch adds a feature present in KDE3 and requested by some users (see > open bugs), that is performing an action when a taskbar entry is > middle-clicked. I have added three possible actions: Close the application, > hide it or move it to the current desktop, where the first two were user > requests. > > > This addresses bugs 182689 and 190951. > http://bugs.kde.org/show_bug.cgi?id=182689 > http://bugs.kde.org/show_bug.cgi?id=190951 > > > Diffs > ----- > > plasma/desktop/applets/tasks/tasks.h fe79a12 > plasma/desktop/applets/tasks/tasks.cpp 0a86dcf > plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff18 > plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 > > Diff: http://git.reviewboard.kde.org/r/110430/diff/ > > > Testing > ------- > > Manual testing. > > > Thanks, > > Albert Vaca Cintora > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
