D18649: [GridViewKCM] improve contrast and legibility for delegates' inline hover buttons

[Andres Betts]

abetts added a comment.


  In D18649#405180 <https://phabricator.kde.org/D18649#405180>, @ngraham wrote:
  
  > In D18649#405179 <https://phabricator.kde.org/D18649#405179>, @abetts wrote:
  >
  > > I was thinking of dark buttons mostly. Something along these lines\
  > >
  > > https://dribbble.com/shots/5204192-Buttons-Dark
  > >
  > > I think the breeze default color is just too close to white, the contrast with regular buttons is pretty low IMHO.
  >
  >
  >
  >
  > 1. If there's a problem with Breeze colors, we should fix it there rather than working around this in downstream software
  
  
  I disagree on this point. I feel the problem we experience is the belief that breeze colors should be slapped on every element on the desktop. There is nothing wrong with Breeze colors, but we should allow for variations within without thinking that Breeze needs to change. I am suggesting that we can make these buttons show more contrast by "not" using the main gray breeze color as the background for them. Instead we use something a little more subtle and that can help our line-art icons stand out. You proposed a really good idea of floating buttons but we have bumped into the same problem we did before, that the contrast of these buttons is not great.
  
  > 2. If anything I think the gray color used for our button backgrounds is too dark, not too light. Right now it's the exact same color as the window background. Most other color schemes make buttons a bit lighter, and I think that looks better in general
  > 3. The only elements that use a dark background with the Breeze light theme are tooltips; making only these buttons dark would be inconsistent with every other button in every other piece of KDE software
  
  And to the user, what does this mean? I think it means something to us, but not necessarily them. I don't see users saying, "OMG, this button is dark, not light, that color belongs in tooltips... KDE is so inconsistent..." To me, what works here is practicality. By trying to align the concepts to the rest of the desktop environment, we are limiting ourselves from providing good contrast and practical functionality.

REPOSITORY
  R296 KDeclarative

REVISION DETAIL
  https://phabricator.kde.org/D18649

To: ngraham, #vdg, #plasma, broulik
Cc: ndavis, andreask, filipf, abetts, GB_2, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190204/f87e999a/attachment.html>