scenebuilder overwrites preferences when installed multiple versions and change preferences in one of them

[icyhoty2k]

When i install two versions of scenebuilder ex: scenebulider 16 and scenebuilder 8 and change preferences in one of the instance it writes to both versions of scenebuilder and when i install plugins from library manager they become avaidable in both versions of scenebuilder that is not desired

Expected Behavior

Multiple instances of Scene Builder shouldn't share preferences and library manager assets

Current Behavior

Multiple instances of Scene Builder share preferences and library manager assets

Your Environment

Always reproducible

[Oliver-Loeffler]

Which kind of behavior would be desirable? Some ideas:

• Store settings per version?

  • One could maintain multiple installations of the same version. Those would share the settings.

• Store settings per installation?

  • Each installation, regardless of its version, would have its own settings. No shared settings between different installations.

• Store settings per installation but allow definition of shared settings (e.g. common artifacts)

  • Each installation, regardless of its version, would have its own settings.
  • Also, a layer of shared settings might exist, which is then overridden by installation specific settings.

[icyhoty2k]

I think that the second option - store settings per instalation is most practical

[Oliver-Loeffler]

Well, option 2 sounds most practical but after reviewing the code and how things work, I'll start to play with option 1 as this is momentarily the most promising.

[Oliver-Loeffler]

Question @icyhoty2k,
When running multiple instances, would you prefer that all SceneBuilder instances share their repository configuration (just the config!) or would you prefer that every version has its very own repository configuration?

I've explored this today and sharing the repositories (not the libraries) can be implemented relatively straight forward.
This could be done as a complement to PR #396 .

What do you think?
@abhinayagarwal & @mimmoz81 whats your opinion on this?

[luca-domenichini]

Well I think that all SB settings, including repository configuration, should be stored in the workspace location.
I mean that at startup, user should be able to choose a folder to represent the current workspace.
The workspace should:

• be importable/exportable to quickly create a new ws copying from an existing one
• contain all SB settings
• contain custom library definition (jars, fxmls, folders)
• be bound to a specific version of SB, having the ability to upgrade a ws to a newer version if an older ws is opened with a newer SB

Example:
User create ws A using SB 16 on folder /etc/A
Inside ws A user defines its prefs and configures the custom library jars and folders.
Then a new project is started, so user exports the ws A to another ws B on folder /etc/B copying all its settings and custom library configs.
Then SB 17 comes into play and /etc/B in updated with new settings from SB 17.
Now user knows that /etc/B should be opened with SB 17 while /etc/A is still on SB 16.

I think that global settings should be used just as a default when the user has not specified something different on his workspace.
On this subject, I created #392 and have a PR ready to be submitted. I would really like to see some progress on #392
and start building some workspace management from that.

[Oliver-Loeffler]

This is very comparable to what e.g. Eclipse does. I really like that approach.
I will review the work in #392 and think about, how we could shape this into multiple small PRs.

[Oliver-Loeffler]

@AlmasB, as discussed, I've closed the PR #396 and will break it into smaller parts.

I'd like to fix this one first, means introducing a version specific preferences/library store.
The formerly discussed functonality of importing settings/libraries of previous versions will follow in a separate issue/PR.

Would you be so kind and assign this one to me? Thanks!