+1

+1

I realized that there's yet another problem with the approach: if two windows border and the window with pointer focus is lower in the stacking order this would create a dead zone in the window. With compositing disabled this would be worse as there's not even a visual hint.

I really need to urge vdg to rethink all of that. I have a really bad feeling about turning no borders on by default. Please reconsider.

There are two visual hints when the mouse is inside the deadzone.

You would still get the different cursor
The client gets the mouse left event and would not show any hover effect on whatever control might be there.

Does this/should this also implement the diff from D13278?

In D13481#279575, @davidedmundson wrote:

There are two visual hints when the mouse is inside the deadzone.

You would still get the different cursor
The client gets the mouse left event and would not show any hover effect on whatever control might be there.

Which might already be problematic. E.g. for things like first person shooters (please don't tell me that nobody would use a fps in windowed mode. This is an example for problems with the dead zone). Basically we break the complete idea of window snapping.

I don't like this change. I fear it will create much harm for questionable visual improvements. I recommend against this.

What is the problem with an FPS in windowed mode? If anything, the potential problem would be a windowed RTS or other game where you're expected to move the view by touching a window edge. But even in this case, the "dead zone" is outside the window rather than inside it, so that critical pixel is always available to the game, and I don't see what the issue is. I sometimes plan Endless Sky windowed with No Borders and I've never encountered a single issue related to the dead zone. Can you clarify which potential issues you're worried about?

The dead zone exists if you have a focussed lower stacked client.

i.e
set window A to always on top
put window A right next to window B (our FPS)
focus window B
move the mouse to the edge between A and B but still slightly over B
input is not given to B, it is given to the resize handle of A

Right. That's not a workflow I think I've ever seen anyone do with a windowed game. For anyone who wants to do that, they can always turn the borders back on. Or just resize one of the windows slightly so the dead zone doesn't overlap the game window. Or not try to play a windowed game right next to a window that's explicitly marked as always on top. Or any number of other very simple tweaks.

I don't think it makes sense to focus on 0.01% corner cases in the process of determining sensible default settings. Defaults should be good for 80-90% of people, and changeable for the rest. Supporting games in adjacent/tiled lower-focused windows underneath top pinned upper windows feels like it's pretty squarely in that minority group where we can feel comfortable saying, "if you need to do this, here is the setting or slight workflow (gameflow?) tweak you can change to make it happen."

FWIW when I enabled borderless windows for these patches to test out the first time ever, I once tried to click in the dead zone to activate the window below and then was for a moment annoyed that it didn't work.

After this one "incident" I can't remember any other time it disturbed my work flow though. Probably because one adapts internally pretty quickly to "if you want to control the window below the active one, there is this dead zone, don't click there". Or maybe because it just happens very seldom that one tries to click in the very small dead zone area.

What I thought of as a solution back when it happened was to check if it's a single click on the dead zone without mouse movement, then activate the window below. Since if you want to use the virtual border, you would move the mouse after press to drag. Not sure if it's worth it since as said, never disturbed my work flow afterwards again.

In D13481#280767, @romangg wrote:

What I thought of as a solution back when it happened was to check if it's a single click on the dead zone without mouse movement, then activate the window below. Since if you want to use the virtual border, you would move the mouse after press to drag. Not sure if it's worth it since as said, never disturbed my work flow afterwards again.

What you propose is an intriguing idea and I rather like it. Might be a nice little touch. That said, macOS has had borderless windows and an external resize area since OS X Lion (released in 2011) and even they don't implement anything like that. Clicks get eaten in the "dead zone" there too.

Since that time--and including 7 years working as an Apple engineer--I don't recall encountering a single a piece of negative user feedback about this. I don't think it's an issue in real life. So your proposal is certainly a "nice-to-have", but I don't think it's a "must have" before we can proceed here.

+1 I've been using borderless windows all the time since I came back to KDE Plasma and haven't had any workflow issues.

In D13481#280754, @ngraham wrote:

Right. That's not a workflow I think I've ever seen anyone do with a windowed game.

Did you read my comment? Let me quote: "please don't tell me that nobody would use a fps in windowed mode. This is an example for problems with the dead zone"

To everyone here: you are extremely experienced developers and software users, partially working in the window manager area. Of course you understand why the dead zone happens and of course you are able to adapt to it. But please think of your users. I fear they won't understand it. Also with click the dead zone might be obvious. With just mouse hover it might not. Please try not to argument for this strong behavior change with anecdotal evidence like "I use this for years".

In the end it comes down to form follows function. I think that this is a case where the impact of functionality change is large and thus form needs to follow. Futhermore I have to say that my proposals I did in the task are also not going to solve it. After thinking more and more about it I see mainly an issue with resize outside the window and the impacts it has. My ideas there also tried to use it and thus are not a solution.

In D13481#281295, @graesslin wrote:

In D13481#280754, @ngraham wrote:

Right. That's not a workflow I think I've ever seen anyone do with a windowed game.

Did you read my comment? Let me quote: "please don't tell me that nobody would use a fps in windowed mode. This is an example for problems with the dead zone"

I understand that you gave an example to illustrate the point rather than to focus on the details of the example, but your choice of example supports my argument that any potential issues here represent tiny 0.01% minority cases that it doesn't make sense to fixate on for the purposes of determine what a good default is. As you've often pointed out, you can't please everyone--nor should you try. In this case, we wouldn't even be saying, "sorry, KWin doesn't support that." Instead we would be saying, "if you want to do that, you can make it happen with any of several very simple tweaks."

I also pointed out that in my prior professional experience working on another platform that has the exact behavior (macOS), I'm not aware of a single user complaint regarding your concerns. I also mentioned that I approve of Roman's proposed fix, which would solve the issue (if any).

Hopefully that clears things up a bit.

the dead zone is actually a point.. tough that's a thing that a big company would have an actual usability testing lab for . To me is very probably something that doesn't get even noticed (i always had side borders disabled but now that i read here of the issue is the first time i notice it at all, even if knowing the implementation i must have known this had to happen, didn't help me to notice that it happened at all)
As a big test, i don't see much way besides doing a (non lts) release with it and see how is received.. i would love to be able to have proper usability testing sessions.. but we don't have such a thing (maybe a tiny version of it could be set up at kde booths of non kde-only events we have a presence in

Please don't play with the users. I would have never pushed a change to test how things work. They are not our testbed. That it worked on other platforms doesn't mean a thing. Maybe that other platform cannot even run into the dead zone situation.

My point is: this is a behavior change which affects users and thus is not for the VDG to decide on. This is something so far the VDG declined. I'm not in a position anymore to block it, but as maintainer I would have blocked this change for the dead zone effect. That's just an unacceptable behavior chnage.

Other platforms, which have virtual border and no real borders around windows, do they also have the deadzone? Is it known to be a usability problem for users of these platforms?

In D13481#282096, @romangg wrote:

Other platforms, which have virtual border and no real borders around windows, do they also have the deadzone? Is it known to be a usability problem for users of these platforms?

Yes, macOS and GNOME have exactly the same visual appearance and behavior. Windows 10 has a single-pixel border and the same behavior.

I agree with Martin that whether or not something is present on other platforms should not in and of itself be used as evidence; what if they're all doing it, but they're all wrong? We have to look at the actual usability consequences too. In the absence of a formal usability testing lab (something we'll never have), we can rely on our own judgment and reasoning, and we can attempt to determine the magnitude of user complaints about the feature on other platforms.

Regarding our own judgment: Every affected workflow I can think of is uncommon and has a trivial workaround. This is even more so on our platform since we'd actually keep the ability to turn borders back on to eliminate the dead zone for anyone people who commonly use an affected workflow. Agreeing with Martin again, defaults aren't about pleasing everyone; they're for ensuring a good experience for the common user, while preserving the uncommon user's ability to tweak things to their satisfaction.

Regarding user complaints: of all the complaints people have levied against macOS, GNOME, and Windows over the years, I don't think I can recall a single one about no click-through in the dead zone.

Again, I also support Roman's proposed click-through idea.

In D13481#280767, @romangg wrote:

What I thought of as a solution back when it happened was to check if it's a single click on the dead zone without mouse movement, then activate the window below. Since if you want to use the virtual border, you would move the mouse after press to drag. Not sure if it's worth it since as said, never disturbed my work flow afterwards again.

how difficult is to implement? would just bring the window forward, or actually pass the click? (ie, if there is a button under that dead zone, it should be clicked)

In D13481#282653, @mart wrote:

In D13481#280767, @romangg wrote:

What I thought of as a solution back when it happened was to check if it's a single click on the dead zone without mouse movement, then activate the window below. Since if you want to use the virtual border, you would move the mouse after press to drag. Not sure if it's worth it since as said, never disturbed my work flow afterwards again.

how difficult is to implement? would just bring the window forward, or actually pass the click? (ie, if there is a button under that dead zone, it should be clicked)

Completely different code paths on X11 and on Wayland. We don't have any click handlers, only pressed and released. So it's not a was this a click thing, we need to learn what a click is.

Given that it requires different implementation for X11 and Wayland and this clearly would be a new feature the X11 Feature freeze rule would kick in and then we have different solutions for X11 and Wayland. So overall I would rather say: too difficult and too breakage risky.

I think we should go back to the drawing board and think about what really is wanted and needed. I want to remind that the original idea was to still have round corners. As I said a few times: this is not the change vdg wants. So let's not try to make something work which the vdg doesn't want. Let's provide them the solution for their actual needs instead.

In D13481#282788, @graesslin wrote:

In D13481#282653, @mart wrote:

In D13481#280767, @romangg wrote:

What I thought of as a solution back when it happened was to check if it's a single click on the dead zone without mouse movement, then activate the window below. Since if you want to use the virtual border, you would move the mouse after press to drag. Not sure if it's worth it since as said, never disturbed my work flow afterwards again.

how difficult is to implement? would just bring the window forward, or actually pass the click? (ie, if there is a button under that dead zone, it should be clicked)

Completely different code paths on X11 and on Wayland. We don't have any click handlers, only pressed and released. So it's not a was this a click thing, we need to learn what a click is.

Given that it requires different implementation for X11 and Wayland and this clearly would be a new feature the X11 Feature freeze rule would kick in and then we have different solutions for X11 and Wayland. So overall I would rather say: too difficult and too breakage risky.

I think we should go back to the drawing board and think about what really is wanted and needed. I want to remind that the original idea was to still have round corners. As I said a few times: this is not the change vdg wants. So let's not try to make something work which the vdg doesn't want. Let's provide them the solution for their actual needs instead.

Let me help here. The VDG actually discussed this, not sure if it was on this ticket, but we came to the conclusion that having round corners is not a "must". We are OK to have squared bottom corners is the technology is not there yet and we favor having no borders first. I ask to please cease discussion on this and start testing the breakage that is alluded here so that we know what will happen.

I ask, at the same time, to stop bringing up new arguments against this patch and focus on moving forward. It seems to me that every few days some new idea of a possible problem is explained to have the team desist from this change. That needs to stop if we want to move forward. We can help.

In D13481#282788, @graesslin wrote:

I think we should go back to the drawing board and think about what really is wanted and needed. I want to remind that the original idea was to still have round corners. As I said a few times: this is not the change vdg wants. So let's not try to make something work which the vdg doesn't want. Let's provide them the solution for their actual needs instead.

Please don't put words in people's mouths.

What VDG wants is for KWin to not draw camouflaged side and bottom borders in Breeze. VDG wants this because the borders are holding back design flexibility and causing visual problems for many apps (including quite a few of our own). VDG is willing to lose the rounded bottom corners as a consequence of this change.

Given that the "dead zone" issues that have been brought up are minor, easily worked around, represent mostly niche use cases, and are also present on every other platform out there, I really don't think it's a deal breaker if we can't implement Roman's idea.

Here's a realistic scenario for the "Dead Zone Problem":

I had quick-tiled two windows next to each other on the desktop. In the left-hand window, I had a scrollable list. The right-hand window was a text editor. I was going through the list on the left, and turning it into prose writing in the editor on the right. Since I was typing into the editor, the right-hand window was usually raised. This meant its dead zone overlapped the scroll bar of the left-hand window.

At some point I wanted to use the scroll bar and couldn't, without going out of my way to raise the left-hand window first.

This was a bit annoying, and doesn't seem very uncommon to do.

Nate, I cannot believe what I read here. Every week you do a blog post about usability. In other reviews you draw the usability card so often that it annoys me. And here you want to break user setups and break with "form follows function". This is absolutely unbelievable to me.

Do what you want!

This one is definitely tricky. I don't think it's insurmountable to track whether there's movement or not prior to a release, and if not, raise the lower window and synthesise press+release events to send to it. But it would't completely eliminate the dead zone problem, for example it wouldn't fix the case I wrote about above: In that case I expected the usual raise on press to happen and then be able to immediately move the scrollbar thumb. The best we could do with the distinguishing trick is to enable click-raise, which is still inconsistent behavior.

In short: I'm getting more and more worried that breaking mouse input to an adjacent window is not OK, because there's often scrollbars there which use drag too.

I'm on board with removing the borders, just wondering if things like this will be changed:

Dolphin has nice spacing with borders:

https://ibb.co/eur6tU

With no borders it's way too close to the edge:

https://ibb.co/gwXCYU

Yes, the plan was (is?) to make the content area touch the window edge with no separation at all, the way it does in for example apps on GNOME, ElementaryOS, Cinnamon, Windows, and macOS, not to mention our own Kirigami apps and some non-Kirigami apps like Konsole and Okular

@romangg @hein @mart @davidedmundson @abetts we had some discussions about this at Akademy and if I recall, someone came up with an interesting solution to the "dead zone" problem; does anyone remember what it was? I'm still not convinced that this issue is a hard blocker, but I would be all for trying our best to address it if it helps us move forward.

I think we were able to identify the issues, even the ones pointed out in the discussions earlier in this ticket. I feel that we have a path forward.

Well I gotta say this (https://ibb.co/deWY8U) looks gorgeous, no blue line around the white box, everything is simple and really elegant, it would be awesome if dolphin actually looked like that.
Sorry for getting off topic.

Yep, that's more or less the idea! :)

Plasma is already my number one but I do notice inconsistencies here and there and getting something like in that picture would really be amazing.
Thanks for your work!