Implement the 'standalone' window mode

[rjwills28]

The main purpose of this PR is to add back in the standalone window implementation that existed in CS-Studio. See Issue #3543 for a full description of our motivations.

A standalone window is essentially a window with no toolbars or tabs and so just displays the BOB screen (again, see above issue for an example screen).

A summary of what has been done in this PR:

• Configure a standalone window:
  • No toolbars or tabs:
    • Remove right click menu option to show toolbars
  • All applications launched from a standalone window will open up in the 'main' Phoebus window (including the editor). Focus will also shift to the main window.
• Allow displays to be opened in a standalone window from an 'Open Display' action:
  • Additional option added.
  • Standalone windows are sized as close to their display dimensions (i.e. width x height from BOB file) as possible and need less padding than the 'original windows' as we do not need to allow room for toolbars, tabs etc.
• If a standalone window contains an action to open a display in the 'replace' mode, then the standalone window is resized to the new display dimensions.
• Configure the memento to save the standalone window mode
• Launch a window in standalone mode from the terminal:
  • These windows will open with the correct width & height specified from the BOB file (if no dimensions are given from the command line).

All of these changes only apply to standalone windows meaning that the original 'New Window' implementation has not been touched and still functions as it did before. These changes will be transparent to users unless they change their actions to open in the standalone mode or use the command line argument to launch them.

We have been actively testing this implementation at Diamond and so have ironed out most of the issues with behaviour.

Note: some of the resizing of windows can be done in a cleaner way once Phoebus has moved to JFX25. This is because there is a bug in older versions of JFX that mean that any sizing of the stage before it is 'shown' (i.e. stage.show()) are not applied (see #3436). This means that currently we have to do all of our resizing after stage.show(), which can cause some flickering of screens when they first launch as they pop up at one size and then very quickly get resized. I have a fix for this but propose postpone implementing that until the basic standalone window implementation has been agreed and Phoebus moves to JFX25.

I appreciate that this is a reasonably big PR but most of the commits should be fairly self contained with a descriptive message. Please let me know if you have any questions/feedback.

I anticipate a few Sonarcloud issues so I will address those asap.

Checklist

• Testing:

  • The feature has automated tests
  • Tests were run
  • If not, explain how you tested your changes

• Documentation:

  • The feature is documented
  • The documentation is up to date
  • Release notes:
    • Added an entry if the change is breaking or significant
    • Added an entry when adding a new feature

[shroffk]

There is work that started on JDK25.
Do you want to wait for that to be completed, switch to javafx25 and then complete this PR or do you feel like this should be merged with a separate effort to cleanup code post javafx25 upgrade.

[rjwills28]

@shroffk thanks for the feedback. Personally I think it would be good to get this merged now as it already contains a fair few changes and then I'll create another PR to clean up the window sizing once we've moved to JFX25. If that's OK with you? I just feel like that might be a bit cleaner?

Otherwise, I've fixed the spelling mistake in the comment (thanks for catching).

In terms of SonarCloud, I've fixed all the issues that I think I can, including refactoring some fairly complex nested if-else statements.

The big one that remains is 'Duplicated Lines of code'. I'm not sure how this can be avoided as the two affected classes both need to override the base class's isOpenAction() method to return true instead of the default value of false. The only way to remove this duplication would be to create a new class that has the isOpenAction(){return true} and have these two classes implement that, but that seems like overkill in this case. Correct me if I'm wrong, otherwise I am going to have to ignore this.
Finally I have followed the naming convention of variables that is used by each class, which in some cases is not the Sonar cloud recommended camel case. I think trying to be consistent within a class is more important than sticking to the camel case standard and so I have left these warnings too. Just let me know if you disagree.

[shroffk]

@rjwills28

do not fixate on the duplicate lines of code.

following the existing variable naming convention is the correct thing to do. We should add an exception for sonarcube.

I understand that these changes are isolated to the standalone window and should not affect existing setup... are there any particular changes that we should test rigorously?

[rjwills28]

As you said, most of the behavior changes are contained to standalone windows. Below are some areas to test.

In terms of checking 'normal' windows still behave the same I would test out:

• Launching with the target=window from the terminal, e.g. phoebus.sh -resource file:/xxx/xxx/xxx.bob?target=window
  Expect a window to show up with tabs, toolbar etc. You can still hide/show toolbar from context menu

• Check creating an ActionButton with the action to open a display in a window.
  Expect display to open in a window.

• Right clicking and selecting any context menu application (e.g. 'Open in Editor', 'Databrowser')
  Expect that the application opens in a tab in the same active window

To test the standalone window implementation:

• Test launching from terminal with target=standalone, e.g. phoebus.sh -resource file:/xxx/xxx/xxx.bob?target=standalone
  Expect the window to be the same size as the BOB display.

• Check creating an ActionButton with the action to open a display in a standalone.
  Expect it to open a window that fits the size of the BOB display.

• Right clicking and selecting any context menu application (e.g. 'Open in Editor', 'Databrowser')
  Expect it should open that application in a tab in the main Phoebus window and not the current one.

[georgweiss]

Works as advertised.

I would however suggest one change: the options "New Window" and "New Standalone Window" may be a bit confusing. After all, they both open a new window, and the definition of "standalone" is open for interpretation. Should we consider "New Undecorated Window" or similar?

[rjwills28]

Thanks for taking the time to review @georgweiss - much appreciated.

Yes I see your point - I am happy to change the option name. Besides your suggestion of "New Undecorated Window" (which I think would work), the only other idea I can think of would be "New Pop-Up Window"?

[georgweiss]

@rjwills28, I'd argue that both options could be labelled "pop-up windows".

How about:

• New Window
• New Window (undecorated)

That would make it clear that these options are essentially the same, save for the toolbar and other UI elements.

[sonarqubecloud]

Quality Gate failed

Failed conditions
3.6% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[rjwills28]

Yes, I like it. I've made that change in the latest commit.