Improve layout management and fix layout issue #3250

katysaintin · 2025-01-31T18:08:09Z

Please find a PR to improve the Layout Management feature :

Configuration of "phoebus_user" folder also with settings.ini in addition of the $(phoebus.user) variable environnement.
Configuration of "phoebus_folder_name also with settings.ini in addition of $(phoebus.folder.name.preference) variable environnement.
Configuration of default layout that can be load at start in settings.ini "org.phoebus.ui/layout_default" preference
Fix issue with layout_dir preference , it was not taken in account at saving Layout action

See the screenshot here :

In this way, the user home directory can be configurabled also in settings.ini and not depends on the system. It allows a deployement of a Configuration Folder separated from the Phoebus Installation. And allows all the Phoebus Installations to share the same configuration folder.

configure the user folder with settings.ini

kasemir · 2025-01-31T18:36:05Z

core/framework/src/main/resources/workbench_preferences.properties

 # May use system properties
-external_apps_directory=$(user.home)
+external_apps_directory=$(user.home)
+phoebus_folder_name=$(phoebus.folder.name.preference)


Please add some # ...comments... to the preference settings, something that explains these because that all ends up in the online help and https://control-system-studio.readthedocs.io/en/latest/preference_properties.html

of course, comments added .

kasemir · 2025-01-31T18:41:06Z

For what it's worth, you can also implement a default layout by copying some "default_layout.memento" into the "$(HOME)/.phoebus/memento" file.
We do that in the launcher script.

On Linux or Mac, where the launcher script can use /bin/bash, you can implement all sorts of ideas to assemble the -settings ... that you pass to the application, install a default set of *.memento files, including the default "memento" if you prefer your users to always get the same initial default layout instead of whatever they had at the last shutdown.
Trying to implement all that in preferences will keep you busy!

katysaintin · 2025-01-31T22:28:48Z

Thank you for the tips. I see also that there is the argument -layout .
I add the comment as you request.

Thank you.
Katy

abrahamwolk · 2025-02-26T10:20:25Z

core/ui/src/main/java/org/phoebus/ui/application/PhoebusApplication.java

-                final File layoutDir = new File(Preferences.layout_dir);
+            String layout_dir = Preferences.layout_dir;
+            if (layout_dir != null && !layout_dir.isBlank() && !layout_dir.contains("$(")) {
+                final File layoutDir = new File(Locations.user(), layout_dir);


@katysaintin This introduced a change in the semantics of the option org.phoebus.ui/layout_dir: previously, the option org.phoebus.ui/layout_dir specified an absolute path to a directory containing layouts. With this change it always specifies a path relative to Locations.user(). In particular, org.phoebus.ui/layout_dir can no longer be set independently of Locations.user(), which is problematic.

Could you change the option org.phoebus.ui/layout_dir back to be an absolute path?

I think this was changed to support defining layout_dir using $(user.home) but we should continue to support absolute paths.

@katysaintin can you update the above so the layout_dir is treated as an absolute path.
We could add support where we also check if the preference includes any variable and resolves the path as relative in those cases.

abrahamwolk · 2025-02-26T12:30:50Z

core/ui/src/main/java/org/phoebus/ui/application/SaveLayoutHelper.java

+        File user = Locations.user();
+        File parentFolder = null;
+        if(layout_dir != null && !layout_dir.isEmpty() && !layout_dir.contains("$(")) {
+            parentFolder = new File(user , layout_dir);


Would it be possible to also change (or make backwards-compatible) the save-functionality, to use Locations.user() again?

Before the changes in this pull request, layouts were loaded from both Locations.user() as well as from the directory specified by the option org.phoebus.ui/layout_dir. My understanding is that Locations.user() can be assumed to be a user-specific writable directory, while org.phoebus.ui/layout_dir cannot: one use-case of org.phoebus.ui/layout_dir is for read-only deployments of shared collections of layouts.

Hello, just to be sure, for the modifications :

layout_dir have to support absolute path

SaveLayout action should save layout in Location.user() in layout_dir , which in this case a relative path ?

Is that right ? That's means that layout_dir can be absolute or relative ?

I check that ASAP.

Thank you for the review .

Katy

layout_dir have to support absolute path

Yes, that would restore the old behavior.

SaveLayout action should save layout in Location.user() in layout_dir , which in this case a relative path ?

I think saving a layout should save it to Location.user(), i.e., a location independent of layout_dir. In particular, saving a layout should not save it to a sub-directory of layout_dir (unless layout_dir happens to be set in such a way as to contain Location.user().)

Is that right ? That's means that layout_dir can be absolute or relative ?

I think it would be best if the implemented functionality is backwards-compatible, so that, by default, layout_dir is an absolute path, and only interpreted as a relative path if the new functionality is enabled.

Is that right ? That's means that layout_dir can be absolute or relative ?

I think it would be best if the implemented functionality is backwards-compatible, so that, by default, layout_dir is an absolute path, and only interpreted as a relative path if the new functionality is enabled.

Hello, sorry I was busy today, I will do the correction tomorrow, (French hour). Katy

Hello, see modifications in PR #3300

backward compatibility see ControlSystemStudio#3250

backward compatibility for layout management see PR #3250

Fixes #3490, reverts bug introduced in #3250

kasemir · 2025-08-07T16:35:13Z

For the record, this broke the layout handling at our installation.

We set -Dphoebus.user=/path/to/settings and layouts got saved there.
With this change, the user location ends up being /path/to/settings/.phoebus, with /.phoebus being added to what you provide.
Now need to launch the product with -Dphoebus.user=/path/to/settings -Dphoebus.folder.name.preference (empty ..folder.name...) to get back to the original behavior.

Add a feature to configure the default layout, fix layout management and

24086c2

configure the user folder with settings.ini

katysaintin requested a review from georgweiss January 31, 2025 18:09

kasemir reviewed Jan 31, 2025

View reviewed changes

Add comments for new preferences see PR review ControlSystemStudio#3250

8057819

katysaintin merged commit 2dce865 into ControlSystemStudio:master Jan 31, 2025
1 check passed

katysaintin mentioned this pull request Feb 3, 2025

Better error handling for '-layout' option #1839

Open

abrahamwolk reviewed Feb 26, 2025

View reviewed changes

katysaintin added a commit to katysaintin/phoebus that referenced this pull request Feb 27, 2025

Manage layout as absolute path and save memento in user location

92bd716

backward compatibility see ControlSystemStudio#3250

katysaintin mentioned this pull request Feb 27, 2025

backward compatibility for layout management see PR #3250 #3300

Merged

katysaintin added a commit that referenced this pull request Feb 28, 2025

Merge pull request #3300 from katysaintin/master

5508dfc

backward compatibility for layout management see PR #3250

mgonzal1 mentioned this pull request Apr 29, 2025

Release v5.0.0: settings file not defined fermi-ad/phoebus-fnal#58

Open

kasemir mentioned this pull request Aug 5, 2025

Bundled settings are broken #3490

Closed

kasemir pushed a commit that referenced this pull request Aug 5, 2025

Always check bundled settings.ini, regardless of additional -settings

68cd18a

Fixes #3490, reverts bug introduced in #3250

kasemir mentioned this pull request Aug 5, 2025

Always check bundled settings.ini, regardless of additional -settings #3491

Merged

eddybl mentioned this pull request Aug 30, 2025

Improve support for centrally managed mementos #3398

Closed

eddybl mentioned this pull request Dec 9, 2025

[Feature Request] "Open Memento" action on buttons #3671

Open

Improve layout management and fix layout issue #3250

Improve layout management and fix layout issue #3250

Uh oh!

Conversation

katysaintin commented Jan 31, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kasemir commented Jan 31, 2025

Uh oh!

katysaintin commented Jan 31, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kasemir commented Aug 7, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants