https://bugs.kde.org/show_bug.cgi?id=500223
--- Comment #8 from John <ilikef...@waterisgone.com> --- (In reply to cwo from comment #7) > 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. Oh, I see, I haven't thought about the problem of pressing Enter while the selection is on another item. As is indeed confusing about what the user wants in that case. But maybe we could infer what it want based on the status of the first password input field opened. 1. I mean, did the user typed anything there before moving to other network? If not, he probably realized it pressed Enter on the wrong network and moved on to the correct one / the one that he really wants to connect to, so pressing enter should not be forwarded but instead open the password input field at the newly selected network. 2. Did the user typed some characters, but less the minimum 8 that are required for Wi-Fi passwords? In that case pressing Enter to send them is useless as they will be rejected, so in this case too open the password input field of the newly selected network. 3. Did the user typed the minimum 8 characters before pressing enter? I think it's would be really weird and uncommon for someone to move to another network and type the full 8 characters before pressing enter if he wanted to connect to another network. > (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). I'm not sure either and I'm just throwing some idea around with the hope that maybe some of them are good and make sense to you or somebody else. Unfortunately I don't have a Windows VM anymore to see how they did it and even if I did, I'm not sure it would've showed any wireless networks as it got some virtual wired connection. And I don't remember either how it was in Windows 7 that I used for many years, but I think there a small pop-up window with only the password input field and maybe an OK button appeared that had all the focus. So you had to type the password and press Enter or click OK or you had to close it to get back to the networks. > 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. I'm glad that you started looking into this pretty old problem, but I'm sorry that it's that hard! > 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). I understand and I feel sad to hear that providing the ease of use features (mouse hover) visual cues (higlighting items or buttons on them) and accessibility features (both mouse and keyboard navigation) are like a burden, hard to implement and maintain. > 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. I wish it didn't lead to this, but I think that's because this is probably the most complicated list of items that appears anywhere in Plasma, at least from what comes to my mind right now. I don't know any other where items have two type of actions, like here: -Show network properties -Show password input field And they differ a bit by with what physical device they are done with (mouse or keyboard): Left click on the left side (on network name): Show network properties Left click on the right side (on "Connect button): Show password input field Right click on whatever side: Not used for anything / Not available ------------------------------------------------------------------------- Enter on both sides (? whole row ?): Show password input field Right-arrow (making Connect button highlighted) + Enter: Show password input field Besides all the back-end / components complications in the code that you and other developers know better, I think there might be a bit of a problem with the logic / behavior / consistency too. It's strange that I cannot replicate with the keyboard the same behavior that I can do with the mouse. I mean left clicking with the mouse on the left side (network) name shows the network properties, which is great and probably what Windows does too. But if I want to do the same thing with the keyboard I can't as it will jump straight into the connection mode by opening the password input field, which I didn't explicitly asked for. If I wanted that I would've gone with they keyboard right-arrow once, until the "Connect" button was highlighted and then pressed Enter. There's not way to specify with the keyboard that I want to highlight the left column / side (the network name) and press Enter because I want to just see the network's properties and not to connect to it. Also one unexpected or unwanted behavior is this: Move up or down with the keyboard's arrow keys. Stop at some network and press Enter The password input field opens (the current behavior) Let's say I did a mistake, I don't want to connect to this password. My expectation is that even with the wrong behavior of showing the password input field instead of the network properties, if I press Enter again the password input field should close, so Enter should be like a toggle to open close the password input field or if the network properties were shown, then those. I tried after that with the ESC button and that, which is harder and more time wasting than just pressing Enter again. I'm was thinking that Enter should work as a toggle because sending an empty password to a secure network it will not work anyway so it would be better to act as a toggle. In my opinion if I were to work on this I would probably start to break the problem in multiple smaller ones like: 1. Make keyboard navigation consistent with the mouse hover and clicks. While pressing the keyboard's up or down keys I would keep the whole row highlight but inside I would highlight the left side (network's name) A. If the user presses Enter then the network properties should be shown B. If the user wants to connect to the network, then it should press the right-arrow to highlight the right side (hence the connect button) and then press Enter. ----------------------------------------------------- * With this case, the default highlight inside the row highlight being the left side (network name) and pressing Enter meaning just showing the network properties the use can move up and down and press Enter as long as it wants as it will just see the properties of each network and it's not problem with some password input being left behind, waiting for some input. Of course close the network properties of the last network and enter was pressed on another as the widget is not so tall by default and because of that it has limited vertical space. * Now with the case of highlighting a network, then highlighting its Connect button and press Enter, which should then open its password input field... A. If the user presses the up or down arrow, consider that it has made a mistake (as it's pretty hard to press the up or down arrow by mistake), choosing the wrong network and wants to choose now the right network to do one of the two actions (show network properties or show password input), so I would close the password input field losing also its focus as a pressed Enter after the selection was moved with the arrow would be confusing. B. If the user moves the mouse over the other networks, unless it clicks on the left side to show network properties or on the right side (Connect button) to show the password input field, IGNORE IT (and forward Enter to the open password input), assuming that the movement is was a mistake letting the mouse free with the hand so it could move the hand to the keyboard to type the password and accept and forward mouse to the open password input field and not towards whatever the moues cursor is hovering now. When I opened the other bug report, this was the use case that I had, using the laptop and the wireless mouse in bed and as soon as I moved my hand from it to the keyboard to type my wireless network password and press Enter, the mouse moved a bit, maybe because the bed shook a bit too from my typing movements or moving my feet. This is the exception that I would do, just for the mouse hover, while a password input field is open and waiting for a password to be typed and Enter to be pressed. I understand that whoever made "Press Enter" to show password input field (same as highlighting the Connect button and then press Enter) was probably thinking to make it as easy as possible and it is pretty easy, but it breaks the consistency with the mouse click on network's name (that shows the properties) and maybe it's why this got so complicated and hard to fix. So at least I, while navigating with the keyboard, be willing to have to press the extra right-arrow before pressing Enter to show the password input field, if it helps in any way to solve this problem or at least be able to show the network's properties by keyboard too. -- You are receiving this mail because: You are watching all bug changes.
