Watch main css file for change and reapply automatically

[tobiasdiez]

With this PR, working on styling and css files should be easier. Css files are now watched for changes and automatically reloaded. Thus JabRef does not have to be restarted in order to apply a new design. In IntellJ you can now start debugging, edit the css and apply the changes by Build > Build project or Run > Reload Changed Classes.

The idea of the ThemeLoader class is to support external css files (next to the jar file) in the future so that users could change the theme on their own.

I'll add a short note documenting this feature to the wiki after this PR gets merged.

---

• Change in CHANGELOG.md described
• Tests created for changes
• Manually tested changed features in running JabRef
• Screenshots added in PR description (for bigger UI changes)
• Ensured that the git commit message is a good one
• Check documentation status (Issue created for outdated help page at help.jabref.org?)

[clarity-bot]

I generated a structure-diff below from pulling d72e463 on JabRef:hotReloadCss into affca25 on JabRef:maintable-beta.

[stefan-kolb]

So this code wacthes for CSS file changes all the time in production code? I'm ok with adding this for the dev version but imho something like this shouldn't be inside the release code.

[tobiasdiez]

@stefan-kolb The idea was actually that external css files are also supported so that the user can edit them directly (in the hope that we can get one or two designers interested, which create a nice theme for us - similar to the dozen of different color schemes for IDEs). The overhead of the change listener should be almost non-existing (and we don't have a method to test for production code, do we?)

[stefan-kolb]

We could still use external css files without polling for changes all the time. I don't think its valuable except for debugging/designing purposes. A simple restart of the app if one wants a new CSS theme would totally be standard behavior.

[Siedlerchr]

When you use ScenicView it has the ability to hook into the css files and you can then achieve the same effect.
Agree with @stefan-kolb that constant polling for a file which does not get changed by most users is useless and produces uncessary IO.

[halirutan]

I also think polling all the time for CSS changes is too much and I would not expose this feature directly to the user (at least not all the time). However, wouldn't it be possible to merge it anyway, but make the polling turned on by e.g. a command-line switch or a Java environment variable? This would have no impact on the performance of the release version and it would help us and possibly non-existent godlike UI designers with too much time :)

@Siedlerchr Have you actually tried this with JabRef and ScenicView? For inspecting the tree-nodes, it is OK, but changing the style is a pain. It is much more convenient to work in the CSS files, at least with my current experience.

I would really like to see this happen and as long as we only do polling on demand, it should not have a performance impact. @tobiasdiez Do you agree that there is no performance drop without polling?

[tobiasdiez]

The file monitor is now only activated if the css file exists as a direct physical file, i.e. is not bundled in the jar. You guys are of course right that there is no need to monitor a css file in the bundled jar archive.

By the way, if I understand it correctly, then the Watcher does not poll the file for changes but actually registers listeners that fire upon changes (at least for modern OSs). Thus it is very performative and scales to thousands of active file listeners (and the limit lies more in the IOPS needed for registering the listeners). There shouldn't be any noticeable overhead for a few files.

[halirutan]

I tested the live reloading from IDEA and it was inconvenient because the watched Main.css was the one from the build folder. I introduced the -Djabref.main.css property that lets you specify the path to the CSS file. In addition, I made it mandatory that the -Djabref.main.css needs to be defined to turn on file polling. Just giving -Djabref.main.css without a parameter, will turn on polling as the version of @tobiasdiez did.

I wanted it to be as convenient for me as possible and I would like to change the source Main.css and not the one in the build folder. If one of the expert designers we expect to arrive soon (:smile:) wants to play with the style, he/she can then use the JabRef.jar and just place a copy of the Main.css wherever he likes. Simply starting

java -Djabref.main.css="/path/to/Main.css" -jar JabRef.jar

lets them turn on live styling.

I have tested this version both from the IDE and from command-line and it seems to work as expected. Can we merge this into the maintable-beta so that I can pull it into my other branch?

[tobiasdiez]

I like your changes @halirutan! +1 for merge.

[Siedlerchr]

If you fix the checkstyle issue (constant names must be uppercase with underscore), we can merge

[halirutan]

@Siedlerchr Thanks! I usually use this format as well, but Tobi used CamelCase and I wasn't sure anymore how we handle this.