Consider a Group Item consisting of a set of optional items. The designer want to stipulate that at least n options should be enabled for the Group Item to be considered valid.
Possible Group Item Definition Changes
Add a property to indicate that the group is a set of conditions
This would automatically add isOptional to all of the group’s item definitions so the designer would not have to do so.
This would allow the use of Item Blocks w/o forcing the designer of adding the isOptional property in the Item Block itself.
Add a property to indicate the number of “relevant” optional children items should be enabled in order for the group to be considered valid
There may be the need for the Group Item to have a different number of conditions items to be enabled.
Possible Group Item Changes
Add a property to override the number of “relevant” optional children items should be enabled in order for the group to be considered valid
Possible Qt Changes
How to indicate to the user that he/she hasn’t selected enough options
Could put the alert icon next to the group name with a tooltip
Could put text in red saying “Please choose n” in read next to the group’s label
When satisfied , the text could go black or go away.
Suggested API
GroupItemDefinition::setIsConditional(bool)
GroupItemDefintion::setConditionalRange(unsigned int minNumber, unsigned int maxNumber) - if maxNumber is 0 then there is no maximum;
GroupItem::setConditionalRange(unsigned int minNumber, unsigned int maxNumber) - overrides the values specified in the GroupItemDefinition
This seems very specialized to incorporate into smtk core. Do we envision multiple use cases? Could it be addressed in the UI, presumably as an ItemView, or is the need in the smtk GroupItem?
Since this conceptually affects item validity it seems that it needs to be in GroupItem (especially if we also need to support an Item overriding its # of enabled options requirement.
Yes to both questions - though technically it could apply to extensible groups I don’t see a valid use case for it.
In terms of creating a new Type of Item - this would involve creating the new definition, new item, new I/O, and new qtItem classes for it so yes a lot more work.
I think we should go with Caution symbol and put the text in a hint that pops up when you hover over the symbol. That way we follow the pattern we’ve established in the rest of the UI. Also it takes up less real-estate.
So I thinking to change: setConditionalRange(unsigned int minNumber, unsigned int maxNumber) to a pair of functions:
setMaxNumberOfChoices
setMinNumberOfChoices
The reason of splitting them is to provide more flexibility on the GroupItem side of things so you can easily override only min or max values.
And for the XML format:
@Bob_Obara - Would it make sense with gray out or put an X or make the other extra boxes not selectable until I have deselected the number of items that put me back into a valid state state of selection when I’ve reached the maximum number of items? Here is an example with graying out the box and graying out the box with an additional icon.