-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2385 incosistent tabbing order across the widgets #2401
2385 incosistent tabbing order across the widgets #2401
Conversation
I've tested the functionality but haven't reviewed the code. Here are a few thoughts, some of which might be out of scope for this PR. The good:
Needs work:
Suggestions:
|
Can you give me an example of a widget that has those? I can't find empty, read only boxes with focus stop...
There is no reason as these windows only show data. Fixed.
This one is interesting - the user NEEDS to enter a value in this field, which is why the textbox holds on to the focus.
Very, very weird. Working on it.
Fixed the ordering. One has to wait a short while after tabbing after Max Distance for the calculations to finish (Focus loss causes recalculation? Is this correct?).
This again is an issue of recalculation being done on focus lost. This potentially needs fixing.
I tried to address it with mixed success. Will look closer.
Hmm this could be a nice extension. Will address it.
I don't think this can be easily done. It's better to remove uneditable boxes from receiving focus. |
The invariant perspective without data in the 'Invariant' tab - tabbing through takes 6 presses to go from max Q to the buttons, suggesting the volume fraction and other inputs are selected.
Seems better
On a side note, these two are handled in #2258. In that PR, anything with focus gets a new background color and a red border is added to any input with an error. I won't get back to that PR for a while but some of these suggestions will likely be addressed for v6.0, but that work has a ways to go still. |
</style></head><body style=" font-family:'MS Shell Dlg 2'; font-size:7.8pt; font-weight:400; font-style:normal;"> | ||
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><br /></p></body></html></string> | ||
</style></head><body style=" font-family:'MS Shell Dlg 2'; font-size:6.6pt; font-weight:400; font-style:normal;"> | ||
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; font-size:7.8pt;"><br /></p></body></html></string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be specifying font sizes absolutely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be a standard Qt Designer thing. Quite a few .ui files have explicit font sizes for tooltips and html content displayed in forms. These values are never manually modified in the Designer so I assume they are defaults.
I could remove them by hand but then loading/saving the forms would write the font size directives again...
Modified those fields to be focusable with clicks but not with tab. |
Description
This PR addresses one of the issues brought up in https://github.com/orgs/SasView/discussions/2342 and spun off into #2385.
Now, tab order for all widgets in SasView is consistent and goes in standard direction (left->right, up->down)
Fixes #2385
Review Checklist (please remove items if they don't apply):