romangg added a comment.
In D13277#273061 <https://phabricator.kde.org/D13277#273061>, @hpereiradacosta wrote: > 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: F5888233: Screenshot_20180603_180754.png <https://phabricator.kde.org/F5888233> 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 <https://phabricator.kde.org/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. REPOSITORY R31 Breeze REVISION DETAIL https://phabricator.kde.org/D13277 To: ngraham, #vdg, #breeze, #plasma, abetts, romangg Cc: hpereiradacosta, romangg, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
