Setup for Secondary Menu in Taskbar Command

[MichaelWDenney]

Apologies in advance if this is a little long. In our application menu, there is an open menu as follows:

The Recent Documents is itself a sub-menu of previously opened documents, and thus potentially requires updating all the time. I, therefore, added a SecondaryLifeCycle to the application menu that re-populates the recent documents onBeforeActivateSecondary. That works quite well.

I wanted to also include the open functionality in the taskbar. Initially all I did was: ribbon.addTaskbarCommand(aOpen.getCommand().project());
where aOpen is the open command from the application menu.

That got me 95% there, but I realized the re-populating of the recent documents was not triggering if the user used only the taskbar control and not the application menu. Therefore, I wanted to also add re-populating of the recent documents to the taskbar control. This is what I did:

BaseCommand.SecondaryLifecycle openMenuLife = new BaseCommand.SecondaryLifecycle() {	
	@Override
	public void onBeforeDeactivateSecondary(JPopupPanel arg0) {
	}
		  			
	@Override
	public void onBeforeActivateSecondary(JPopupPanel arg0) {
		populateRecentCommands();
	}
		  			
	@Override
	public void onAfterDeactivateSecondary(JPopupPanel arg0) {
	}
		  			
	@Override
	public void onAfterActivateSecondary(JPopupPanel arg0) {
	}
};

ribbon.addTaskbarCommand(Command.builder()
     		.setText(aOpen.getText())
       		.setIconFactory(aOpen.getCommand().getIconFactory())
       		.setAction(commandActionEvent -> {
       				aOpen.getAction().actionPerformed(commandActionEvent);
       		})
       		.setSecondaryContentModel(aOpen.getCommand().getSecondaryContentModel())
       		.setSecondaryLifecycle(openMenuLife)
       		.setActionRichTooltip(RichTooltip.builder()
			.setTitle(aOpen.getCommand().getActionRichTooltip().getTitle())
			.build())
                .build().project()
);

Functionally this worked. (Although I do wonder if there is a simpler way to use the app command's projection with an added secondary lifecycle). But the Recent Documents menu entry in the taskbar now looks like this:

That is, the arrow indicating the existence of the submenu is over top of the text. Is there a bug or have I done something wrong? (Note that when I was originally just adding the open command's projection to the task bar, as long as I first opened the application menu, the recent documents menu entry had the arrow correctly positioned.)

[kirill-grouchnikov]

The root cause is probably the re-populating of the recent documents was not triggering if the user used only the taskbar control and not the application menu. While you might be able to "fix" it in onBeforeActivateSecondary by computing the new preferred size of the popup panel after your new content has been added there, that shouldn't be the responsibility of the app code.

However, it sounds like you are updating your menu model in that populateRecentCommands which you call from onBeforeActivateSecondary? That's definitely something that is going to be tricky, or maybe even impossible, to support. This lifecycle method is called on the UI thread after the popup panel for the menu has been built by its projection in line 654 of BasicCommandButtonUI. The purpose of these lifecycle methods are to notify the app code that the popup menu is on its way to be displayed, and on its way to not be displayed anymore. Reaching in and manipulating the content inside that popup panel is such a generic operation, that I'm not sure how I could support all the possible things that the app code might want to do in there.

And in here, you don't seem to be configuring the component directly. Your populateRecentCommands probably is updating the content model, which then will trigger an update to the projected component in the next available cycle on the UI thread, by which time the popup menu has been shown with its originally computed size. So your content model update comes in, the arrow is displayed, but it is displayed on top of the text because there is no space in the menu to display it on the side. And you wouldn't want the menu to be changing its size once it is displayed.

It sounds like, perhaps, you would want a projection to have a lifecycle interface of its own, so that you can update your component model before the projection builds the Swing component in buildComponent? But that can be brittle as well, as there is an importunity for it to get into an infinite loop where the the lifecycle method triggers your content model update, which triggers a refresh of the projected component, which triggers a lifecycle method, and so on.

Rewinding all the way back to your very first sentence - The Recent Documents is itself a sub-menu of previously opened documents, and thus potentially requires updating all the time. This sounds like you don't want to get into updating your CommandMenuContentModel (presumably) all the time until it is needed. Sort of a deferred way of thinking about constructing the UI - only populate the content model when it is needed to be projected on the screen. But to do this properly would need a heavy rearchitecturing of the entire content model / presentation model / projection paradigm in Radiance components, and I don't have any plans to do so.

For the specific case, this list of previously opened documents - how frequently does it get updated? If it's shown in one of the popup menus, that list can't be (presumably) be getting updates, as the user is interacting with the menu. And if it's not shown, updating it wouldn't be causing any UI refreshes since it is not projected.

[kirill-grouchnikov]

It will very much help to:

1. See the code in populateRecentCommands, or at least the parts that call the Radiance content model APIs.
2. Have a small, standalone reproducer. Not sure if you'd want to add that on top of the Radiance ribbon test app, or in its own self contained sample.

[MichaelWDenney]

Thanks for the feedback. Before I get into the details, I want to make sure I understand what you are referring to with regard to the preferred size of the popup panel. Are you talking about the size of the popup panel that contains the list of recent documents or the popup panel that contains the "Recent Documents" menu item? The panel containing the list of recent documents is the one populated by populateRecentCommands and it looks fine. With the exception of the automatic addition of the ">" because the submenu is now populated, the panel containing "Recent Documents" never changes. So, is the issue that that panel needs to resize to take into account the ">"? And if so, wouldn't there be a similar problem in the application menu?

[kirill-grouchnikov]

The width of the application menu is fixed, and does not depend on the content. See here. You're not seeing the overlap issue because the secondary panel in the application menu has more space than your particular string needs, so when the arrow is displayed all the way at the right edge, there is no content overlap.

[MichaelWDenney]

I think I found a solution. popupPanel.setPreferredSize(popupPanel.getPreferredSize()); didn't work so I started thinking about why. One bit of the code in populateRecentCommands that I didn't include was that the call to appMenuOpenRecent.getCommand().getSecondaryContentModel().addCommandGroup(s)); was wrapped in an additional layer of our code that schedules it on the EDT in a non-blocking manner. Because it was non-blocking, I presume the secondary menu was populated after the primary menu was already sized. When I change the scheduling on the EDT to be blocking, the arrow is positioned correctly. And that is without the need for the call to setPreferredSize.

I originally made the populating of the secondary menu non-blocking out of concern that a long list of recently opened documents might hold up the works, but I'm not seeing any slowdown as of yet. If it does become an issue, one hacky thing I could do is use a blocking call for the first addition to the secondary menu and have all the rest non-blocking. As long as at least one entry exists in the secondary menu right away, the primary menu sizes correctly.

[kirill-grouchnikov]

Cases like this (no judgement on the app logic, just taking it as an example) is why it’s going to be very difficult or next to impossible to handle this generically at the library level.

[MichaelWDenney]

Yeah, I understand. And no fear of being judgmental. There's always room for improvement. What I would prefer is something that triggers an update to the recent commands whenever there is a change instead of just before it is needed. But, the existing code didn't lend itself to that easily.

Although it will continue to be a work in progress, we did release the first version of our product that makes use of Radiance in the GUI. As a thank you for your support, we would like to offer you a complimentary license. Whether you have use for the product itself or not, I thought you might like to see it in action. If you can provide me with a private email, I can arrange something through our customer support.

[MichaelWDenney]

Should I take your lack of response as a "No thanks." 😄

[kirill-grouchnikov]

Just a bit busy these days, but Maple 2025 looks good from the screenshots I saw on your website. Hopefully you'll have time to test it with the changes to the color system in 8.0. If you're using one of the core skins (Business) with no custom modifications, it should continue working with no changes to your codebase.