[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: D13277: Turn off the extended resize handle/black triangle when there are no borders
From: Roman Gilg <noreply () phabricator ! kde ! org>
Date: 2018-06-03 17:36:46
Message-ID: 20180603173646.1.304B7FB6FB8C722E () phabricator ! kde ! org
[Download RAW message or body]
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
[Attachment #3 (unknown)]
<table><tr><td style="">romangg added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: \
right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: \
#F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: \
inline-block; border: 1px solid rgba(71,87,120,.2);" \
href="https://phabricator.kde.org/D13277">View Revision</a></tr></table><br \
/><div><div><blockquote style="border-left: 3px solid #8C98B8; color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a \
href="https://phabricator.kde.org/D13277#273061" style="background-color: #e7e7e7; \
border-color: #e7e7e7; border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: line-through;">D13277#273061</a>, <a \
href="https://phabricator.kde.org/p/hpereiradacosta/" style=" border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@hpereiradacosta</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><p>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).</p></div> </blockquote>
<p>That's not a good reason against changing a default. Otherwise we could never \
change one.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: \
italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>On \
the other hand I have seen no good reason, not to keep it on by default either. \
(might have missed them though).</p></blockquote>
<p>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:<br /> <a \
href="https://phabricator.kde.org/F5888233" style="background-color: #e7e7e7; \
border-color: #e7e7e7; border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">F5888233: \
Screenshot_20180603_180754.png</a><br /> 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).</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: \
italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: \
#f8f9fc;"><p>"this is ugly" (a word which I hear more and more these days \
and really come to dislike).</p></blockquote>
<p>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).</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: \
italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>I am \
tired of arguing.</p></blockquote>
<p>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 <a \
href="https://phabricator.kde.org/T7983" style="background-color: #e7e7e7; \
border-color: #e7e7e7; border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">T7983</a>. I wholeheartedly invite you \
to contribute to it with your experience as Breeze maintainer.</p>
<p>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.</p></div></div><br \
/><div><strong>REPOSITORY</strong><div><div>R31 Breeze</div></div></div><br \
/><div><strong>REVISION DETAIL</strong><div><a \
href="https://phabricator.kde.org/D13277">https://phabricator.kde.org/D13277</a></div></div><br \
/><div><strong>To: </strong>ngraham, VDG, Breeze, Plasma, abetts, romangg<br \
/><strong>Cc: </strong>hpereiradacosta, romangg, plasma-devel, ragreen, Pitel, \
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart<br \
/></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic