Comment # 10 on bug 1045798 from Oliver Kurz

(In reply to Stefan Hundhammer from comment #7)
> You may find this weird, but that's just the way it is.
> 
> It is completely pointless to spend a lot of time (or any time at all) to
> figure out why exactly in this particular case the shortcut changed; some
> widgets changed on the screen, and the shortcuts were redistributed. It is a
> moot point to find out details why this happened. It happened, it will
> happen again, it is meant to happen - because that's the way this thing is
> designed. This is what I explained earlier.

I think you brought this point across and we do not need to argue over how it's
implemented. That is none of our concern as QA. We are looking at the product
trying to simulate best the customer perspective.

If the issue is really as Rodion mentioned in comment 6 that the keyboard
shortcut changes when going back and forth *in the same run* I am convinced
that we should regard this as a real UX issue.

> This is not optimized for our QA workflows, it is optimized for the user. I
> wonder what you discussed with some UX expert about (Ken?) or if you really
> got to the bottom of this case. I will gladly explain this to him in person
> if needed.

Nah, it was mainly a joke by me gone wrong. We just asked "random guy" for his
unbiased opinion, our Azubi Lukas in that case, because he worked with the SCC
team and cared about the usability of the SCC web UI in before.

> I offered a future-proof solution for you QA guys multiple times, but if you
> don't want to go that way, you will have to live with those ever-changing
> shortcuts. This is still the wrong approach, and it will keep failing again.
> You will get the very same response if you guys keep writing essentially the
> same bug report again and again. 

I don't understand how identifying widgets by ID would be relevant for
simulating the customer experience. You are stating that you explained that
repeatedly to "us" QA and we might seem stubborn or stupid to you. It is either
that multiple persons come to the same conclusion and that is caused by YaST
behaving in an highly unexpected way or that we are really doing something that
no customer or user would do. AFAIK the mentioned issue is only appearing in
the live-installer and we only have/test this on the openSUSE Tumbleweed
KDE-Live CD. So if it's really just confined to that then probably we can
ignore on WONTFIX because the effort/value is too low (setting bug therefore).
However, if we observe that elsewhere we should discuss the impact again and
potentially reopen.