[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request 124675: Fix Bug 311991 - Taskbar buttons for minimized apps should not use disabl
From: "Martin Klapetek" <martin.klapetek () gmail ! com>
Date: 2015-10-27 2:33:57
Message-ID: 20151027023357.21418.80291 () mimi ! kde ! org
[Download RAW message or body]
--===============2686199663801515954==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
> On Oct. 25, 2015, 11:05 p.m., Thomas Pfeiffer wrote:
> > As always: If you want design or usability input, please provide a screenshot. We \
> > cannot read the code. Thanks.
>
> Eike Hein wrote:
> Thomas, all this does is not grey out the text in Task Manager button labels when a \
> window is minimized. See also the long discussion in the referenced bug ticket.
> Thomas Pfeiffer wrote:
> Thanks, I just wanted to make sure what it specifically does.
> In that case, I am against the patch as it is. There should be some way of \
> distinguishing minimized from non-minimized tasks. I agree with the problem, but I \
> do not agree with the solution.
> Would it be possible to instead of hardcoded greying-out (which I also agree is not \
> the right representation, because greying out is reserved for disabled controls) \
> allow the Plasma theme to define the visual representation? In the Breeze theme, it \
> would make sense (as suggested in the bug thread) to use a different color for the \
> highlight bar instead of changing the representation of the task. Other themes \
> might choose differen representations, or just don't distinguish them at all.
> Heiko Tietze wrote:
> Other solutions: size (e.g. make the button smaller), text (brackets for instance), \
> position (special area outside the normal task bar), subtile grey out (icon only), \
> or add some decorator to the icon. The color might work well - and would probably \
> be the easiest way, but I'm afraid of the desire to show more states like \
> maximized, docked, active, different virtual screen etc. with the need to remember \
> all the colors. Personally I'd like the position very much since minimizing a \
> window means to not include it into the workflow, more or less. It's like the most \
> missing feature of minimizing into tray. However that would be quite a big change.
> Eike Hein wrote:
> Changing size or position is jarring because it causes a lot of movement on the \
> bar. Desaturating the icon is unpopular with users too, since the color information \
> is desired to recognize an icon quickly.
> Christoph Feck wrote:
> If I understand the bug report correctly, the issue was with the icon only, so the \
> text graying could be kept, and the icon graying removed.
> Gregor Mi wrote:
> See e.g. comment 33 "Faded text and colours makes this difficult". So it is also \
> about the text.
Fwiw, I, as an ordinary user, do not see any difference between the window being \
minimalized and the window not being on top (active window). My laptop screen is \
small~ish (13") and I always work in maximized windows. Therefore, representing the \
minimized state in the taskbar in any way bears absolutely no value for me, because \
if I want to swtich to any other window, it makes no difference if it just moves in \
the stack of visible windows or if the window is unminimized. The goal is to get the \
window to the top/make it an active window, I do not care where it comes from. Or, \
more importantly, I do not need to care.
Have we considered a usecase like that? I kind of question the whole usefulness of \
representing the minimized state, switching to it makes no difference besides the \
unminimizing animation, it just makes it harder to find. I mean, I've never looked at \
the taskbar searching Konsole and thought to myself "ah right, Konsole is now \
minimized, so now what?". What would our personas do? Why is it so important to be \
able to tell if the window is minimized or not?
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124675/#review87384
-----------------------------------------------------------
On Oct. 23, 2015, 1:16 p.m., Gregor Mi wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124675/
> -----------------------------------------------------------
>
> (Updated Oct. 23, 2015, 1:16 p.m.)
>
>
> Review request for Plasma, KDE Usability and Jens Reuterberg.
>
>
> Bugs: 311991
> https://bugs.kde.org/show_bug.cgi?id=311991
>
>
> Repository: plasma-desktop
>
>
> Description
> -------
>
> This fixes Bug 311991. Though I am not sure if there are side effects which I am \
> not aware of.
>
> Diffs
> -----
>
> applets/taskmanager/package/contents/ui/Task.qml \
> f655801ab1f7b1a9a915f35149c858f0ede22a29
> Diff: https://git.reviewboard.kde.org/r/124675/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Gregor Mi
>
>
--===============2686199663801515954==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 \
solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> \
<tr> <td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/124675/">https://git.reviewboard.kde.org/r/124675/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On October 25th, 2015, 11:05 p.m. CET, <b>Thomas \
Pfeiffer</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">As always: If you want design or usability input, \
please provide a screenshot. We cannot read the code. Thanks.</p></pre> \
</blockquote>
<p>On October 26th, 2015, 11:33 a.m. CET, <b>Eike Hein</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Thomas, all this does is not grey out the text in Task Manager button \
labels when a window is minimized. See also the long discussion in the referenced bug \
ticket.</p></pre> </blockquote>
<p>On October 26th, 2015, 8:52 p.m. CET, <b>Thomas Pfeiffer</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Thanks, I just wanted to make sure what it specifically does. In that case, \
I am against the patch as it is. There should be some way of distinguishing minimized \
from non-minimized tasks. I agree with the problem, but I do not agree with the \
solution.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Would it be possible to instead of hardcoded \
greying-out (which I also agree is not the right representation, because greying out \
is reserved for disabled controls) allow the Plasma theme to define the visual \
representation? In the Breeze theme, it would make sense (as suggested in the bug \
thread) to use a different color for the highlight bar instead of changing the \
representation of the task. Other themes might choose differen representations, or \
just don't distinguish them at all.</p></pre> </blockquote>
<p>On October 26th, 2015, 9:10 p.m. CET, <b>Heiko Tietze</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Other \
solutions: size (e.g. make the button smaller), text (brackets for instance), \
position (special area outside the normal task bar), subtile grey out (icon only), or \
add some decorator to the icon. The color might work well - and would probably be the \
easiest way, but I'm afraid of the desire to show more states like maximized, docked, \
active, different virtual screen etc. with the need to remember all the colors. \
Personally I'd like the position very much since minimizing a window means to not \
include it into the workflow, more or less. It's like the most missing feature of \
minimizing into tray. However that would be quite a big change.</p></pre> \
</blockquote>
<p>On October 26th, 2015, 10:17 p.m. CET, <b>Eike Hein</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Changing size or position is jarring because it causes a lot of movement on \
the bar. Desaturating the icon is unpopular with users too, since the color \
information is desired to recognize an icon quickly.</p></pre> </blockquote>
<p>On October 26th, 2015, 10:19 p.m. CET, <b>Christoph Feck</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">If I understand the bug \
report correctly, the issue was with the icon only, so the text graying could be \
kept, and the icon graying removed.</pre> </blockquote>
<p>On October 26th, 2015, 10:39 p.m. CET, <b>Gregor Mi</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">See \
e.g. comment 33 "Faded text and colours makes this difficult". So it is also about \
the text.</p></pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Fwiw, \
I, as an ordinary user, do not see any difference between the window being \
minimalized and the window not being on top (active window). My laptop screen is \
small~ish (13") and I always work in maximized windows. Therefore, representing the \
minimized state in the taskbar in any way bears absolutely no value for me, because \
if I want to swtich to any other window, it makes no difference if it just moves in \
the stack of visible windows or if the window is unminimized. The goal is to get the \
window to the top/make it an active window, I do not care where it comes from. Or, \
more importantly, I do not need to care.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Have we considered a \
usecase like that? I kind of question the whole usefulness of representing the \
minimized state, switching to it makes no difference besides the unminimizing \
animation, it just makes it harder to find. I mean, I've never looked at the taskbar \
searching Konsole and thought to myself "ah right, Konsole is now minimized, so now \
what?". What would our personas do? Why is it so important to be able to tell if the \
window is minimized or not?</p></pre> <br />
<p>- Martin</p>
<br />
<p>On October 23rd, 2015, 1:16 p.m. CEST, Gregor Mi wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: \
1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for Plasma, KDE Usability and Jens Reuterberg.</div>
<div>By Gregor Mi.</div>
<p style="color: grey;"><i>Updated Oct. 23, 2015, 1:16 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://bugs.kde.org/show_bug.cgi?id=311991">311991</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
plasma-desktop
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">This fixes Bug 311991. Though I am not sure if there \
are side effects which I am not aware of.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>applets/taskmanager/package/contents/ui/Task.qml <span style="color: \
grey">(f655801ab1f7b1a9a915f35149c858f0ede22a29)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/124675/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============2686199663801515954==--
[Attachment #3 (text/plain)]
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic