What | Removed | Added |
---|---|---|
Status | RESOLVED | REOPENED |
Resolution | INVALID | --- |
Flags | needinfo?(shundhammer@suse.com) |
(In reply to Stefan Hundhammer from comment #2) Hi Stefan, You have valid point, and we would adapt test immediately if not 2 other points: 1) The shortcut in previous builds was same, namely alt-n 2) Alt-n is not used for any other shortcut in the networking page So, it's not about shortcuts being changed. Additionally, I as a user may expect same shortcut for Next button and from that perspective there should be a reason why we do it differently for one single page. Just imagine, we do it for every page, meaning user has lookup for current shortcut on every page. Idea of using buttons IDs is good, but we lack resources to implement this in the framework and there are quite some things to improve. As of now we reuse same code for different distributions, including installations in text mode. Meaning, shortcut (whatever it is) will work in all described scenarios. But this is not related to the ticket. So, here we don't assume that shortcuts has to be static, but in this particular case I don't see any reason why we have changed it. So, could you please explain why shortcut is now different, even though there is no other N... button or even any other control. So I see this as usability issue from user perspective first of all. Changing tests is our responsibility and even though we have pain with it, we introduce required changes when product has been changed. I also could not find anything in the header file you are referring to, which justifies this change. So, please, spend a bit more of your time explaining why we have this change and how does it improve user's experience and then we proceed accordingly (change test or change product). > There is no such thing as a "wrong shortcut" for those buttons. A button has > a shortcut, and it might change between wizard steps. > > Your base assumption that those shortcuts have to be static is wrong. They > are not, and they are not meant to be. > > Here is an explanation why not and how this works in YaST: > > https://github.com/libyui/libyui/blob/master/src/YShortcutManager.h#L65 > > I suggested to your QA colleagues numerous times that we could introduce a > much more stable mechanism for openQA to activate YaST buttons: All buttons > have a unique widget ID ("next" in this case) that is much more suitable for > that purpose. We could add a mechanism to the YaST UI to easily send such a > widget ID to activate a widget (not only limited to buttons, but also > setting the keyboard focus to input fields and selection lists etc). > > But if you prefer to do it the old-fashioned way by using keyboard > shortcuts, you'll just have to live with some of them changing between > wizard steps. > > Remember that the focus for the product is the user, not testing tools; we > have to give the user a chance to use the application reasonably well with > only the keyboard if using the mouse is not an option (mouse driver not > working etc.).