Skip to content
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

formatting for enabled vs disabled items in Movement tree #182

Open
kvesik opened this issue Aug 10, 2023 · 1 comment
Open

formatting for enabled vs disabled items in Movement tree #182

kvesik opened this issue Aug 10, 2023 · 1 comment
Labels
enhancement New feature or request good first issue Good for newcomers GUI only Work on this issue might reference data structures, but won't affect them. (low priority)

Comments

@kvesik
Copy link
Collaborator

kvesik commented Aug 10, 2023

Description of issue

The Movement tree is visible via a MovementTreeView at the bottom-left of the Movement module specification dialog:
image
image

MovementTreeItems in the tree are either mutually exclusive (ME) or not; ME items are displayed with radio buttons and non-ME items are displayed with checkboxes. Checkboxes are the default way for QStandardItems to appear in such a view, so the radio buttons for ME items are created via the overloaded MvmtTreeItemDelegate.paint() function.

There are two issues with the way that the radio buttons are painted:

  1. The radio button itself shows grey when checked, whether the item is enabled or disabled. Ideally, the checked radio button should be blue when enabled & checked, empty when unchecked, and grey when disabled & checked. This would be consistent with (a) other radio buttons in the software, as well as (b) checkboxes (for non-ME items) in the Movement tree.
  2. The text associated with the item always shows black, whether the item is enabled or disabled. Ideally, the text of ME items should be black with enabled, and grey when disabled. This would be consistent with (a) other radio buttons in the software, as well as (b) checkboxes (for non-ME items) in the Movement tree.

Here's an example of what's currently happening-- Directionality, Unidirectional, and Bidirectional are all disabled in the image below, but it's only really clear for Directionality. Unidirectional and Bidirectional are ambiguous because the radio button is filled in with grey but the text is black; this formatting never changes.
image

Related issues and discussion

See issue #83 and comments re formatting/style in #134 for background.
It wasn't such a big deal that only checkboxes get greyed out when we were dealing with the directionality issue, since the two relevant radio buttons getting disabled were children of a (greyed-out) disabled checkbox.

However, in issue #175 when Kathleen specified "if any of the above are selected (instead of H1 / H2 / both hands), disable the 'joint-specific movement' options"... all of these options to be disabled are radio buttons. So from the user's perspective, there is absolutely no visual indication why they shouldn't be able to check any of those items.

Not super high priority, but eventually we will need to figure out a way to make disabled radio-button tree items also have grey font, or at least some visual indication that they're unavailable.

@kvesik kvesik added the enhancement New feature or request label Aug 10, 2023
@kvesik kvesik changed the title Find a way to visually grey-out disabled items in location & movement trees formatting for enabled vs disabled items in Movement tree Nov 20, 2023
@kvesik
Copy link
Collaborator Author

kvesik commented Nov 20, 2023

It might be useful to start with:

  • PyQt5 class QStandardItem
  • SLP-AA class/function MvmtTreeItemDelegate.paint()

@kvesik kvesik added the good first issue Good for newcomers label Nov 27, 2023
@kvesik kvesik added (low priority) GUI only Work on this issue might reference data structures, but won't affect them. labels Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers GUI only Work on this issue might reference data structures, but won't affect them. (low priority)
Projects
None yet
Development

No branches or pull requests

2 participants