CSSTUDIO-1989 Changes to the Phoebus source code needed for the Navigator application

[abrahamwolk]

This pull request adds changes to the Phoebus source code for the Navigator application [0] to work.

Since there seemed to be little to no interest in the Navigator application from the broader community, the Navigator application itself has been removed from the branch that this pull request is based on: only the changes to the base Phoebus source tree that are needed for the application are part of this pull request.

The main change is that the code for managing the center Node that is the center of the BorderPane that is displayed in the main window of Phoebus now also handles the case where the center Node is a SplitPane (the center of this BorderPane in the current source code of Phoebus contains a DockPane): the Navigator application replaces the the center node with a SplitPane such that the Navigator application is displayed on the left side of the SplitPane, and the ordinary Node is displayed on the right side.

Other changes to the core Phoebus code include adding accessor functions (setters and getters) and declaring some accessor functions public instead of private.

If the Navigator is not included in a build of Phoebus, there should be no observable effects when using the application from the changes introduced.

[0] I opened a discussion about the Navigator application here: #3053 . If someone wants to test the Navigator application, it is necessary to checkout a few commits earlier than the most recent commit on the branch CSSTUDIO-1989-navigator, since the Navigator application itself was removed in a recent commit.

[kasemir]

the Navigator application is displayed on the left side of the SplitPane

The navigator is basically a specialized file browser. Its key functionality can be provided by a file browser set to some "my displays" folder. That folder then contains copies or symlinks for the desired displays. Like any app pane, the file browser can be on the left side of a split dock and then "locked".
Instead of displaying a subtree of the file system, the navigator has its own configuration file. And instead of allowing various placements, it's fixed to the left side. I wonder if that will soon be a disadvantage. I often have two file browsers open, set to different folders. Whoever asked for the navigator might soon ask for a "main" navigator plus another one specific to the task at hand. So maybe you're better served by using the existing dock support, just start out with the navigator in the "left" half of a dockpane and by default "locked".

[shroffk]

just start out with the navigator in the "left" half of a dockpane and by default "locked".

I think this makes sense to me.
@abrahamwolk if you could make this work as described above it would be great.

[abrahamwolk]

@kasemir wrote:

The navigator is basically a specialized file browser. Its key functionality can be provided by a file browser set to some "my displays" folder. That folder then contains copies or symlinks for the desired displays. Like any app pane, the file browser can be on the left side of a split dock and then "locked". Instead of displaying a subtree of the file system, the navigator has its own configuration file.

It is true that the basic structure of a navigator is a tree where the nodes point to files containing application instances. This basic functionality could be implemented using the filesystem.

Implementing a custom application for the functionality allows for more integration with both the functionality of Phoebus and with the UI of Phoebus, however. At the moment, the integration is limited; I can think of the following points:

• Integration with the configured color scheme and fonts of Phoebus.
• The name of an OPI or a Data Browser entry in a navigator is read from the name set in the file representing the instance.
• We have control over how the navigator is displayed in the UI: the navigator application is not a DockItem, and it is impossible to move it around: when shown, it is always shown on the left side of the main window. It is not possible to open several navigator instances at once.
• We have control over how application instances are opened: it conveniently possible to open application instances (1) replacing the currently opened tab, (2) in a new tab, or (3) in a background tab.

In the future, however, it may be extended, perhaps by functionality to search application instances in one or several navigators for PV names, the ability to point to application instances that are not saveable to file currently in Phoebus (e.g., logbook search queries), etc. etc.

Separate files representing navigators also lends itself well to version control.

And instead of allowing various placements, it's fixed to the left side. I wonder if that will soon be a disadvantage. I often have two file browsers open, set to different folders. Whoever asked for the navigator might soon ask for a "main" navigator plus another one specific to the task at hand. So maybe you're better served by using the existing dock support, just start out with the navigator in the "left" half of a dockpane and by default "locked".

Placing the navigator always on the left in the main window is a design decision. This placement is very predictable, and I think it makes sense from a UI perspective that the navigator always is located in the same place.

Multiple navigators are supported, and it is easy to switch between the set of available navigators: the available navigators are structured in a tree (here the file system is used to implement the tree), and the UI allows for convenient switching between navigators.

@shroffk wrote:

just start out with the navigator in the "left" half of a dockpane and by default "locked".

I think this makes sense to me. @abrahamwolk if you could make this work as described above it would be great.

By design, the navigator is not implemented as a DockItem, and I don't think that this would be possible without changing this design, unfortunately.

[kasemir]

With the Eclipse-based CSS, at least two sites decided that they must have site-specific top-level additions, one similar to this navigator, the other a type of status panel. The move on from Eclipse broke those.
The layout option to lock panel locations was meant to be a compromise acceptable to all sites.
But go ahead, do your thing, just be ready to adapt or re-do.

[abrahamwolk]

With the Eclipse-based CSS, at least two sites decided that they must have site-specific top-level additions, one similar to this navigator, the other a type of status panel. The move on from Eclipse broke those.

I think that if we are the second site to implement a navigation solution, then that is evidence for that there exists a need for a more integrated navigation solution with more features than a simple file browser in CSS.