Open jtreminio opened 4 years ago
Seems SplitItem
handles item selection differently since it displays data horizontally, so it keeps a different selected index to the rest of the parent menu.
It sounds like a logical next step. If was already thinking of this myself. It could have getChecked()
method which returns the checked items. If we can implement this in a nice clean way without lots of special casing and touching lots of files I'd be happy to include it.
SplitItem radio works well:
But it's not possible to have multiple groups of RadioItem within the same menu level:
Similarly, I want to be able to group non-RadioItem items together.
I'm thinking a non-styled container item that can take any number of
MenuItemInterface
items.It has the following API:
addItem()
addItems()
setItems()
removeItem()
If it contains no items, the parent
CliMenu
displays nothing - it is only a container of items and has no styling of its own, nor does it affect the UI.If it has items, it behaves as if those items were defined in-line with the parent menu.
Example:
This would look identical to the GIF above.
If no items are defined,
then it acts as if the group isn't defined at all:
This will help group RadioItems in a vertical manner (without needing to use
SplitItem
), and allow grouping other item types for non-Menu work.In addition, I would suggest changing
RadioItem::getSelectAction()
to use this group feature to disable other items within the same group, vs usingSplitItem
.If the radio item does not belong to a group, behave as it already does and toggle off other radio items within the same
CliMenu
object.edit:
Thinking about this, for initial PR it would be good to keep it simple and not give this class any styling at all. Simply a container, nothing else, but I could see it expending to keeping its own copy of styles and applying them to any children items.
So this would basically end up being a submenu that's visible on the current menu without needing to select an item to view the children items within.