Review Request 124675: Fix Bug 311991 - Taskbar buttons for minimized apps should not use disabled state

Tue Oct 27 22:00:24 UTC 2015

> On Oct. 25, 2015, 10: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.
> 
> Martin Klapetek wrote:
>     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?
> 
> Eli MacKenzie wrote:
>     My own use-case for a visible minimized state is as a flag. As far as I know there is no means to associate arbitrary data to a taskbar entry, so I'll minimize a window when it is "flagged". For example, if a browser window stays minimized "too long" I'll know I have to go bookmark some of its tabs and close it. I tend to remain logged in for months at a time.
>     
>     FWIW I have a 24" 16:10 monitor and use maximized windows.
> 
> Gregor Mi wrote:
>     Thanks for the input. If I may summarize: we have the ordinary user view vs. the power user view:
>     - For the ordinary (or impaired) user a long-outstanding issue would be fixed.
>     - The power user would like to keep a feature to be enabled by default.
>     How will this be moderated?
> 
> Heiko Tietze wrote:
>     Simplest solution is to accept your patch (aka opt-in the minimized state). Ship it.
> 
> Thomas Pfeiffer wrote:
>     Heiko's perception that we now have an "opt-in" solution was based on a misunderstanding.
>     Nevertheless, we agreed that since greying out is definitely not the correct visualization and your patch fixes this, you can ship it.
>     If the VDG comes up with a better solution, we'll propose it. Until then, having minimized windows look the same as non-minimized ones is definitely better than what we currently have.

>How will this be moderated?

In leui of someone making a third proposal:
The maintainer will make a call. Some people might object, some will be happy, but everyone then moves on regardless.

- David

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124675/#review87384
-----------------------------------------------------------

On Oct. 23, 2015, 11:16 a.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, 11:16 a.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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20151027/6cde51ae/attachment.html>