Yamcs Studio v1.0.3 undocumented workspace woes

[tomvanbraeckel]

Upon starting Yamcs Studio v1.0.3 on a machine that has v1.0.2 and v1.0.0-beta.31 installed, the software looks horribly broken.

Screenshot:

After investigation, it seems that the default workspace changed since v1.0.2 and is now pointing to an old, incompatible workspace that is being used by the old v1.0.0-beta.* versions.

We cannot reset (empty) this old workspace because it is being used regularly by Yamcs Studio v1.0.0-beta-* on this machine.

These workspace changes and incompatibilities seem to be a taboo in the release notes and are an unwelcome (and time-consuming) surprise to the users.

Furthermore, a "default" workspace is supposed to "de-fault" the user. Yet in this case they seem to be doing quite the opposite - "faulting" to a known-to-be-old-and-incompatible workspace, rather than the known-to-be-working-and-compatible one that v1.0.2 used.

From our investigation, it seems that:

• Yamcs v1.0.3 uses by default userhomedir/yamcs/workspace
• Yamcs v1.0.2 uses by default userhomedir/yamcs-studio/
• Yamcs v1.0.0-beta.* uses by default userhomedir/yamcs/workspace

Our preference is that Yamcs Studio defaults to a new workspace, such as userhomedir/yamcs-studio/workspace-v1.0.3/ whenever a new Yamcs Studio is released, especially when it introduces a workspace incompatibility.

Another solution, perhaps even better, would be if the user could configure the initial workspace that is used at startup. A commandline argument would also do.

But regardless, workspace incompatibilities need to be communicated to the users (release notes) and changes to the behavior regarding workspaces should also be noted in order to smoothen the transition to new releases.

[fqqb]

There has been no intentional changes in the default workspaces in v1.0.0+. For beta's I would need to lookup. I remember I did work on workspace selection before v1.0.0, but don't remember if I changed any defaults.

I think our release notes since v1.0.0 have gotten a lot better than before.

I definitely do not recommend using multiple versions with the same workspace, unless you are upgrading your version. Even then you may have to do a "Window > Reset Window Layout" (this is something we'd like to fix in the future, but cannot at this stage).

If however you would like to use multiple versions in parallel, then you should indeed use multiple workspaces, but you should control that yourself. The command line options should be available. For a default workspace use the flag: -workspace. To force a prompt try out -force-workspace-prompt. I hope they work, if not, do tell us, you're the first user of those flags.

I will investigate if there's any accidental bug that has been introduced in changing the defaults between v1.0.2 and v1.0.3. That should not be.

[tomvanbraeckel]

I double checked and can confirm that the workspace behavior changed since v1.0.3 as described above.

Testing of the -workspace and -force-workspace-prompt options reveal that they used to work in v1.0.2 but they don't work anymore as of v1.0.3...

[fqqb]

Interesting. I may have an idea, but need to confirm.

As an alternative workaround you may try to put this in the Yamcs Studio.ini file under the option -vmargs:

-Dosgi.instance.area.default=@user.home/my-favourite-workspace

So it would look something like:

-vmargs
-Dosgi.instance.area.default=@user.home/my-favourite-workspace
[... other args]

Note that entries must be on a separate line in this file

It's not as pretty as the -workspace flag but should also get the job done

[tomvanbraeckel]

I can confirm, it works this way!

This means that by adding "-Dosgi.instance.area.default=@user.home/yamcs-studio/" to Yamcs Studio.ini's -vmargs we can prevent Yamcs Studio v1.0.3 from using the same workspace as Yamcs Studio v1.0.0-beta so we're good to continue testing the new release.

Thank you for your help!

[fqqb]

I found the issue by now, and will prepare a new release hopefully still today. It's some delicate timing issues in the bootstrapping of the application (must make sure that nothing gets written to the workspace before it is actually selected).

I think the one drawback with -Dosgi.instance.area.default is that things like switching to a different workspace from within the studio will not work, since it works at a lower level.