D13481: Recommend window border size "None"

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  For the record. As far as I can tell, MSWindows(r) decorations do not have 
"no borders". They have a 1 pixel dark border (that blends with the shadow), on 
all sides. This essentially fixes all the regressions that this patch 
introduces, that were mentionned by several kde contributors, and essentially 
ignored. 
  I am still strongly against this change.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg, ngraham
Cc: hpereiradacosta, pedrogomes1698, hein, januz, ngraham, davidedmundson, 
graesslin, abetts, mart, plasma-devel, LeGast00n, ericadams, jraleigh, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D13481: Recommend window border size "None"

[Roman Gilg]

This revision was automatically updated to reflect the committed changes.
Closed by commit R31:e15989fb1f0d: Recommend window border size 
None (authored by romangg).

REPOSITORY
  R31 Breeze

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13481?vs=36009=59296

REVISION DETAIL
  https://phabricator.kde.org/D13481

AFFECTED FILES
  kdecoration/breeze.json

To: romangg, #plasma, #vdg, ngraham
Cc: pedrogomes1698, hein, januz, ngraham, davidedmundson, graesslin, abetts, 
mart, plasma-devel, LeGast00n, ericadams, jraleigh, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Pedro Gomes]

pedrogomes1698 added a comment.


  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!

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: pedrogomes1698, hein, januz, ngraham, davidedmundson, graesslin, abetts, 
mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


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

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: pedrogomes1698, hein, januz, ngraham, davidedmundson, graesslin, abetts, 
mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Pedro Gomes]

pedrogomes1698 added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: pedrogomes1698, hein, januz, ngraham, davidedmundson, graesslin, abetts, 
mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Andres Betts]

abetts added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: pedrogomes1698, hein, januz, ngraham, davidedmundson, graesslin, abetts, 
mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: pedrogomes1698, hein, januz, ngraham, davidedmundson, graesslin, abetts, 
mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Pedro Gomes]

pedrogomes1698 added a comment.


  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

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: pedrogomes1698, hein, januz, ngraham, davidedmundson, graesslin, abetts, 
mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Eike Hein]

hein added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: hein, januz, ngraham, davidedmundson, graesslin, abetts, mart, 
plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  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!

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: hein, januz, ngraham, davidedmundson, graesslin, abetts, mart, 
plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D13481: Recommend window border size "None"

[Eike Hein]

hein added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: hein, januz, ngraham, davidedmundson, graesslin, abetts, mart, 
plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Andres Betts]

abetts added a comment.


  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. Let's be daring with change!

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Marco Martin]

mart added a comment.


  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)

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Roman Gilg]

romangg added a comment.


  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?

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Marco Martin]

mart added a comment.


  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

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  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"

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Diego Gangl]

januz added a comment.


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

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: januz, ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Roman Gilg]

romangg added a comment.


  FWIW when I enabled borderless windows for these patches to test out the 
first time ever, I 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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


  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."

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[David Edmundson]

davidedmundson added a comment.


  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

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


  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?

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Nathaniel Graham]

ngraham added a comment.


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

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: ngraham, davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[David Edmundson]

davidedmundson added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: davidedmundson, graesslin, abetts, mart, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Martin Flöser]

graesslin added a comment.


  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.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: graesslin, abetts, mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Andres Betts]

abetts added a comment.


  +1

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: abetts, mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, sebas, apol

D13481: Recommend window border size "None"

[Marco Martin]

mart added a comment.


  +1

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13481

To: romangg, #plasma, #vdg
Cc: mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol

D13481: Recommend window border size "None"

[Roman Gilg]

romangg created this revision.
romangg added reviewers: Plasma, VDG.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
romangg requested review of this revision.

REVISION SUMMARY
  Adds a recommendation of border size "None" for the new KWin mechanism, which
  allows window decoration plugins to recommend a size for KWin's auto border
  size mode.
  
  We want our default session with Breeze to have no window borders in order to
  reduce visual clutter, make it look more in line with current design trends
  and have cross platform apps look more native, in particular Kirigami apps.
  
  This is a solution for T8707 .

TEST PLAN
  Manually with patches to KWin. More testers desirable, needs a fully refreshed
  build of Breeze, otherwise the new property is not part of the compiled shared
  library for some reason.

REPOSITORY
  R31 Breeze

BRANCH
  recommendBorderSize

REVISION DETAIL
  https://phabricator.kde.org/D13481

AFFECTED FILES
  kdecoration/breeze.json

To: romangg, #plasma, #vdg
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart