[PATCH] Look and feel is not loaded before showing splash screen

[hiddewie]

The splash screen shows the default system Java look and feel, not the configured look and feel. The configured look and feel is set during startup in MainApplication#setupUIManager, which happens before the application starts but after the splash screen is shown.

This patch sets up the UI manager before the splash screen is shown, such that the splash screen gets the configured look and feel. The configuration has already been loaded at that point.

[hiddewie]

Before: splash screen has Java look and feel

[hiddewie]

With patch: configured look and feel

[simon04]

In 16498/josm:

fix #19290 - Configure Look and feel before showing splash screen (patch by hiddewie)

[simon04]

Nice catch, thank you!

Which LaF are you using in the screenshot?

[hiddewie]

I am using the GTK+ look and feel in Ubuntu 20.04 with dark mode enabled.

[simon04]

This patch broke plugins providing a Look and Feel, see ticket:19027#comment:5. At the time of applying this patch, we haven't had any LaF plugins. The flatlaf is a plugin candidate now.

[hiddewie]

Would leveraging a ServiceProvider be an option for plugins providing a Look and Feel?

The UI manager could call the ServiceLoader which could preload classes which implement a look and feel provider interface, before calling plugins on the module path that interact with the actual application.

[simon04]

Using a ServiceLoader could work. However, this would open a completely separate way of defining/loading plugins (which is currently done via org.openstreetmap.josm.plugins.PluginHandler#loadPlugins and various entries in plugin's META-INF/MANIFEST.MF).

We could use negative Plugin-Stage values for plugins which need to be loaded before setupUIManager

[hiddewie]

That is definitely an option which fits in the current plugin strategy.

Leveraging the ServiceLoader mechanism could provide a modern way to develop plugins against a JOSM defined interface (and even multiple interfaces providing plugins/configuration for multiple 'things'). Maybe the ServiceLoader method could be provided along the current method of providing plugins. The advantage is that the plugin developer would implement an (JOSM defined) interface that loads/configures the plugin. This might also be a disadvantage because backwards compatibility with the Plugin interface could be broken in the future, while the manifest text file is always parsable in some form. On the other hand, it is also an extra method to do the same thing (loading/configuring a plugin) which has to be maintained.

[simon04]

In 16974/josm:

see #19027, see #19290 - PluginHandler.loadVeryEarlyPlugins for plugins providing a LookAndFeel