> 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. > > David Edmundson wrote: > >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.
Yes, "opt-in" would mean patching a qml file. :) So, I understand that this RR can be shipped now. Or are we still waiting (e.g. for the maintainer), David? - Gregor ----------------------------------------------------------- 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
