Shared Ribbon Tasks or Bands in Contextual Task Groups?

[MichaelWDenney]

Currently, a RibbonTask cannot be added to two different RibonContextualTaskGroups. Likewise, a JRibbonBand/JFlowRibbonBand cannot be added to two different RibbonTasks. This would appear to force me to define duplicate bands and tasks in the situation where I need duplicated functionality in distinct contextual groups. For example, if I have both a 2D Plot and a 3D Plot contextual group, I may need them both to have the same functionality within a View task composed of multiple bands. Short of duplicating the View task and all its bands for each contextual group, is there no way to do that?

[kirill-grouchnikov]

Correct, there is no way to "share" a Swing component in general between two parents. Ribbon bands are Swing components, and they can't be attached to more than one parent at the same time. There is some "unpretty" reparenting that I do when a ribbon band goes into collapsed mode, and is displayed in a popup panel - and then needs to get reparented back to its task when the ribbon band goes to regular / uncollapsed mode. I don't really see how this can be easily extended to the more general case of sharing bands between tasks - even though, technically, you can't have more than one task visible at the same time.

Until such moment in time where the entire ribbon is defined with pure content and presentation models, and there are no Swing components anywhere in the API surface for the ribbon, sharing views will not happen. At the present moment, I do not have plans for revising the ribbon APIs at that level.

[kirill-grouchnikov]

For reference, Aurora ribbon content is driven purely by projections and models - https://github.com/kirill-grouchnikov/aurora/blob/icicle/component/src/desktopMain/kotlin/org/pushingpixels/aurora/component/ribbon/RibbonBand.kt#L45 is one reference. There you can pass the same projection to multiple places, and at runtime the projection is used to place the actual component(s) on the screen, and have them all synced to the underlying content model changes.

There's technically not much that prevents migrating the Radiance ribbon to it, with these particular points to keep in mind:

• Compose (the underlying UI toolkit for Aurora) builds on top of a reactive programming model, and it takes care of propagating and syncing model changes to all the places on the screen. In Radiance I have to do this manually with a bunch of weak-referenced listeners, and that can get hairy quickly.
• Migrating the entire ribbon API surface to projections and models will mean that applications that want to place core or custom Swing components into ribbon bands will need to wrap that to work with models and projections. I didn't push hard for this up until now, but that would certainly be the price to pay for such an API change.
• It will also be a very big migration cost for ribbon-based apps, so that's certainly something to keep in mind.