> On May 15, 2013, 8: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 ;) > >
> 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. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/#review32545 ----------------------------------------------------------- On May 15, 2013, 12:35 a.m., Albert Vaca Cintora wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110430/ > ----------------------------------------------------------- > > (Updated May 15, 2013, 12:35 a.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
