This is a request for a feature found in Compiz (but broken in later versions, I think). When using "hot" corners and edges, instead of moving mouse to a corner/edge and having to wait the configurable number or milliseconds for the effect to take place, one could move mouse to corner/edge and click a (configurable) mouse button. Advantage: It is much faster to perform, so it makes for faster and more efficient use of the effects. This is very effective on a computer with a proper mouse, less so with a laptop touchpad. Reproducible: Always
I'm sorry, but this is a bad suggestion. Following Fitts's law (http://en.wikipedia.org/wiki/Fitt%27s_law ) it is very easy to move the mouse against the screen edge but it is extremely difficult to click at the mouse edge. Your suggestion would not make it easier but more difficult to hit the edges. If all you want to achieve is a shorter time for activation, please note that you can configure the activation delay.
That's too bad. I used this feature in Compiz absolutely all the time, and I can attest that clicking the edge is not "extremely difficult" but rather "extremely easy". Perhaps one in a hundred times I would "miss" (the pointer having moved back a pixel or two before clicking). I didn't use corners, so I can't comment on those. Thank you for the suggestion, but I don't like delays, neither long or short. Long delays are annoying to wait for, and short delays means the effect gets triggered by accident, which is also annoying. This was the one feature that kept me at Gnome2+Compiz for a long time. I don't regret moving to KDE, but I'm going to miss this feature a lot.
I'd say we actually need custom timeouts? Eg. one might want the electric borders to trigger by delay but have the corners (for certain effects as present windows) trigger immediately. Clicking is cumbersome and pot. dangerous because you need to ensure the pointer _is_ in the corner before you click or you might accidentally close a window (well, iff one maximizes windows, that is ... ;-) The autortrigger causes feedback itself w/o invoking any pot. dangerous actions and you can just keep moving the pointer until sth. happens.
Any kind of clicking anywhere on the screen is potentially dangerous in that sense, if there are two clickable targets in close proximity and one much less desirable to hit than the other. In real life clicking the wrong area of the screen rarely happens (in my experience). It also rarely happens on the edges (also in my experience). The one in a hundred estimate was much too generous, if anything. I read the wikipedia page on Fitt's Law. I can't see anything there to affirm the claim that clicking a screen edge is extremely difficult (which to me would be very counter-intuitive and contrary to experience). But, look. I don't want to come off as argumentative. This was just meant as a humble suggestion to improve kwin with a (in my view) awesome feature from Compiz. I accept that you think otherwise. If I was capable, I'd implement it and patch it for my own personal build (that's how much I miss it), but it would probably require much too much work.
> I read the wikipedia page on Fitt's Law. I can't see anything there to > affirm the claim that clicking a screen edge is extremely difficult (which > to me would be very counter-intuitive and contrary to experience). Oh that derives from the mathematics. For screen edges it says: "Edges and corners of the computer monitor are particularly easy to acquire with a mouse, touchpad or trackball because the pointer remains at the screen edge regardless of how much further the mouse is moved, thus can be considered as having infinite width" That is W is ∞ while for clicking W is 1 (width of the screen edge). This is also mentioned in the article: "This doesn't apply to touchscreens, though." In that regard using touch is the same as clicking. W is - given our implementation - also 1 and not as one would assume 0, but it's a little bit more difficult than clicking as a thumb is not as precise as a mouse. I want to thank you for your feature suggestion, but please understand that we add features based on what makes most sense for the majority of users. Keeping Fitts's Law out of mind we still have to face the issue that clicking a non visible target is a very bad UI for the average or beginning user. I understand that for you as a power user that might make sense but in general we focus on what is useful by most users. This we cannot figure out on the bugtracker, but we provide brainstorm.forum.kde.org for ideas.
*** Bug 304880 has been marked as a duplicate of this bug. ***
>I want to thank you for your feature suggestion, but please understand that we add features based on >what makes most sense for the majority of users. Keeping Fitts's Law out of mind we still have to face >the issue that clicking a non visible target is a very bad UI for the average or beginning user. I >understand that for you as a power user that might make sense but in general we focus on what is >useful by most users. Martin, consider that this might be an option. And from logic point of view you cannot say that this feature doesn't make sense. So it is logical that it makes sense. The question is for how many users? But how many users really need activities? If you don't want to do it, I will have to accept it, but I think that most users are not generally very active on forums or commenting bugs or requests so it is rather false assumption that not many users will use this. In fact we cannot predict this. To have valid predictions you would have to create a poll and ask every KDE user about their preferences, which still would be not very accurate because users can change their mind, change their behaviour over time. And in fact they do. I don't need activities but when they are on my KDE desktop ready to use, who knows, maybe I will try them and keep using them. So I think users use what they find practical and helpful. If you provide feature they will use it. Of course you can say that I can coordinate my movements more and move mouse to different area, but when I use different effect with different screen edges plus auto-hide panels it is really not very convenient to pay attention, remember where mouse can be moved so that other functions will not be activated by accident. >This we cannot figure out on the bugtracker, but we provide brainstorm.forum.kde.org for ideas. If it is already discussed here there is no point to move the discussion elsewhere.
> >This we cannot figure out on the bugtracker, but we provide > >brainstorm.forum.kde.org for ideas. > If it is already discussed here there is no point to move the discussion > elsewhere. it is not discussed on the bugtracker. We do not discuss feature requests here. If you want to have user feedback go to brainstorm. Here I will not comment any more unless someone comes with evidence that my concerns regarding Fitts's Law and clicking invisible targets are invalid. Please do not even think about trying to convince me that we should add an option for that. I'm not going to implement (nor allow to go in) an option which can lead to accidential closing of windows.
>Here I will not comment any more unless someone comes with evidence that my concerns regarding >Fitts's Law and clicking invisible targets are invalid. Your concern is invalid simply because - and here are arguments: 1) If this is not a default behaviour but just an option it is assumed that user knows what he/she is doing. 2) If the user need to mark an option to make it work it doesn't matter if it is visible or invisible target. In this case knows what he/she is doing. The same way you don't worry about active screen edges in general, which are invisible after all, because it is not activated by default. So the assumption is the same - users know what they are choosing and what behaviour they prefer so they don't complain later that something happened when they only wanted to close window - if they assigned an effect to the corner where they have close button. 3) If user don't like it he/she may switch it off. We are not talking about default behaviour. 3) If user will activate a corner opposite to the one were they have close window button nothing will be closed, so the simple rule here is don't use active corner where you have buttons and you will not experience a closed window, ever. No need to worry about it. You should not rely on some stupid logarithm. When users chose an option they are expecting to know how this option works. The low describes untrained movements, which means it doesn't apply to an option where you want the feature to work in a certain way and you train yourself to use it. http://en.wikipedia.org/wiki/Fitt%27s_law The wiki site that you refereed to doesn't say anything about invisible/visible thing. It doesn't even say anything about clicking on the screen edge. So you actually don't refer to any valid argument that would undermine the sense of click on the screen edge. If in your opinion it undermine the sense of click on screen edge it should consequently undermine also the whole idea of active screen edge. In my opinion the whole reference to this low is an invalid argument here. After all the low doesn't state: you cannot use active screen edge and click on it especially when you first chosen to do it by marking an option. That would be complete non-sense.
> Your concern is invalid simply because - and here are arguments: > 1) If this is not a default behaviour but just an option it is assumed that > user knows what he/she is doing. sorry and here you are wrong. This is the wrong argument for any option. And out of experience I can tell you that your assumption is just wrong. I don't have to comment on your other arguments as they are based on this one. Sorry I will never accept a possible harmful option which assumes that users know what they do.
>Sorry I will never accept a possible harmful option which assumes that users >know what they do. Are you telling me that I don't know what I do? That all I do on my desktop is just an accident and no purpose activity? It is certainly true that I didn't know all options at first before I tried them. But when I try I know how they work. And I know what I do on my desktop. It seems you want to protect users from themselves and you treat users like idiots. Maybe you didn't mean it to say it that way but believe me you don't have to protect users from their own actions. Users are responsible for what they do on their desktop. Mistakes happens but this is not a valid argument to prevent introducing new features just because someone may not know how to use them. Maybe after introducing a click on screen edge there should be a big capital letter warning next to this option: "Be careful - you may accidentally close your application if you click on the wrong corner." Or just when installing KDE: "Developers will not introduce new features because they are afraid that users don't know what they do." I am just joking now. :) Martin, I appreciate your work and work of all KDE developers and your concern about users but really there is no need to worry that much. We are not monkeys. :)
(In reply to comment #11) > >Sorry I will never accept a possible harmful option which assumes that users > >know what they do. > > Are you telling me that I don't know what I do? That all I do on my desktop > is just an accident and no purpose activity? no, and that's the problem here. You only think about you as a user, while I think about all users. We have millions of users and we don't add code for one or two users while it might be harmful for the majority of users. We know what will happen if we introduce such a feature. It is harmful and users will report bugs about it, they will complain loudly and they are right to complain. Please think what it means to the majority of users. So far your argumentation has only focused on what you need and assumed from you to other users. As I don't see that the discussion could improve I end it here.
How will, say, right clicking on a screen edge accidentally close a window? I guess it's possible, but that would have to be a very strange user configuration. As far as Fitt's Law is concerned, it seems to me that, to the degree that it applies at all, it states the opposite, namely that clicking the edge is clicking an "infinitely" large target, and hence extremely easy. That would agree with practice. No offense, but your insistence on the opposite looks to me a bit like someone claiming bumblebees in fact cannot fly, because "in theory" (an obviously incorrect theory) they shouldn't be able to. I feel a bit like an asshole for complaining, though. Kwin is a great piece of software overall.
I also don't complain. I like kwin. It was just a feature request. Kvaks, just post a branstorm idea on KDE Brainstorm forum and let users vote. I will.
> As far as Fitt's Law is concerned, it seems to me that, to the degree that > it applies at all, it states the opposite, namely that clicking the edge is > clicking an "infinitely" large target, and hence extremely easy. No, Fitts's Law is mostly about finding the hit target. That is a button positioned at a screen border is extremely easy to hit. A one-pixel border is not - maybe with a very precise input device. I would never trust a touchpad or a mouse to be that precise. A screen corner is clearly extremely difficult to hit. It's just one pixel, the screen borders do not help at all. This is also very important when considering this feature. The screen edge activation is for fast and easy activation through mouse movement where you don't have to be very precise. Just slam the mouse against the edge. The requested feature would not be easier to use but more difficult. This makes me doubt that you would be happy with the feature if it were implemented at all.
> Just slam the mouse against the edge. Yep, that's what I used to do in Compiz. I would throw the mouse pointer blindly to the right and right-click. Ultra-fast and ultra-easy way to trigger some window managing effect. Fantastic feature. Hardly ever a miss, never triggered unintentionally, and I never closed a window by mistake.
Can there be a few pixels made active like for example 5-10 pixels area in the corner? I don't understand the difference between just moving mouse when it is enough to have one pixel - I hit it more often than I want to - and a click on the same pixel. Maybe I am wrong but for me it feels like exactly the same movement plus a click. I just move my mouse to the pint where cursor doesn't move any more and this triggers the effect.
> Can there be a few pixels made active like for example 5-10 pixels area in > the corner? no! > > I don't understand the difference between just moving mouse when it is > enough to have one pixel - I hit it more often than I want to - and a click > on the same pixel. Maybe I am wrong but for me it feels like exactly the > same movement plus a click. I just move my mouse to the pint where cursor > doesn't move any more and this triggers the effect. The difference is that these are two different operations you have to synchronise. Just re-read what you just wrote: 1. move mouse 2. observe whether mouse still moves (go back to 1 if not) 3. click Complex, difficult, non-intuitive. The exact opposite to what the screen edges should be: easy to activate if you want to activate them.
>Complex, difficult, non-intuitive. Please, don't exaggerate. Both of us tell you that it is easy yet you still demonize it. Clicking never was difficult. Martin, how many votes on the brainstorm forum would convince you that users want it and have enough intelligence to use it without problems? Be realistic, don't expect millions.
a) you'll close maximized windows with close button on the clicked edge if you miss the pixel (with most decoration, that is - windows feature thing i think) b) the VAST majority of users is NOT capable of performing a click w/o moving the mouse. It's also nearly impossible w/ touching a touchpad. As if that wasn't enough, many cheap mice cause microjudder (while not being moved, the chip cannot decide for a position and jumps forth and back a pixel - this is a HW thing) c) increasing the hit area steals that space from interaction with regular windows, including their decoration - so you can not click a titlebar button covered by that area d) a click is an explicit action while moving is implicit. there are different requirements to what may be caused by either, esp. implicit reactions mJst be easily revertable. this implies different requirements on feedback as well - which is not present with a squarepx sized invisible point, therefore it should not alter the outcome of explicit interaction. e) never tried with compiz or whether it works atm. but did you ever consider that behavioral change was NOT a bug?
*** Bug 314350 has been marked as a duplicate of this bug. ***
Some comments for all above. In short: +1 for the feature. 1) The danger of window closing is absent with the configurable button to click. Such a selection was specified initially, BTW. 2) The Fitts's law seems staying pro this feature, not contra. Actually it is mentioned by the link above... > Edges and corners of the computer monitor [..] are particularly easy to acquire with a mouse, touchpad or trackball because the pointer remains at the screen edge regardless of how much further the mouse is moved, thus can be considered as having infinite width. So the common case is when you just throw the mouse "somewhere in that direction" and then click when you are sure it's there. No need of precise positioning and movement control, by the same law. That's why such a feature is cool, as for me. Even more, it would be interesting to have customizable actions for such a triggers (several buttons at the same edge do different actions) but let's leave it for now. 3) The active zone with 2-4 pixels should be enough, I think. If somebody would really suffer from the step-back pointer move (and therefore leaving the active zone), it could be eliminated by making a click while keeping mouse moving. Current switching requires that too. 4) Touchpads shouldn't be a blocker (together with new users)—just disable it by default. Same for active edges in a whole, as it isn't a good feature for beginners, IMHO.
Final comment from me on this bug: Fitts's Law make it pretty clear that clicking a screen border is difficult. Just take the formula and enter the the values. Hitting a screen edge with the mouse means your hit target is infinite, but clicking the hit target is just one. That's kind of the worst thing one can imagine. And no that won't be added (not even with a config option) and even if someone would come and provide a patch I would veto it based on Fitts's Law.
Final or not but let's see on the equation. I wonder why my feeling differs from that math. T = a + b * log(2)(1 + D/W) Note: we are taking into account T includes the click time too ("a" constant), so T is the total time to trigger the action. "a" and "b" are constants, "D" could be taken as, say, 20 units and "W" is infinite. Note: infinite, and not one pixel because of the edge case. So: T = a + b * log(2)(1 + 20/inf) = a + b * log(2)(1 + 0) = a + b * 0 = a. And this is the best possible case, at least for the mouse-like device—movement could be ignored and just the click time matters. Please correct where I'm wrong.
Your feeling falls short on : "and then click when you are sure it's there" to be more precise: "when you are sure it's there" As mentioned before, there's no feedback on that state - you are not sure that the cursor covers the invisible 1px² before you click. Simple as that. Instead you have to move the mouse, check precisely that the cursor is on the edge and then click. As you spotted correctly, the move time can be ignored (it's also the same for the click and nonclick variant) and only the actual click AND (you skipped that) the position time matter. The click (press) is neglectable (~50ms for and average user press, 100ms for a complete click) but the perception time ("when you're sure") is not. It's the expensive part which also demands your focus. Right now, you can just move the mouse and at some point get the action. You don't even have to follow the cursor. Now reg. the "false positive" claim i suspect you actually "abuse" this request in order to solve another problem (hide the cursor) wrongly? There's "unclutter" and if you want i can hand you a 2liner c code to show/hide the cursor (which you could bind to a shortcut and if this is the cause)
Sorry, but I ~always sure that cursor stopped at the edge. Of course it wouldn't be possible with 1px line in any other area, but in case of the edge feedback isn't really required and just two conditions seems enough: 1) Some practice with mouse device to get basic prediction skills. 2) Move mouse with the extra part, say ~1.5-2 times longer than usually. Click while moving. I can't imagine the realistic reasons to fail in this case. And you don't have to follow the cursor too. Regarding the position time, I'm not sure I understood why it differs from the move part. The formula consists of two summands and move / positioning part tend to zero for our case. So, T ≈ a. Regarding false positives I meant just an unexpected switch triggering. It happens for me sometimes with the current case. The reason seems that you really need to ensure you've stopped the pointer before the edge for another operations. Otherwise (if you keep it moving for some time) it will trigger the switch.
(In reply to comment #26) > I can't imagine the realistic reasons to fail in this case. And you don't > have to follow the cursor too. Yes you do, since the *least* reverse movement (minor judder of your hand) will move the cursor away from the edge again. > Regarding the position time, I'm not sure I understood why it differs from > the move part. There's a difference betwenn moving and positioning. Moving is uncontrolled and fast and completely irrelevant here at all. Positioning is slow, since it requires a control system. Move, check, move, check, move, check - hit. This does not account the additional costs to perform the press/click (without accidentally moving the mosue) itself. > The reason seems that you really need to ensure you've stopped the pointer > before the edge for another operations. Otherwise (if you keep it moving for > some time) it will trigger the switch. And how would that change the elast if you trigger with the click? I mean, "another operation" will include a click, likely to use the scrollbar, yesno?
(In reply to comment #27) > Yes you do, since the *least* reverse movement (minor judder of your hand) > will move the cursor away from the edge again. Sorry, but I still can't. It could be a problem when the pointer isn't moving, but how the step back is possible _while_ moving the mouse forward? > There's a difference betwenn moving and positioning. > Moving is uncontrolled and fast and completely irrelevant here at all. > Positioning is slow, since it requires a control system. > Move, check, move, check, move, check - hit. The second summand of Fitt's formula include all of that time (move+check), isn't it? And it tends to zero here. > This does not account the additional costs to perform the press/click > (without accidentally moving the mosue) itself. Sure, it's the first constant ("a"). > And how would that change the elast if you trigger with the click? > I mean, "another operation" will include a click, likely to use the > scrollbar, yesno? It includes a click in, say, 50% of cases. Sometimes it's just moving the mouse either to the better position on the table or away from some widget. Switching is quite unexpected in this case and will be eliminated by click option entirely. Another part of cases (which include a click) could be resolved by configurable button. For the right button similar tasks could be opening desktop context menu or clock settings in the tray, but I don't think they will be really overlapping here. And usually there is a third button too, etc.
More important than the math is the actual evidence of in-use experience, subjective and anecdotal it may be. Look, I don't underestimate the importance of math (I'm a mathematician, so I clearly wouldn't), but if one fails to connect the correct mathematical model in the correct way to the real world phenomenon one wants to understand, then the exercise is a failure. I believe Martin fails in this manner here. His understanding of how the math applies to this feature is contrary to my understanding, but more importantly starkly in contrast to my actual real-world experience. The action described is extremely fast and easy to perform (and very useful), with near-zero chance of doing something undesirable. Martin is the maintainer and developer, and if he's so vehemently opposed to the feature, then that's his prerogative. But his stated reasons leave me shaking my head. And declaring that a patch by anyone else would be refused leaves me unmotivated to embark on a project to implement it myself (which would probably be too large a task anyway).
As for me, I don't even see an math problem here (some computations are above). Seems like it approves the easiness. And I've been using such a feature for some time and it was quite a good one.
T = a + b*ID ID is common for both variants and converges to zero anyway, thus "a" is the only relevant variable and it is clearly "0" for the non clicking variant and is whatever time > 0 you require to - ensure the cursor is really in/on the edge (however you might do that) - perform a controlled click on the spot (from the WP article: "The constant a can be thought of as incorporating reaction time and/or the time required to click a button") Comment #26 suggests that you clearly understood that. (In reply to comment #28) > Sorry, but I still can't. It could be a problem when the pointer isn't > moving, but how the step back is possible _while_ moving the mouse forward? a) the corners are reached by moving along the x and the y axis and your efforts moving along X can harm the Y position (because if you're a human, you move the mouse within an arc) b) a way to unintentionally harm the cursor position is to lift the mouse what also impacts full edges (esp. a problem for touchpads and trackballs) c) HW issue, the cam in the mouse assumes a contermove depending on the underground. > > There's a difference betwenn moving and positioning. That was meant on terminology. I assumed you took the terms equal. To bring my personal opinion into this: having "switch desk on edge wheel only" is fine (wheeling is hardly destructive and easily reversible) but acting on clicks on invisible areas is *absolutely* not and violates *everything" in terms of HIG (despite buttons are clearly visible, they also provide visual feedback on hover - not without a reason) Whether this particular actions takes the user longer or not (it obviously does), i actually don't care (his/her time) the least, but "click this invisible thing you assume to be there and get some action out of it" is seriously braindead stupid GUI and no way an option from my position.
(In reply to comment #31) > ID is common for both variants and converges to zero anyway, thus "a" is the > only relevant variable and it is clearly "0" for the non clicking variant Agree, and since switch delay are usually >≈ click time, it could be assumed they are equal and Fitt's law doesn't tell anything bad about any of the cases. > and is whatever time > 0 you require to > - ensure the cursor is really in/on the edge (however you might do that) I don't check for that, but let's leave that on my own and just keep the above math in mind (we've put on it a lot). > a) the corners are reached by moving along the x and the y axis and your > efforts moving along X can harm the Y position (because if you're a human, > you move the mouse within an arc) It's OK, the arc should end at the edge. > b) a way to unintentionally harm the cursor position is to lift the mouse > what also impacts full edges (esp. a problem for touchpads and trackballs) Agree, but small lifting of the mouse while movement (not after) shouldn't break the main behavior. And the big lift could break any action. Regarding touch UI, I'm not considering this feature for it. There are really some problems which are absent for the mouse. However this shouldn't be a strong objection---as for me, KDE have chosen the best way to be used on both desktops and tablets. It wouldn't be nice if it would change to the common "touch mostly" way. > c) HW issue, the cam in the mouse assumes a contermove depending on the > underground. Even if it happens, this countermove will be immediately eliminated by further movement in the initial direction. This is why I referred to the such cases on-the-go. > wheeling is hardly destructive and easily reversible Same as for the subject case, as for me. And I have wheel option disabled due to lower usability (it should be done at specific widgets) and false positives too. There are a lot of opinions. > but acting on clicks on invisible areas > is *absolutely* not and violates *everything" in terms of HIG (despite > buttons are clearly visible, they also provide visual feedback on hover - > not without a reason) Firstly the Fitt's law, then the HIG... Buttons aren't the only possible interactive control. OK, you've expressed your opinion.
I can't believe that with so many options available, clicking on a screen edge isn't an option, and with such adamant revulsion of it. The Fitt's Law reference does not apply to this, and let me explain why. The very reason why moving the mouse to the edge of the screen is an easy act is also why CLICKING the mouse on the screen edge is easy. You simply fling the mouse there and push a button. Getting the mouse there is easy, because you can't go past the edge. Clicking a button is easy because we've been doing it since mice were invented. And here is why users (like myself) prefer click-activate on edge rather than timeout: 1). Accidental activation. A common mode of operation for a computer is to accelerate the cursor to the edge closest to the thing you want, then backtrack with finer granularity. It's like ice skating - it's quicker to just skate across the rink, stop at the boards, then skate 1 foot back again than to try to stop on a dime without hitting the boards. 2). The timeout. To try to mitigate the accidental activation, there's a timeout. Great. Now I have to WAIT for my computer to do something I could have told it to do. I have always had the edges of my screen set with a click trigger to move to the next desktop, and a slight delay when dragging a window to move the window to the next desktop. It's a very intuitive system, and it makes it very quick to do mouse-only navigation of homescreens by just clicking through them right on the screen edge. Developers are certainly within their rights to not want to implement a feature, but the reasons given are not valid. "We don't use it and don't feel like implementing it" is the real reason here.
Fitt's law is imo a minor aspect on this (despite I disagree on the idea to apply the infinite area on a click, see various posts on why) See comment #20 on why I personally believe that this is a completely stupid idea. You're likely just looking for "unclutter" (hides the cursor), but another and safe solution would be to add (a panel and) a button to trigger whatever you want.
> a) you'll close maximized windows with close button on the clicked edge if you miss the pixel (with most decoration, that is - windows feature thing i think) And similarly, if you miss the maximize button, you'd be triggering whatever action just requires putting the mouse into the corner. When you have a few different things in a close space, you have to be more careful. The difference is that I'm not going to click the mouse on maximize unless it's on the maximize button - and I'm not going to click to activate the corner action unless the mouse is in the corner. With just motion actions, I could be aiming for the maximize button, but trigger the other action instead. And if that action is something like Expose, it's very jarring when you're aiming for the corner of a window and suddenly all the windows move around. > b) the VAST majority of users is NOT capable of performing a click w/o moving the mouse. It's also nearly impossible w/ touching a touchpad. As if that wasn't enough, many cheap mice cause microjudder (while not being moved, the chip cannot decide for a position and jumps forth and back a pixel - this is a HW thing) I'm not sure I buy that statistic, especially since we are talking about edge pixels. I've been using compiz with the edge-clicking on a touchpad for years and haven't had any problems. People who don't want those actions or don't have the hardware or motor skills to handle it should probably not enable it. > c) increasing the hit area steals that space from interaction with regular windows, including their decoration - so you can not click a titlebar button covered by that area Sure. Same with corner activations without clicking. Except that if both actions up in that corner are clicks, they only "steal" the actual space that is defined for them. With motion actions, just getting the mouse up there count trigger one. It's "stealing" the ability to even come near the corner of the screen. It's like saying the sidewalks take away valuable road space, but having sheer cliffs on either side of the road is ok. > d) a click is an explicit action while moving is implicit. there are different requirements to what may be caused by either, esp. implicit reactions mJst be easily revertable. this implies different requirements on feedback as well - which is not present with a squarepx sized invisible point, therefore it should not alter the outcome of explicit interaction. I think that explicit vs implicit hits the nail directly on the head as to why people want this ability. Some actions SHOULD be explicit, like switching desktops. > e) never tried with compiz or whether it works atm. but did you ever consider that behavioral change was NOT a bug? It works marvelously, but Compiz has aged out since it doesn't mesh well with gnome3 or KDE. For me, the switch to KDE was begrudgingly, but it's a lot nicer than gnome3, and I'm doing what I can to tweak it to be the way i want it. This is one of those tweaks that I was confused to find missing, since I've had it for years with compiz. > You're likely just looking for "unclutter" (hides the cursor), but another and safe solution would be to add (a panel and) a button to trigger whatever you want. I don't understand what hiding the mouse cursor has to do with this at all, actually. Unless it also does something else? Actually, I like that side-panel idea a lot. The panels can't be made very narrow, and don't have per-panel color settings (so I can't make it more transparent). I'm not sure there are any widgets that can be set so that clicking them is a shortcut for an action, but if that exists, I think that would be a good-enough workaround. I would likely set it to be behind windows, since the only time I use that is when I don't have a maximized window anyway. I very rarely maximize windows, which maybe is why I see no problem with contention for clicking on the edges and corners. I haven't found out if this is an intentional "feature" or a strange bug, and whether it is in KDE, my input drivers, or X itself, but the mouse does not easily go to the edge pixel on the screen. When I move it to the corner it stops at 1,1 and won't move to 0,0 - same with the other side. It's as if it snaps back to 1px whenever I go to 0. This makes activating the corners and edges quite difficult, as I need to "keep going" rather than staying still to activate it. The longer the delay the harder it is to activate, since it will pop back out. I'm not sure if that strange behavior makes it better or worse. It would make it much harder for a click-to-activate to function on the edges, but it makes it harder to accidentally activate the hover actions. Unfortunately, it's also harder to *intentionally* activate the edge actions as well. It looks like in the end it still comes down to preference, like you said - that you personally believe it's a dumb idea. There are a lot of options in the settings menu that I think are stupid, and I just don't tick those boxes. There are plenty of ways to shoot yourself in the foot and make things behave poorly or conflict with eachother, and it's up to the user to decide which dumb thing they like best. I've also mapped the Meta key by itself as well as with a modifier, which I know drives many people completely bonkers. Too bad, it's my computer, I'll do what I want with it :-)
(In reply to comment #35) > > a) you'll close maximized windows with close button on the clicked edge if you miss the pixel (with most decoration, that is - windows feature thing i think) > > And similarly, if you miss the maximize button You're not suggesting your maximize button would be one invisible px², are you? > I'm not sure I buy that statistic, especially since we are talking about > edge pixels. Edge pixel does not matter - the move is uncontrolled. Of course thsi does not hold for ppl. who spent years in ego-shooters. Yet, i can't perform an unmoved click by tapping a touchpad. > > c) increasing the hit area steals that space from interaction with regular windows, including their decoration - so you can not click a titlebar button covered by that area > > Sure. Same with corner activations without clicking. Which is 1px, ie. the absolute minimum. And you can't do anything else on that px either - but can get to any pixel touching it. Moving the mouse to such pixel is as hard with as without corner activation and as hard as pointing any particular pixel. So you say the 1px dead area is already bad and making it even bigger would be an improvement? I don't follow that logic. > I think that explicit vs implicit hits the nail directly on the head as to > why people want this ability. Some actions SHOULD be explicit, like > switching desktops. Use the mouse wheel anywhere on the desktop? We're talking about screen borders in general here - if you don't like electric borders to switch the desktop, just don't set them to do so. > I don't understand what hiding the mouse cursor has to do with this at all, > actually. Unless it also does something else? The general abuse of moving the mouse into a corner is to "hide" it. > windows, since the only time I use that is when I don't have a maximized > window anyway. I very rarely maximize windows, I like that attitude, but if you don't maximize and mostly care about chaing VDs, i'd suggest to wheel the mouse instead and spare edges/corners for sth. better in the first place. ----------- > I haven't found out if this is an intentional "feature" or a strange bug, > and whether it is in KDE, my input drivers, or X itself, but the mouse does > not easily go to the edge pixel on the screen. Pushback. During the timeout the pointer is pushed away from the corner/edge so you've to forcefully move it there. Hints that you really want to go there and not just pushed the mouse with your ellbow. You can lower the Activation delay to 0 in "kcmshell4 kwinscreenedges" Also ensure the re-activation delay is somewhat bigger than the activation delay, see bug #323588
> And similarly, if you miss the maximize button > You're not suggesting your maximize button would be one invisible px², are you? No, I'm suggesting that if you're a pixel off, you'd hit the wrong thing. If you accidentally hit the maximize button by being a pixel off, you could just as easily be a pixel off in the other direction. Or worse, actually, since the corner activation currently doesn't even require a click - just trying to maximize often activates the corner action. > Edge pixel does not matter - the move is uncontrolled. Of course thsi does not hold for ppl. who spent years in ego-shooters. So you agree, then, that since edges are "uncontrolled" that it's very easy to hit them. The fact that it's hard for people to exactly aim for 1px and click on it without moving the mouse has exactly nothing to do with edge actions. > Yet, i can't perform an unmoved click by tapping a touchpad. Use a button, then? People use lots of different input devices, each with different strengths and weaknesses. They select the workspace behavior they desire based on the input device. > Which is 1px, ie. the absolute minimum. And you can't do anything else on that px either - but can get to any pixel touching it. Try to get to 1,0 without touching 0,0. > Moving the mouse to such pixel is as hard with as without corner activation and as hard as pointing any particular pixel. Not true. Corners and edges are easier, we've already established that. > So you say the 1px dead area is already bad and making it even bigger would be an improvement? I don't follow that logic. No, I'm saying that the dead pixel in the corner is already "dead" since you can't go there without triggering a potentially unwanted action. In fact, you can't even go NEAR the corner, because of the inaccuracy of pointing. I am saying that having a motion-trigger in the corner is more likely to be accidentally triggered than a click action. And thus, having a motion action means that there is a larger area that you need to avoid than with a click action. I don't know if I can explain that more clearly. Imagine if you set your corner hover action to "reboot" and compare that to having the corner CLICK action set to "reboot". If it was just the click action, you could still use everything in that corner and it would be really unlikely to accidentally trigger it. But with the motion action, you would rage-quit after the tenth time your computer reboots on you. Thus, you would be unable to do anything in that corner, making it effectively "dead" space. > Use the mouse wheel anywhere on the desktop? We're talking about screen borders in general here Oh, I hadn't tried that action, that could work. It's hard to get a single mousewheel click on my trackpad, but if I have an external mouse that will work well. >if you don't like electric borders to switch the desktop, just don't set them to do so. I *do* like them, I would just prefer it to be an explicit action instead of implicit. > The general abuse of moving the mouse into a corner is to "hide" it. People seriously do that? I only just now realized that the cursor doesn't hide itself while typing. I personally don't care if the cursor is visible or not, and I don't think it has anything to do with this. If a person wants to be able to put their cursor in the corner of the screen without an action, they would simply disable the action. >I like that attitude, but if you don't maximize and mostly care about chaing VDs, i'd suggest to wheel the mouse instead and spare edges/corners for sth. better in the first place. If not for the trackpad being bad at exact scrolling, I like the workaround. >Pushback. During the timeout the pointer is pushed away from the corner/edge so you've to forcefully move it there. Hints that you really want to go there and not just pushed the mouse with your ellbow. You can lower the Activation delay to 0 in "kcmshell4 kwinscreenedges" Also ensure the re-activation delay is somewhat bigger than the activation delay, see bug #323588 I'm getting more used to the "move mouse to the edge, then push further" action. I think that may actually end up working better in the end, but I still get a lot of unintended edge action that would not be there if a click were required. And that pushback is certainly the reason why edge and corner click won't work. I had zero problem getting the mouse to edge and corner pixels with compiz, but compiz doesn't have pushback. Trying to click on a corner or edge pixel is easy, but trying to continuously move the mouse diagonally to hold it over the pixel resisting pushback and click at the same time is hard.
(In reply to comment #37) > No, I'm suggesting that if you're a pixel off, you'd hit the wrong thing. And that (prevent accidents) is why any reasonable click target is considerably larger than 1px², what means the invisible 1px² in the corner is not a reasonable click target - what is my point. > > Edge pixel does not matter - the move is uncontrolled. Of course thsi does not hold for ppl. who spent years in ego-shooters. > So you agree, then, that since edges are "uncontrolled" that it's very easy > to hit them. The accidental mouse move on click is uncontrolled. There was no mention to "edges" or whatsoever. On the contrary: I explicitly said that the edge condition does not matter. > The fact that it's hard for people to exactly aim for 1px and > click on it without moving the mouse has exactly nothing to do with edge > actions. No, it has everything to do with this. In particular to keep the pointer absolutely steady when performing the click. > Try to get to 1,0 without touching 0,0. Hitting a particular pixel *is* hard - we completely agree here. It's possible though. > Not true. Corners and edges are easier, we've already established that. We were referring to the 1,0 or 0,1 or 1,1 case and explicitly not the corner. Moving the cursor into a corner is simple, clicking that corner without accidentally moving the mouse is as hard as clicking any pixel w/o accidentally moving the mouse and getting the mouse to a particular non-corner pixel (even adjacent to the corner) is incredibly hard. The only relevant of those questions here is whether a) you can be sure to cover exactly the corner pixel right before clicking b) you will not accidentally move the mouse while clicking Esp. for a touchpad i'd claim the answer to be "no, you can't" and "yes, you will". > I don't know if I can explain that more clearly. Imagine if you set your > corner hover action to "reboot" and compare that to having the corner CLICK > action set to "reboot". In either case, i'd have to not have any interest to interact w/ the mouse anyway near that corner - far too dangerous. Your case here is that you want to bring the mouse *very* close to the corner w/o causing an action by accidentally reaching the corner. My point is that you should not have any interest in clicking the pixel near the corner pixel if the corner pixel acted on click, because you will either accidentally click the corner when wanting to click the pixel next to it or accidentally click the pixel right next to the corner when you wanted to click the corner. So the strategy is to keep the corners for relatively harmless actions, triggered on entering them, so if you got a reboot button right next to it, you can be sure that you'll reboot when clicking there - and if you accidentally leave that ("huge") button onto the corner pixel, you can rather easily move back. > People seriously do that? Yes. I think it was often mentiond wrt flash. > I only just now realized that the cursor doesn't hide itself while typing. Depends on the client. Eg. konsole hides it quite oftenly. > If not for the trackpad being bad at exact scrolling, I like the workaround. I heard that before. It's likely reasonable to have a setting about the scroll distance and or timeout (dead time between 2 triggers) to cause a VD change. (plasma, desktop containment) - though touchpad wheels are in general no suited for distinct wheel action (eg. over comboboxes etc.) However, if i had the choice between a touchpad and a keyboard shortcut (kcmshell4 keys, select kwin and filter for desktop), i'd certainly go for the latter (eg. Meta+Arrow keys) > And that pushback is certainly the reason why edge and corner click won't > work. If the edge would react on clicks, a pushback would not be required. But just to make this clear: You cannot click into a window below the corner pixel. The event goes to kwin and stops there. There's no point in clicking into this edge.
> The accidental mouse move on click is uncontrolled. There was no mention to "edges" or whatsoever. Let me clarify, then. The MOUSE will move when you click, but the CURSOR will not, as it is constrained in 1 or 2 directions by the limits of the screen, thus making it quite simple to hit the location you meant to. > On the contrary: I explicitly said that the edge condition does not matter. And I say it DOES matter. Clicking on an edge or corner pixel *is* *significantly* *easier* than clicking any other pixel on the screen. The study didn't look at that, perhaps, but that is truth. Clicking on an edge or corner pixel is EASIER than any other pixel. Same with aiming. It's easier to aim for a corner or edge, because there's a backboard. >In either case, i'd have to not have any interest to interact w/ the mouse anyway near that corner - far too dangerous. And this is how the rest of us feel about the automatic corner actions. > Your case here is that you want to bring the mouse *very* close to the corner w/o causing an action by accidentally reaching the corner. My point is that you should not have any interest in clicking the pixel near the corner pixel if the corner pixel acted on click, because you will either accidentally click the corner when wanting to click the pixel next to it or accidentally click the pixel right next to the corner when you wanted to click the corner. You're making the point that it's not a good idea to have clickable buttons too close to eachother while justifying how it's ok to have non-clickable actions in the same place. If you think it's too easy to click the wrong place, then it's CERTAINLY too easy to move the mouse into the wrong place. > So the strategy is to keep the corners for relatively harmless actions, triggered on entering them Actually, the corners are programmable for any number of actions, harmful or not. It's up to the user to decide what they want to trigger. I would say "lock screen" is pretty harmful a corner action, as it has a significant time cost in undoing. > so if you got a reboot button right next to it, you can be sure that you'll reboot when clicking there - and if you accidentally leave that ("huge") button onto the corner pixel, you can rather easily move back. I'm still not following. You're saying that the risk of accidentally clicking the corner pixel is too high, but the risk of moving the mouse into that pixel is not? In the venn diagram of things that can happen, ALL CLICKS INVOLVE THE MOUSE BEING IN THAT PIXEL. That means that no matter how risky you think that it is going to be to accidentally click on that pixel, it is not one iota less risky than having the mouse move into that location - because you cannot click on a pixel without first moving the mouse there. > People seriously do that? Yes. I think it was often mentiond wrt flash. What does flash have to do with mouse cursors? > I heard that before. It's likely reasonable to have a setting about the scroll distance and or timeout (dead time between 2 triggers) to cause a VD change. (plasma, desktop containment) - though touchpad wheels are in general no suited for distinct wheel action (eg. over comboboxes etc.) Right. Even if I could change it to only register distinct clicks, I wouldn't want to, for the loss of the ability to scroll quickly (its main purpose, after all) > However, if i had the choice between a touchpad and a keyboard shortcut (kcmshell4 keys, select kwin and filter for desktop), i'd certainly go for the latter (eg. Meta+Arrow keys) That's a cool story, but your preferences are not and should not be forced upon all users. I also use a keyboard shortcut to switch desktops, and I switch between which one I am using based on whether my hand is currently on keys or on the touchpad. > If the edge would react on clicks, a pushback would not be required. But just to make this clear: You cannot click into a window below the corner pixel. The event goes to kwin and stops there. There's no point in clicking into this edge. Except that those clicks are exactly what this bug entry is about. There is a point, it's just not an action that can currently be mapped to anything.
>> In either case, i'd have to not have any interest to interact w/ the mouse anyway near that corner - far too dangerous. > And this is how the rest of us feel about the automatic corner actions. Exactly. In general, I remember the xkcd strip with "just add an option" but all the current topic is a certain case for this, as for me.
Re the edge click target argument. I cannot but suspect that some misunderstand the feature proposed and how it's actually used on Compiz. First note that myself and other users of the Compiz feature know from experience that it is very easy to perform. If you are arguing that it is very difficult, you haven't tried it and/or you misunderstand. Sorry, but when "theory" so strongly disagree with practical experience, the theory is wrong. So here's what typically happens when performing the edge click: You throw your mouse to the edge of the screen and click. That's it. You're not aiming for and trying to stop the mouse cursor at the outermost pixel. I can definitely see how that would be difficult. You'd typically also NOT be moving the mouse to the edge, then pause for a bit and then click. I can see how the cursor might move back a pixel or two in that case. It's move-click in one gesture and it works at least 99% of the time (in Compiz). And it's a super useful feature if your hand is already on the mouse.
Please stop arguing for it, you won't convince us to implement it. It's free software and you can try to provide a patch - git.reviewboard.kde.org will happily accept it and then we can look at the implementation. But please don't argue for us to implement it. Patches welcome.
If the original response to the feature request had just been "We're not going to do it because it's too hard to do without breaking the way edge and corner detection works. Also, we don't really like it", that would have been the end of it. The only reason this thread blew up is because of the asinine and invalid excuses as to why it can't or shouldn't be done. None of them are true. It's not the feature being argued for, it's the reasons against it being argued against. And while I agree with the mentality of "it's open source, if you want it so badly, write it yourself", I don't believe for a second that a patch for that feature would be accepted, given how much opposition there is.
(In reply to comment #43) > The only reason this thread blew up is because of the asinine and invalid > excuses as to why it can't or shouldn't be done. None of them are true. FALSE: I DID AND DO BELIEVE THAT THIS IS COMPLETELY BRAINDEAD AND STUPID FOR THE REASEONS I MENTIONED SEVERAL TIMES! There you got it, you made me shout.
> I DID AND DO BELIEVE THAT THIS IS COMPLETELY BRAINDEAD AND STUPID FOR THE REASEONS I MENTIONED SEVERAL TIMES! What you believe and what is fact are not aligned. Sorry you feel that way.
> What you believe and what is fact are not aligned. Sorry you feel that way. Jeff, please - on our side it's not believe it's in fact something one could call "experience" out of years working on the window manager and seeing usage interactions go wrong. By continuing that thread you won't convince us. And even if you could convince us to say "ok, our argumentation is wrong", we would still not implement it. If you hope for us to implement it, the argumentation is wrong. I offered a compromise by saying someone else can implement it. You can accept this offer or not. Of course I cannot guarantee that we would accept a patch because it needs to go through review.
Ok, let it make me more clear then: A user interface that requires you to click an invisible tiny area while general and pot. destructive input processing is *obviously* so stupid that i cannot even imagine how one could possibly come up with that. Moving around the cursor can in general be considered harmless, and any client that starts irreversible action by that can reasonably be considered broken. So it can safely be interpreted for undestructive and reversible actions (hovering stuff, even kicking you into "present windows" or changing virtual desktops - while i would not use the latter myself) Pressing the mousebutton is a distinctive action that clients reasonably take as explicit "the user knows what he does" action. This is guaranteed by a visual feedback where you can *see* that the mouse is over a button etc. (ideally stressed by a nice hover feedback) and a "safety" padding: you'll move the button near the center of a 100x20px button, so a minor shift when clicking has no impact. The *invisible* screenedges do not provide any such visual feedback (the "approach" glow obviously hints different and is only available with compositing) and there is not the least safety padding. There is also no example for a common 1px² clickarea nor for invisible clickareas - because this is plain stupid by any common sense. Did I make myself clear enough? Also just stating your opinion -without any reason- as fact does not make it that. It makes you entering a childish "you're wrong! no you're wrong!" game that i will certainly not play.
Martin, I agree with what you're saying. I'm just explaining why there's so much disagreement. it's not that people disagree with the fact that it's not going to be implemented. In fact, I'm quite certain now that it won't be. Myself and others just disagree with the assessment that it's "too hard" to click a screen edge, since it's something we're already used to on other systems, or it never would have even been suggested. Thomas, I'll respond to your points in-line: > A user interface that requires you to click an invisible tiny area while general and pot. destructive input processing is *obviously* so stupid that i cannot even imagine how one could possibly come up with that. But a user interface that requires that you navigate to an invisible tiny area is not stupid? I'll remind you that this interface feature already exists in KDE. > Pressing the mousebutton is a distinctive action that clients reasonably take as explicit "the user knows what he does" action. This is guaranteed by a visual feedback where you can *see* that the mouse is over a button etc. (ideally stressed by a nice hover feedback) and a "safety" padding: you'll move the button near the center of a 100x20px button, so a minor shift when clicking has no impact. Again, there is already corner and edge detect actions, which happen to actually have that nice visual hover feedback already. > The *invisible* screenedges do not provide any such visual feedback (the "approach" glow obviously hints different and is only available with compositing) and there is not the least safety padding. I see no technical reason why such visual feedback could not exist. And the safety padding is not needed as the feature works perfectly fine without it. You have never tried it, clearly. > There is also no example for a common 1px² clickarea nor for invisible clickareas - because this is plain stupid by any common sense. You calling it stupid does not make it stupid. As has been stated many times in this thread, this feature already exists in other window managers and works just fine. Thus, to call it "common sense" is a fallacy. There are a lot of people using that feature that disagree with your assessment. > Also just stating your opinion -without any reason- as fact does not make it that. It makes you entering a childish "you're wrong! no you're wrong!" game that i will certainly not play. I never said that my opinions were fact, just that yours are not.
> You calling it stupid does not make it stupid. As has been stated many times > in this thread, this feature already exists in other window managers and > works just fine. Thus, to call it "common sense" is a fallacy. There are a > lot of people using that feature that disagree with your assessment. We are not here to copy any feature Compiz ever invented. Just because Compiz had it doesn't mean that it's a good idea - in many cases it's rather the opposite. Compiz developers told me in person how awful it is that they have more combinations of options than there are atoms in our solar system. We can then think about what that means to the maintainability of a project and start to wonder why Compiz got kicked from all distros except one, has lost all developers and will not port to Wayland and which window manager is alive and kicking and able to answer users in bug reports.
> We are not here to copy any feature Compiz ever invented. Certainly not. Compiz only came up as an example of this feature being possible and perfectly functional. > Just because Compiz had it doesn't mean that it's a good idea - in many cases it's rather the opposite. Compiz developers told me in person how awful it is that they have more combinations of options than there are atoms in our solar system. We can then think about what that means to the maintainability of a project Maintainability of code and configuration options has nothing at all to do with whether a UI feature is good or bad. Sure, having too many options makes code harder to maintain, and when there are options that require a lot of extra work that are not used by the majority of users, it makes perfect sense for those options to be cut. On the other end of the spectrum is Gnome3, however - an interface where ALL the configuration options have been eliminated. I'm sure it looks great for code maintainability, but from a user perspective it's boring. Unless your preferences happen to match the exact use case it was designed for. There's a happy medium in there, for sure. KDE actually has a LOT of options for just about everything I could want to configure, with the exception of this and the ability to use the superuser key to trigger an action while still retaining its use as a modifier (fixed using xcape to remap it). Actually, that Windows-Key feature has a very similar situation. It's a feature people are used to using because it exists in other desktop environments (Windows, Gnome3), and despite being against some UI rule somebody made up, people like it. > and start to wonder why Compiz got kicked from all distros except one, has lost all developers and will not port to Wayland and which window manager is alive and kicking and able to answer users in bug reports. Project management and code quality has nothing to do with whether a UI feature is good or bad. It's kicked from distros for stagnating, which is hardly uncommon. It's been years since there's been an update, and there were a lot of unfinished and buggy things about it. I can say for certain that KDE is far more friendly and stable than compiz ever was and despite the minor differences, I'm still quite happy with it. This was never about Compiz vs KWin, this was just talking about a specific UI feature that happens to exist in Compiz. I'm not sure I buy that edge-click actions resulted in the downfall of the project. I *can*, however, completely understand that such a feature would be very difficult to implement cleanly in KWin, and could potentially break other features or lead to code that is much harder to maintain. I can also understand that a feature like that should not be a default setting . Those are very good reasons to not want a feature.
> I *can*, however, completely understand that such a feature would be very > difficult to implement cleanly in KWin, and could potentially break other > features or lead to code that is much harder to maintain. I can also > understand that a feature like that should not be a default setting . Those > are very good reasons to not want a feature. And that's also the case. The code for screen edge handling got rewritten about a year ago by myself. Some of the reasons were that it is: a) too complex b) too many options You can see that I would be very reluctant to add more options to it. As that resulted in the situation that we needed to rewrite (see the reference to Compiz I brought up - many options lead to complex code, making it difficult to maintain, resulting in bitrot). The code is also not ready at all to have mouse click interaction and would need significant changes to the event handling to pass mouse clicks on, filter them out before it goes into other parts
(In reply to comment #42) > please don't argue for us to implement it. Patches welcome. As for me, patches are useless if (any) upstream is clearly against a specific change. I think...
> > please don't argue for us to implement it. Patches welcome. > > As for me, patches are useless if (any) upstream is clearly against a > specific change. I think... We won't implement it. If there are patches which show us that all our concerns were wrong, we can reconsider our opinion. If we say no, you can still fork KWin (that should be easy in the days of git) or convince your distribution to ship the patch. Maybe they see it differently. Writing a patch is clearly the better way to show us to be wrong than to spend hours on arguing.
(In reply to comment #53) > We won't implement it. If there are patches which show us that all our > concerns were wrong, we can reconsider our opinion. Hm, concerns here are mostly related to UI/UX/design topics and not to technical implementation. This is what I mean under the small use of patches for such a cases. OK, anyway I have no Qt/KDE coding experience to make such a changes.
hard requirements from my POV: - when the active area is entered it has to grow from 1px width to eg. 4px ("safety" padding) - at least w/ compositing, there should be a(n optional) hint that the click will be intercepted by the active border ie, "one shall see what one clicks" and "one shall not be punished for minor errors" If Martin accepts a patch that turns an invisible 1px² into a mouseclick UI, I could hardly (and would not) oppose, but i'd not stop calling that stupid either.