Layout Management

[shroffk]

Layouts are a crucial part of Phoebus. There are 2 sets of layouts
user layout which are created by individuals to suit their personal requirements and workflows (operator X's favourite screens, Kunals debugging layout)
system layout which are predefined layouts for certains common tasks and operations (alarm layout, databrowser layout)

To manage system layout the current known solutions include a site specific launch script which copies .momento files into the users ~/.phoebus directory prior to launching.
At NSLS2 we initially decided to adopt the above approach but encountered 2 issues.

1. NFS mounted home directories meant that we could not have a different set of system layout for different groups of machines.
2. A desire for limiting the amount of modifications to user directories

Solutions:
The phoebus application should be able to load layouts from a configured location.

[kasemir]

Do you want to load layouts from the current phoebus.user location and an additional configurable location, or just one of them?
What has priority when both locations contain the same file?
What about the 'default' layout, the one that's loaded on startup, and controlling if that is the last-state-when-shutting-down or a fixed setup, regardless of state when shutting down?

[shroffk]

With this setup phoebus loads layout from an additional location configured via a preference

What has priority when both locations contain the same file?

The user layout always wins out, so if the user has a layout with the same name then we don't even load the system one.

What about the 'default' layout, the one that's loaded on startup, and controlling if that is the last-state-when-shutting-down or a fixed setup, regardless of state when shutting down?

I would stick to the current behaviour
last-state-when-shutting is restored on startup

Additionally, when the user loads a system layout and modifies it... the modified layout is stored under the users .phoebus

[kasemir]

I would stick to the current behaviour
last-state-when-shutting is restored on startup

Well, we need both. Some beamlines like last-state, others want predefined state.
Does your change still support doing that by copying a plain .memento into the phoebus.user location?
A plain .memento in the system location would only be used the first time around, and from then on the one in the user location would take preference, right?

[shroffk]

The changes should not affect existing behaviour. If you copy .memento then that should still get higher priority and work as before
My changes do no copy .momentos into the user location unless they are changed.

[kasemir]

OK, sounds good.

[shroffk]

I tested all the scenarios described above... not really sure how to convert those into unit tests.

@kasemir let me know if any of your setup breaks, we can reopen this ticket and resolve them

[kasemir]

Again looks OK, plus for opening a fixed layout on startup we now also have the new -layout option from #1747