Turn off the extended resize handle/black triangle when there are no borders
ClosedPublic

Authored by ngraham on Jun 2 2018, 1:36 AM.

Details

Summary

As discussed and agreed to in T8707: Window borders, turn off the black triangle that's currently drawn by default when windows are drawn with "No Borders"

Test Plan
  • Tested on a new user: no black triangle when KWin's border setting is "No Borders"
  • Tested on an existing user who had DrawSizeGrip=false in their breezerc file: no change
  • Tested on an existing user with who had DrawSizeGrip=false in their breezerc file and then turned it on in System Settings: black triangle appears as expected
  • With the black triangle on, reset to default settings: works as expected

Diff Detail

Repository
R31 Breeze
Branch
turn-off-black-triangle (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
ngraham created this revision.Jun 2 2018, 1:36 AM
Restricted Application added a project: Plasma. · View Herald TranscriptJun 2 2018, 1:36 AM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
ngraham requested review of this revision.Jun 2 2018, 1:36 AM
ngraham edited the summary of this revision. (Show Details)Jun 2 2018, 1:37 AM
abetts accepted this revision.Jun 2 2018, 1:40 AM
This revision is now accepted and ready to land.Jun 2 2018, 1:40 AM
romangg accepted this revision.Jun 3 2018, 3:04 PM
romangg added a subscriber: romangg.

I think this should land independently of the other diffs. I've always used the Normal border size in the past, but now trying out "No Borders" with my patch I don't see the reason for painting this handle. Is there any reason to keep this default as it is?

ngraham edited the summary of this revision. (Show Details)Jun 3 2018, 3:05 PM
ngraham added a subscriber: hpereiradacosta.

Same here, I always turn it off too. Of course since this is a Breeze change, I'll want to make sure @hpereiradacosta is okay with it.

hpereiradacosta added a comment.EditedJun 3 2018, 3:21 PM

Long time ago, you could not resize windows from outside the window area. So when switching to no border, the only way you could resize a window was: the titlebar, keyboard shortcuts, and this handle. (which provided a reasonably large hit area at the bottom of the windw.
That's why it was on by default.
Now, no there is no reason not to turn it off by default, except that it will piss people relying on it (and now they will have to look for the option for turning it on again).
On the other hand I have seen no good reason, not to keep it on by default either. (might have missed them though). except from "this is ugly" (a word which I hear more and more these days and really come to dislike).
On the section of devising a general rule by the example, I for one use this handle systematically to resize my borderless konsoles. got used to it, will turn it on systematically if the default is change.

Also,

  • I have seen no bug reports over the past 10 years about anyone complaining about this thing being on by default.
  • I fail to see how removing this default is an improvement.

I know: this proves nothing. Feel free to commit. I am tired of arguing.

ngraham closed this revision.Jun 3 2018, 3:35 PM

Now, no there is no reason not to turn it off by default, except that it will piss people relying on it (and now they will have to look for the option for turning it on again).

That's not a good reason against changing a default. Otherwise we could never change one.

On the other hand I have seen no good reason, not to keep it on by default either. (might have missed them though).

A good reason to remove this handle is that it paints over application content. Although it's only a very small area it does cover for example quite a large area of the lower scroll bar button in Chrome:


In general indiscriminatorily changing client content presentation is bad practice, therefore I would even remove the option for the handle entirely or disallow it on a KWin level. Maybe it's this way already in the Wayland session (didn't test it there).

"this is ugly" (a word which I hear more and more these days and really come to dislike).

You are right, that just saying something looks ugly is not a sufficient reasoning for a design change. But from what I've seen in the infamous "No window borders" task, which you were probably hinting at, the VDG also brought forward more sophisticated arguments in general. Besides that several devs chimed in saying that they change to "No Borders" all the time because they like it more. I for one never changed, because I don't care about such small details in the design. But having the borders removed now for testing purposes, I have to say it does look nice and I do think it leads to a better overall look of our default desktop (at least as long as the shadows are on, without them it's difficult to know where a window begins and where it ends -> that issue should be discussed in the task, but it's only a real problem on X where compositing can be turned off).

I am tired of arguing.

Why do these discussions tire you? Our design can't stand still forever. If it's because the VDG proposed design changes somewhat hastily and without a grand concept behind them in the first half of this year: I agree. But look where we were coming from: the VDG was in complete disarray at the end of last year providing only minimal output. So we started at an absolute low point at the beginning of the year but I would say mostly thanks to the work of a few individuals, to whom I definitely count Nate, the VDG organisation and work output already got definitely better. And it will hopefully get substantially better when we can work out the remaining tasks of our HIG project, in particular T7983. I wholeheartedly invite you to contribute to it with your experience as Breeze maintainer.

There are other organisational measures, that could be discussed to improve the internal structure of the VDG and their cooperation with us devs, but for now I'm already very happy with the current progress.