CSSTUDIO-2231 Add flag -select_settings for selecting a Phoebus configuration file on startup

[abrahamwolk]

This PR adds the flag -select_settings which allows for selecting a Phoebus configuration file on startup of Phoebus.

When Phoebus is started with the option -select_settings <directory>, a dialog will open that allows one to select a configuration file in directory when starting Phoebus. Any file in <directory> that ends with either .ini or .xml can be selected.

-select_settings is not allowed to be used in conjunction with the option -settings in order to avoid confusion.

Testing request: Phoebus seems to support settings in the form of XML-files. Unfortunately, I do not have a configuration file in XML-format to test with. Therefore the loading of configuration files in the XML format in this PR has not been tested. Could someone test this functionality with a configuration file in XML format and confirm that it works?

[georgweiss]

Strings shown to user should be externalized to messages.properties (e.g. PhoebusApplication).

Failure to start (e.g. incorrect configuration file, unsupported combination of program arguments) should trigger a dialog with suitable error message. Otherwise user will not know why Phoebus did not start, and console/stdout/stderr might not be available.

[abrahamwolk]

Strings shown to user should be externalized to messages.properties (e.g. PhoebusApplication).

Failure to start (e.g. incorrect configuration file, unsupported combination of program arguments) should trigger a dialog with suitable error message. Otherwise user will not know why Phoebus did not start, and console/stdout/stderr might not be available.

Good points. I will fix these.

[kasemir]

-select_settings is not allowed to be used in conjunction with the option -settings in order to avoid confusion.

So far it's fine to list multiple -settings, they are accumulative. We use that in our launcher scripts, always loading global -settings but then adding something like "beam line settings" and finally "user settings", if they exist.
So the launcher script adds one or two more -settings to the command line.

Similarly, it should be OK to run like this if we support -select_settings:

phoebus.sh -settings /home/controls/global.ini -settings /home/controls/beamline.ini -select_settings /home/controls/options`

So you have several base settings which add up, and finally some selectable option. So -select_settings should NOT prohibit additional -settings.

[abrahamwolk]

So far it's fine to list multiple -settings, they are accumulative. We use that in our launcher scripts, always loading global -settings but then adding something like "beam line settings" and finally "user settings", if they exist. So the launcher script adds one or two more -settings to the command line.

Similarly, it should be OK to run like this if we support -select_settings:

phoebus.sh -settings /home/controls/global.ini -settings /home/controls/beamline.ini -select_settings /home/controls/options`

So you have several base settings which add up, and finally some selectable option. So -select_settings should NOT prohibit additional -settings.

I found it potentially confusing, since settings can shadow each other, and therefore I disallowed it. But if this is used, then it makes sense to support it! In that case I would think that not only a combination of -settings and -select_settings should be allowed, but that also multiple calls to -select_settings should be supported, e.g.:

phoebus.sh -settings /home/controls/global.ini -settings /home/controls/beamline.ini -select_settings /home/controls/options -select_settings /home/controls/other_options

would then launch two selection dialogs in succession. Do you think this is a good idea?

[georgweiss]

Multiple dialogs is not ideal.
How about allowing multiple selection in the dialog?

[abrahamwolk]

Multiple dialogs is not ideal. How about allowing multiple selection in the dialog?

Suppose the commandline options java -jar phoebus.jar -select_settings <directory1> -select_settings <directory2> are given. Presumably, the intention is to select exactly one (partial) configuration from <directory1> and one (partial) configuration from <directory2>. If it is possible to select multiple configuration files in the same dialog, then two or more configurations could be chosen from <directory1>, for example.

[georgweiss]

then two or more configurations could be chosen from , for example.

That would not be different than supporting multiple -settings. Supporting multiple -select_settings to support multiple configuration directories is maybe a degree of non-essential flexibility.

[abrahamwolk]

Strings shown to user should be externalized to messages.properties (e.g. PhoebusApplication).

Failure to start (e.g. incorrect configuration file, unsupported combination of program arguments) should trigger a dialog with suitable error message. Otherwise user will not know why Phoebus did not start, and console/stdout/stderr might not be available.

I have implemented these changes now.

[abrahamwolk]

That would not be different than supporting multiple -settings.

I disagree with this, since I think the natural intended meaning of two specifications of -select_settings is that exactly two configuration files should be chosen, one from each specified directory. And if the same directory is specified twice, then exactly two configurations files should be chosen from the same directory.

Supporting multiple -select_settings to support multiple configuration directories is maybe a degree of non-essential flexibility.

This may be the case.

[georgweiss]

The message string

TheArgumentIsNotADirectory="the argument '{0}' is not a directory!"

should probably not be double quoted. Same with other new message strings.

Also, single quote around {0} fails the formatting:

[kasemir]

Mind you, I am questioning the need for -select_settings. Typical end users should not have to pick anything. The launcher script should figure it out for them and then use -settings to start CSS. If your users do need to pick between a few settings, you can already create the appropriate number of desktop icons or start menu links. If you really need a selection dialog, you can do that in for example python/Qt from the launcher script. For what it's worth, on our beam lines we tend to have two entries in the Linux desktop menu to start CSS: One to just start it as the automatically logged-in generic beam line user, and another to first change to a different user. Such change-user-ID gymnastics need to be handled in a launcher script, can't do that within the JRE once CSS is running.
Bottom line, how the settings are determined is a site-specific matter and can already be handled in launcher scripts. A -select_settings option doesn't add any functionality that's not already possible by other means, so there's no show stopper here that needs to be fixed.

[abrahamwolk]

The message string

TheArgumentIsNotADirectory="the argument '{0}' is not a directory!"

should probably not be double quoted. Same with other new message strings.

Also, single quote around {0} fails the formatting:

Thanks! I have fixed this now.

[abrahamwolk]

Mind you, I am questioning the need for -select_settings. Typical end users should not have to pick anything. The launcher script should figure it out for them and then use -settings to start CSS. If your users do need to pick between a few settings, you can already create the appropriate number of desktop icons or start menu links. If you really need a selection dialog, you can do that in for example python/Qt from the launcher script. For what it's worth, on our beam lines we tend to have two entries in the Linux desktop menu to start CSS: One to just start it as the automatically logged-in generic beam line user, and another to first change to a different user. Such change-user-ID gymnastics need to be handled in a launcher script, can't do that within the JRE once CSS is running. Bottom line, how the settings are determined is a site-specific matter and can already be handled in launcher scripts. A -select_settings option doesn't add any functionality that's not already possible by other means, so there's no show stopper here that needs to be fixed.

We have a usecase for this functionality, and while the functionality in principle could be implemented in a separate script, I do not think that the functionality is out of place in Phoebus either.

[abrahamwolk]

@kasemir: Do you object to this PR, or is it, in your view, OK that I go ahead and merge it?

[kasemir]

I'd consider it superfluous, but it's not breaking anything, so go ahead.