Rodion Iafarov changed bug 1045798
What Removed Added
Status RESOLVED REOPENED
Resolution INVALID ---
Flags   needinfo?(shundhammer@suse.com)

Comment # 3 on bug 1045798 from
(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.).


You are receiving this mail because: