Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
icyhoty2k opened this issue Jul 7, 2021 · 7 comments · May be fixed by #579
Assignees
Labels
enhancement New feature or request

Comments

@icyhoty2k
Copy link

icyhoty2k commented Jul 7, 2021

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

@icyhoty2k icyhoty2k added the bug Something isn't working label Jul 7, 2021
@abhinayagarwal abhinayagarwal added enhancement New feature or request and removed bug Something isn't working labels Jul 8, 2021
@Oliver-Loeffler
Copy link
Collaborator

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
Copy link
Author

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

@Oliver-Loeffler
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Collaborator

@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!

Oliver-Loeffler added a commit to Oliver-Loeffler/scenebuilder that referenced this issue Oct 4, 2022
…ibrary are now stored specifically by version, closes gluonhq#369.
Oliver-Loeffler added a commit to Oliver-Loeffler/scenebuilder that referenced this issue Oct 4, 2022
…ibrary are now stored specifically by version, closes gluonhq#369.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment