omegat-org/glossary-renderer-plugin-skeleton

[BUG] Default OmegaT colors changed when the plugin's jar is present

Closed this issue · 4 comments

The Bug
When the plugin jar is put into ~/.omegat/plugins, and OmegaT started, colors that weren't changed by users are changed. The layout provided by the plugin doesn't even need to be selected, the mere presence of the plugin is enough.

When the jar is removed, default colors restore their default values.
This bug isn't observed for the colors that have been changed by the user prior to using this plugin.

Steps to Reproduce
Steps to reproduce the behavior:

  1. Build the jar
  2. Place it into ~/.omegat/plugins (or /any/other/folder/plugins, and then in the next step start OmegaT with that folder as the config-dir)
  3. Start OmegaT (if needed, as java -jar OmegaT.jar --config-dir=/folder/from/the/previous/step)
  4. Check the color configuration
  5. Quit OmegaT
  6. Remove the jar from the folder where it was put in step 2
  7. Start OmegaT again (the same way as in step 3)

Expected behavior
Colors (default or custom) shouldn't change.

Attached are 6 screenshots, all taken from OmegaT running with a fresh config: 3 with the jar in plugins folder, and 3 without the jar.
withJarColors
withJarLayouts
withJarViewMenu
withoutJarColors
withoutJarLayouts
withoutJarViewMenu

System Info

  • OS: 64-bit GNU/Linux, various DE's, dark GTK theme
  • Java: e.g. Java8, 11, 17, Oracle and OpenJDK
  • OmegaT: v.5.x (released and built from master), all available LAF's

Possibly, it's an OmegaT's issue, not the plugin's. I compiled the plugin with nearly the exact copy of OmegaT's DictionaryGlossaryRenderer.java, and got the same behaviour.

Could you upload log on console when launching OmegaT? Let's check the order of plugin initializations and whether there are exceptions.

Assumption:
The renderer plugin might break other plugins initialization.

Because default color themes are implemented as a bundled base plugin, so when plugins initialization process is failed and aborted, a theme would become a OS default, the behavior would be like as your report.

The base plugins are initialized at last,
https://github.com/omegat-org/omegat/blob/master/src/org/omegat/filters2/master/PluginUtils.java#L151
It may be skipped when previous part causes unexpected exceptions.

Do you configure omegat part of build.gralde.kts ? it requires set className of your plugin.

The issue, that a default theme is ignored when plugin failed, is fixed in OmegaT nightly.
https://sourceforge.net/p/omegat/bugs/1091/