#19290 closed defect (fixed)
[PATCH] Look and feel is not loaded before showing splash screen
| Reported by: | hiddewie | Owned by: | team |
|---|---|---|---|
| Priority: | minor | Milestone: | 20.05 |
| Component: | Core | Version: | |
| Keywords: | laf, look an feel, splash screen, initialization | Cc: |
Description
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.
Attachments (3)
Change History (12)
by , 5 years ago
| Attachment: | #19290_--_Splash_screen_with_look_and_feel.patch added |
|---|
by , 5 years ago
| Attachment: | Screenshot from 2020-05-24 21-41-42.png added |
|---|
by , 5 years ago
| Attachment: | Screenshot from 2020-05-24 21-40-57.png added |
|---|
With patch: configured look and feel
comment:1 by , 5 years ago
| Summary: | Look and feel is not loaded before showing splash screen → [PATCH] Look and feel is not loaded before showing splash screen |
|---|
comment:3 by , 5 years ago
| Keywords: | laf look an feel splash screen initialization added |
|---|---|
| Milestone: | → 20.05 |
Nice catch, thank you!
Which LaF are you using in the screenshot?
comment:4 by , 5 years ago
I am using the GTK+ look and feel in Ubuntu 20.04 with dark mode enabled.
comment:5 by , 5 years ago
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.
comment:6 by , 5 years ago
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.
comment:7 by , 5 years ago
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
comment:8 by , 5 years ago
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.
Before: splash screen has Java look and feel