Review Request 108400: Improve highlighted contrast in thumbnail tabbox

Thomas Lübking thomas.luebking at gmail.com
Mon Jan 14 23:24:41 UTC 2013 


> On Jan. 14, 2013, 7:59 a.m., Thomas Lübking wrote:
> > my 2c only:
> > 
> > if air has an unnotable *highlight* frame this should be fixed in the theme.
> > if it is not fixable in the theme because the focus is on a mostly light and "airy" appearance i would frankly raise the question of usability in some contexts and esp. for qml fall back to an osd look (unstyled effect frames) for the default implementations (which can easily be replaced by the plasma components one if the user wants to)
> > 
> > hardcoding a certain look in a theme using qml to fix a specific (even the default) theme is imo definitively wrong.
> > consider a theme with edgy corners or a dark one with a contrasting highlight color (not tested but there's some ghost theme or so i'd inspect before adding such patch) where the hardcoded workaround might then miserably fail :-(
> 
> Martin Gräßlin wrote:
>     I have to agree with Thomas here. In additon I have a few questions:
>     * how does it looks like with other themes? Is the highlight color a required element? Are the themes prepared for it?
>     * what about the other switchers? Are they suffering the same problem or is the highlight there better?
> 
> Sebastian Kügler wrote:
>     I agree in principle as well. The switcher does use an unfortunate combination, however, with its grey solid background. "hover" on top of this is almost indistinguishable from the background though. It works a lot better with translucent framesvgs behind and a darker wallpaper (in the taskbar, in krunner for example).
>     
>     Note that I've also tried using PlasmaComponents.Highlight (which semantically seems even more correct), but that's using the same theme elements.
>     
>     I've used a few other themes, Oxygen, Slim Glow especially. theme.highlightColor is defined in all of them (and it has been a mandatory color from the beginning, so we can safely assume it's defined and sensible -- it's used in other places as well, so would quickly stick out). The only issue I've seen with some themes is that the rounding of the corners of the theme is not reflected when using my patch, one could maybe use the margins as hint here. It's a fairly minor thing, anyway. In all themes I've tried, the highlighted window was much easier to spot, using the switcher was much faster and needed less mental attention.
>     
>     I've gone through the other switchers in my kwin install. Some show the same problems, others not to such a degree due to other circumstances:
>     - informative: slightly better, icon highlighting helps, also easier to scan vertical list
>     - {large,small} icons: slightly better, frame contrasts with "more uniform icons", could definitely be improved
>     - windowstick: similar problems
>     - compact view: slightly better since text is made bold for highlighted items
>     - grid: same problem
>     - text icon: same problem
>     - flipswitch, coverswitch: no problem
>     
>     In the end, the lack of contrast for me is only a problem in the window switcher, other UI bits where this problem could arise do not suffer from it to that degree. I'd recomment to not just look at this patch, but try it, since it makes quite a difference in usage.
>     
>     Would it be possible to use a translucent framesvg in the background, so we get some extra contrast from underlying "stuff"?
> 
> Martin Gräßlin wrote:
>     there shouldn't be a difference in contrast compared to e.g. KRunner. That the TabBox is using an opaque theme is a bug Thomas is working on (see review http://git.reviewboard.kde.org/r/107983/ ).
> 
> Thomas Lübking wrote:
>     I've checked some themes[1] and except "spoons" (very old version, no idea whether ivan ever updated it), "opaquity" and the "new air" (even the old air) they all sufficiently highlight the selected window.
>     
>     Reg. the translucency:
>     i'm not a big tabbox user, but there seems to be two stacked frames here (forming the background plate), the lower one seems completely transparent but blurred when blurring is enabled and the upper one does not seem to be ARGB.
>     Also i'm no way sure that the mentione fix will help for kwin (kwindowsystem signals to kwin ... i only got kselectionwatcher instantiated after the eventloop is up working so far, but didn't test the patched kwindowsystem from inside kwin -> gonna)
>     All in all and from a non tabbox expert, it's *looks* somehow wrong in general :-\
>     
>     
>     [1] Androbit, Ghost, T-remix-black, Tibanna, OpenSuSE, Oxygen, Product, SlimGlow (pretty old version on my HDD, no idea about updates)
> 
> Martin Gräßlin wrote:
>     I will investigate the TabBox opacity on Wednesday. Wanted to do a TabBox bugfix day anyway.

Just a quick note:
a) KWindowSystem::compositingChanged() WORKS inside kwin (bespin deco factory) whether instantiated before or after the eventloop is up doe NOT matter and as far as i can say

//        imagePath: "dialogs/background"

In the outer PlasmaCore.FrameSvgItem in ShadowedSvgItem.qml will fix the additional outer frame and i get nicely shadowed and translucent tabboxes (not that they're useful ;-)

The theme adapts to compositor changes, but the mask seems broken, i get black small corners - that is different from the black frame you get momentarily because the cm selection is released with delay.
What does apaprently NOT work with this change (or in general) is blurring (but other windows setting the blur region do get blurred correctly, so i suspect it's just missing) but the theme does NOT change the blur state (ie. being more translucent) before the next kwin restart (and then aligns to whether blurring is or is not enabled in kwin at that time)


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108400/#review25425
-----------------------------------------------------------


On Jan. 14, 2013, 8:08 a.m., Sebastian Kügler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108400/
> -----------------------------------------------------------
> 
> (Updated Jan. 14, 2013, 8:08 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Description
> -------
> 
> Improve highlighted contrast in thumbnail tabbox
> 
> Air's hovered svg provides only a thin frame around the borders, too
> little to quickly spot the highlighted item when the whole widget is
> only around for a few milliseconds (as is usual with the tabbox).
> 
> This patch paints a rectangle with rounded corners behind the
> highlighted item instead, making it much easier to spot the currently
> highlighted item.
> 
> Aimed for master and KDE/4.10.
> 
> 
> Diffs
> -----
> 
>   kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml 4c33703d54c84fd54da94f821234e4cbd9c1c001 
> 
> Diff: http://git.reviewboard.kde.org/r/108400/diff/
> 
> 
> Testing
> -------
> 
> Tested with Air, Oxygen and Slim Glow, all work as expected, all show contrast improvements, while still looking beautiful. :)
> 
> 
> File Attachments
> ----------------
> 
> before, try spotting the highlighted item
>   http://git.reviewboard.kde.org/media/uploaded/files/2013/01/14/kwin-tabbox-contrast-before.png
>  after, much easier to find
>   http://git.reviewboard.kde.org/media/uploaded/files/2013/01/14/kwin-tabbox-contrast-after.png
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130114/8d744d23/attachment-0001.html>

More information about the Plasma-devel mailing list