abetts added a comment.
> However, regardless of what we choose, I would like to move towards unifying the interfaces in the above table, because inconsistency in something basic like this is not good. So if we decide to make search fields that have keyboard focus by default not visibly focused until clicked on or text is typed, then we should do it everywhere to maintain consistency. This is another reason why I prefer the shows-focus-when-it-has-focus approach, because deviating from this consistently requires custom code in every client. I feel like we are not really objecting to this concept behaviorally, but rather to the visual consequences of implementing it consistently. > > Thoughts? I agree that our HIG needs to explain focus better. It doesn't really have to be a long HIG about it. It could just be a general rule about the way that fields get their focus. In my mind, adding a visual element that denotes focus is a bit unnecessary, unless you navigate your UI using TAB or this is actually a user with an explicit need to see where the focus is. My general opinion is that KDE has wanted every nook and cranny to have importance and we reflect that in the UI. Like the Kirigami HIG says, developers need to find the most important controls about their app UI and give those a certain priority. I think we could apply that here and remove the blue circle from the search fields and only make it show when the user is navigating using tab or because of some accessibility feature. I don't think that just because it is present in many areas, that it means it's the better approach. However, I remain open to the general consensus. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D15011 To: ngraham, #plasma, #vdg, davidedmundson, abetts Cc: huftis, rooty, sharvey, romangg, broulik, safaalfulaij, oysteins, filipf, abetts, davidedmundson, michaeltunnell, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart
