<table><tr><td style="">ngraham added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D15011">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D15011#315816" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D15011#315816</a>, <a href="https://phabricator.kde.org/p/abetts/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@abetts</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>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.</p>

<p>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.</p></div>
</blockquote>

<p>I think we'd need to be careful playing with this. In some cases, I would agree with you that a focus ring is unnecessary--for example around the main content view in Dolphin or Kate: it's obvious where focus is because of the underlined/selected files, or the blinking cursor (respectively). But for small text fields, I think it probably adds value. The important thing is that the user feels confident regarding what will be affected when they use their keyboard. That's why visible focus indicators exist. Our focus indicator is already pretty subtle compared to other platforms. We change a one-pixel monochrome line to a one-pixel colored line. On macOS, for example, there's a huge blue glow.</p>

<p>Also note that if we want to change the focus indicator in Breeze, then we should land this patch as-is and not tweak the focus behavior here or else we may not automatically inherit whatever changes we make globally.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R119 Plasma Desktop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D15011">https://phabricator.kde.org/D15011</a></div></div><br /><div><strong>To: </strong>ngraham, Plasma, VDG, davidedmundson, abetts<br /><strong>Cc: </strong>huftis, rooty, sharvey, romangg, broulik, safaalfulaij, oysteins, filipf, abetts, davidedmundson, michaeltunnell, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart<br /></div>