https://bugs.kde.org/show_bug.cgi?id=500223
--- Comment #9 from cwo <cwo....@posteo.net> --- (In reply to John from comment #8) > 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. Yes, such a thing would be possible. But I think it's probably better to avoid complicated logic here; it might mean the user sometimes has to press an additional arrow key if they moved away from the entry for a network, but things work in a transparent way rather than the user having to guess what we're guessing what they think. It's likely an edge case anyway. We can also revisit this later when the other things are done and it turns out to be a real problem. > 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. I think once everything is conceptually sorted out it shouldn't be hard to maintain. The problem is lots of things using the components differently and ending up with subtle (and sometimes not so subtle) differences in behavior. Sometimes this may even be a good idea. > It's strange that I cannot replicate with the keyboard the same behavior > that I can do with the mouse. FWIW, our default key for "do the same thing as clicking" is Space, which we largely inherit from Qt - Enter/Return we usually have to add explicit handlers for, and if we do it doesn't always do the same thing as clicking/space. For example, in a Dialog, Enter often means "use the Accept-equivalent dialog button, like OK, Save, Open etc.". If there's also something that can be clicked in the dialog, you activate it by pressing Space. And that works in the Network list to show the connection information. (Except in menus where space doesn't work, only Enter... no idea why this is the case, but it seems to be rather consistent in our apps across both Kirigami and QWidgets). I did think a bit about the issue you're raising as well. Sometimes having minor differences between the mouse and keyboard interaction patterns are justiied, and I think this is one of them. First, it's convenient (as you point out) in the default case. It's also something that I think makes the interacton clearer for screen reader users who can't see the extra button. Using enter to confirm (in this case to begin connecting) is rather natural, and we can even have the screen reader read out "Press Return to Connect" or similar. "The connect button is to the right" feels like an awkward announcement. > 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. Maybe, but you can also just not close it and move away again and that always works. If the user notices they're on the wrong network and they've already started typing, we can't have enter close the field as it would conflict with confirming the password and attempting to connect. We could do it if the entry field is empty, but I'd wait and see if this is actually an issue in practice. > 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. No, all the technical and consistency problems are still there without it I think. -- You are receiving this mail because: You are watching all bug changes.
