D16988: [Kickoff] Make the visible search field unfocused by default

[Root]

rooty added a comment.


  > And I'm afraid I don't think we can do #1. @chempfling and @gladhorn have been working hard to push on accessibility, and one thing I've learned in the past week weeks is how important focus is. Making sure that the active element both has and looks like it has focus is critical to making sure  the UI is accessible for screen readers. As such, we need to keep it visually focused by default when it opens.
  
  I respectfully disagree. While this is a very valid point (and I don't dislike the already focused search field), the verb type in the imperative mood is the most efficient way to inform the user that they can search. Furthermore, the UI seeming accessible if focused is more of an intuitive leap. Spotlight, for instance, does this by means of a magnifying glass, and it moves onto the focused search results by default, but it doesn't focus the search field - there is //simply little if any benefit// in keeping the actual search field focused (it's too obvious). That's why I was tinkering with the idea of removing the focus altogether (but I do like the blue).
  
  //In short, there is simply no need to have the search field visually focused by default when it opens, not in Kicker (the text would need to be changed to Type to search...), not in Krunner and not even in Clipboard (where this has already long been implemented). 
  //
  
  > One more note: while compatibility with 3rd-party themes is a laudable goal, it can never be a primary one, and it can't dictate design considerations. 3rd-party themes are a moving target and chasing them is futile, so  "this change makes it look better with 3rd-party themes" can never be a selling point. It has to be better for Breeze first and foremost. If the change also improves the look for 3rd-party themes, all the better, but that can't be the primary consideration.
  
  Futile? I beg to differ. While not primary, it should still be paramount. The fact that it makes it look better for third party themes should be a major concern for KDE, because KDE is touted as endlessly customizable (and this is one of the main reasons a lot of people prefer KDE to GNOME... or Windows/Mac, for that matter).
  
  > So I'd like to see the font size changes go into one patch, the keyboard navigation improvements go into a second, and the search field placeholder text change in a third one. I think those are fairly non-controversial.
  
  While in principle I do agree, this is impossible to accomplish here without making a decision about whether the search field is unfocused or not. Splitting up the patch means that the keyboard improvements go down the drain //(Esc is used to escape no matter what (this works already) and there's no need to use Tab to select the search field (it's already in focus)//. The only thing that's salvageable is the font size change and the change in the text within the field (and the hover font change). The hover changes themselves (not the font), the keyboard improvements etc. are simply too intertwined with the unfocused search field and the way the states are defined. You'd have to rewrite the unfocused portions, but there's essentially no point in doing so seeing as you'll never be using those keyboard improvements in the first place if it's already focused.

REPOSITORY
  R119 Plasma Desktop

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

To: rooty, #plasma, #vdg, romangg, ngraham, davidedmundson
Cc: gladhorn, chempfling, filipf, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20181119/3ce9ea79/attachment-0001.html>