https://bugs.kde.org/show_bug.cgi?id=500223
--- Comment #7 from cwo <cwo....@posteo.net> --- I did consider just forwarding all keys to the entry field (or the last active one in case multiple password entry fields are open for some reason), but there is a rather severe issue with this in my opinion: while we could forward characters, we can't really forward the final enter to confirm it as we don't know whether the user intended to send enter on the password entry field or on the newly selected item. If we forward it, allowing the user to arrow up/down after opening a password field is pointless and confusing, they can arrow to another entry but they can't actually do anything useful there. So it would be hard to recover from selecting the wrong network to show the password entry field. And if we don't forward it, the user can type the password into the field from elsewhere, but they can't actually connect without moving the focus back, so the forwarding seems rather pointless. (This doesn't apply to your case of the user arrowing back to the entry with the open password field, I fully agree that then the user should be immediately able to type, though I'm not sure at the moment whether the best solution is to forward character key presses or just moving the keyboard focus to the entry field when the list entry with the password field becomes selected). Anyway, I started looking into this. In principle it's not that hard, but in practice it's quite a challenge and requires some work in the underlying Plasma components and thinking and quite likely lots of other applets that should be adjusted for consistency to any changes we make here. One of the main issues is that we need to separate keyboard-focus state from mouse hovered state. That's not all that difficult, but both can be active at the same time - if the user hovers over an entry and uses the arrow keys to move to a different entry, both need to be highlighted so that both mouse and keyboard use work properly. But they can't have the same type of highlight, or it'll be confusing which is which. We do have two different kinds of highlight (see for example in the Folder View panel widget, or outside Plasma in e.g. the sidebar in Discover. But the component we use in the Network widget does not really support this and needs to be adjusted for this, and it also looks somewhat unpleasant on the large list entries that we have there. So there's quite a bit of implementation work to be done here, and ideally we can work out a way that can be consistent with other widgets that use this component so that they all look and work the same even if the input issue isn't really relevant there. And probably also adjust the other components that use different components to also work the same way (e.g. the Kate sessions widget). So we've gone from "fix a small focus issue" to "redesign widget interaction in Plasma and implement it across everything". I do think that this is a worthwhile thing to attempt (also for increasing consistency and making the general experience better), but it's a large undertaking and will likely take a while, and no promises. -- You are receiving this mail because: You are watching all bug changes.
