> On Jan. 14, 2013, 8: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"?
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/ ).
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108400/#review25425
-----------------------------------------------------------
On Jan. 14, 2013, 9: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, 9: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
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
