D13481: Recommend window border size "None"

[Andres Betts]

abetts added a comment.


  In D13481#282788 <https://phabricator.kde.org/D13481#282788>, @graesslin wrote:
  
  > In D13481#282653 <https://phabricator.kde.org/D13481#282653>, @mart wrote:
  >
  > > In D13481#280767 <https://phabricator.kde.org/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20180625/2d856fb1/attachment-0001.html>