Not Including a MenuSearchWidget?

[MichaelWDenney]

Our application is using JMenuBar for some low level menus. The JMenuBar class is getting the RadianceMenuBarUI and, I assume, therefore includes an instance of MenuSearchWidget. I don't want a search panel in these menus and its presence is resulting in a blank entry at the end of our menus. Is there a mechanism to disable menu search support in a particular menu bar? Simply removing the MenuSearchWidget appears to work, but that is definitely inelegant.

[kirill-grouchnikov]

That widget should only get added to the menu bar when you call RadianceThemingCortex.WindowScope.setWidgetVisible(myFrame, true, WidgetType.MENU_SEARCH). Are you seeing that widget without explicitly enabling it? Or is the setup that the same top level JFrame has multiple JMenuBars in its hierarchy?

[kirill-grouchnikov]

To clarify, you are seeing the menu search widget without explicitly enabling it with the WindowScope.setWidgetVisible? That sounds like a bug. I'm not seeing it in the main Radiance test app. There this widget is explicitly enabled from the new JCheckBox("Has menu search") checkbox (in ControlPanelFactory.java).

As for multiple menu bars in the same hierarchy, that would need to be a new API probably on ComponentScope to allow enabling the menu search just on the specific menu bar.

[MichaelWDenney]

Correct. the menu search widget is never explicitly set within our app.

That said, even if it was, why are we just seeing a blank line in the menu? Is there more that would need to be done to initialize the widget properly?

[MichaelWDenney]

If this is a bug, do you see any issue with removing the MenuSearchWidget from the JMenuBar as soon as it is instantiated as an interim solution? As I said, it seems to work fine, but I don't know about any behind the scenes side effects.

[kirill-grouchnikov]

Ah yes, the search panel in MenuSearchWidget is added to the hierarchy of every JMenuBar, but it's only made visible if the functionality is explicitly enabled. If explicitly removing it works for you, that should be fine. If there's time in the 8.0 release, I'll revisit this logic to:

• Add more granular API to control visibility
• Consider to only add the panel to the menu bar when search is explicitly enabled

[MichaelWDenney]

Sounds good. Thanks once again for the help. I really do appreciate the support and that you are always quick to respond.

[kirill-grouchnikov]

I've been thinking about this, and the right way to make this work.

Right now there are two methods in RadianceThemingCortex:

• GlobalScope.setWidgetVisible
• WindowScope.setWidgetVisible

The first issue is that the second one should really be RootPaneScope.setWidgetVisible, since that's what matches the core JRootPane.setJMenuBar API. Even though apps can use JFrame.setJMenuBar, that API is not defined in Window, and the implementation forwards this to JRootPane.setJMenuBar. So logically, the WindowScope is not the right scope for this configuration.

The second one is that, realistically speaking, I do not see a near future in which I add more widgets that would fall under the umbrella of RadianceThemingSlices.WidgetType (which has only MENU_SEARCH enum value, and that's how it's been for years now).

If I was adding this functionality today, it would be:

• APIs in GlobalScope and RootPaneScope, named something like setMenuSearchVisible(boolean)
• Search panel only added to the menu bar when search is explicitly made visible

The second part is not a breaking API change, but the first part is. But I'm reluctant to introduce such a breaking change in Radiance 8.0, as the primary focus of this release is on the new color system. Right now I'm leaning towards making this change in the next release 8.5, which would be a few months after 8.0 lands, so at some point in late 2025.

[MichaelWDenney]

Holding off until release 8.5 shouldn't be an issue for me since I implemented the work-around of removing the MenuSearchWidget as soon as a JMenuBar is instantiated. I haven't seen any negative side effects.

[kirill-grouchnikov]

See #521 that is scheduled for 8.5

[kirill-grouchnikov]

#521 has been addressed