D24706: [RFC] Change button style

[Noah Davis]

ndavis added a comment.


  In D24706#562666 <https://phabricator.kde.org/D24706#562666>, @ngraham wrote:
  
  > In D24706#553074 <https://phabricator.kde.org/D24706#553074>, @ngraham wrote:
  >
  > > I do like how obvious it makes the selected button, but by doing this, it visually overwhelms and destroys the concept of the default button (which is supposed to be the most visually distinctive button). IMO it also interferes with the the checked and hover states IMO. For example, hovering over a focused button right now inverts its text color, which I don't like at all.
  >
  >
  > Any comment on the above?
  >
  > I think we can change the background color on hover, but for focus, IMO we should try playing with outlines and see if we can make it work. When the background changes based on hover, focus, and also default button status, it's just too much, and it becomes hard to tell what's what IMO.
  
  
  How is it for you compared to the git master focus decorations? I know it's not what you're asking, but I'd like to know.
  
  I'm having a hard time letting go of what I wanted, but I know it has flaws. I've been exploring my options for making the complete experience of using buttons in Plasma more predictable, logical, accessible and attractive.
  
  Things I've discovered about default buttons:
  
  - The default button stops being the default button if you focus a pushbutton or combobox. In that case, nothing happens when you press [Enter]. It may be unrelated to the Breeze QStyle, but I think this should change so that the default button is always activated when [Enter] is pressed.
  - GNOME's idea of a default button is effectively just the button which is focused by default.
  
  On one hand, there's no way to tell that [Enter] and [Space] trigger different actions, partly based on what is focused in Qt applications.
  On the other hand, knowing that you can press [Enter] to accept changes in a settings window without tabbing to the OK button (unless you focus a pushbutton or combobox) makes using settings windows a lot faster.
  
  - GNOME's behavior would work perfectly with what I wanted and eliminate the need to come up with a better default button indicator
  - I think what we have is better in the long run for keyboard focused users if we can get it to work more consistently.
  
  My primary objections to only using an outline to indicate focus on buttons are these:
  
  1. We don't normally do lines thicker than 1px
  2. A 1px focus outline could be a bit too thin if it doesn't contrast well enough with the background colors
  
  A purely technical obstacle in the way of using just an outline is that the background still changes on focus even if the code for changing the background on focus is removed. I have no idea why this happens. Using the design I wanted and the git master design just masks the problem.
  
  We do use thicker lines in some cases.
  
  - The Plasmashell tabs and Task Manager focus lines are 3px
  - the outlines around grid view items in SySe are 4px
  
  Perhaps if we have a very limited set of line thicknesses it won't introduce more inconsistency, but anything larger than 2px looks really excessive and out of place for buttons.

REPOSITORY
  R31 Breeze

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

To: ndavis, #vdg, #breeze
Cc: bodoeggert, ngraham, plasma-devel, LeGast00n, The-Feren-OS-Dev, cblack, konkinartem, ian, jguidon, hannahk, Ghost6, jraleigh, MrPepe, fbampaloukas, squeakypancakes, alexde, IohannesPetros, GB_2, trickyricky26, ragreen, mglb, crozbo, ndavis, ZrenBot, firef, alexeymin, skadinna, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, aaronhoneycutt, abetts, sebas, apol, ahiemstra, mbohlender, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20191115/faaed344/attachment.html>