Display Builder: Resources location

[pavel-ch]

In complex OPI projects, the displays are usually organized in several directory levels. From all displays at any level, usually the same resources like:

• icons / bitmaps
• bcf files

• common embedded displays bob files etc. should be accessible. Also, due to a common requirement to be independent from the actual directory path, usually all file/resource references in the project must be relative. With the current implementation, all resource localization is done relatively to the current display, which leads to a loading error for example:	+-Icons/icon.png

  +test.bob with symbol widget and path relative as "Icons/icon.png" | +BranchX/test.copy.bob with the same symbol> failing to load Icon.png

Because it is a good engineering practice to have a set of common resources, addressed always in the same manner from all files, I suggest to implement it in some way. I see two possible ways:

1. Preference + a special path prefix (like examples: -> resources: or something else less confusing)
2. Preference + file search priority (1 relative, 2 preferences)

Any thoughts from your side?

[kasemir]

We place shared files in a folder /home/controls/share/opi, while the beam line specific files are in /home/controls/blxxx/opi. In principle, that would allow using /home/controls/share as the absolute path for locating shared resources. But we still use relative paths like "../../share/opi" to get from blxxx/opi to the shared files because we access the files in a few fundamentally different ways:

1) At the beam line, they are fetched as /home/controls/share/opi/some_file.bob.

2) From an office computer, they are fetched as http://some_file_server/blxxx/opi/some_file.bob.

The relative links work for both local and http access. The absolute link would break.

In your BranchX example, I would either add a symlink from BranchX/Icons to ../Icons so that the test display can find the icons via a relative path, or create a copy of Icons into BranchX/Icons in case the branch is not only about working on the text.bob but also on the icons, so it needs a working copy of the Icons.

As for search paths, in fact all the other EPICS display tools support a search path. So technically that could of course be added. But a search path has the downside that you never really know what you'll get. Best case it slows you down because you need to check each path entry, which is especially bad via http. Plus somebody changes the search path, and poof. I'm very glad that the Display Builder has been able to support our beam lines for years now without a search path.

[pavel-ch]

Thanks for the hints.

In principle, that would allow using /home/controls/share

• In my setups I cannot rely on a well-known path, reason see below (deployment) The relative links work for both local and http access. The absolute link would break.
• Yes confirmed In your BranchX example, I would either add a symlink from BranchX/Icons to ../Icons so that the test display can find the icons via a relative path, or create a copy

This is for my typical project not a good way for minimally 2 reasons:

• Having always several branches with several levels -> too many symlinks
• Targeting to fast project setup, copy etc. including git deployment in a muti-OS environment (Linux runtimes x Windows editors), there is no easy way to manage symlinks

or create a copy

• no this issue is about really central resources - common icons etc.

As for search paths, ...

• Absolutely agree with disadvantages of the search path. But my suggestion 1. avoids that. It is something already implemented with examples: keyword. This needs only a check for another keyword in ModelResourceUtil class, not breaking anything which works so far. I am only still considering how to handle http: vs file: acces in Preferences. But in fact I have no problem having slightly modified settings.ini between deployment types. What about that?

[kasemir]

Your resources:/icons/image1.png idea is basically possible with macros. In the preferences, you can define

org.csstudio.display.builder.model/macros=<resources>/path/to/common/resources</resources>

In displays that access these shared resources, use $(resources)/icons/image1.png.

Different deployment types can use different settings, like one that fetches the common resources from a web server:

org.csstudio.display.builder.model/macros=<resources>http://file_server/resources</resources>

[pavel-ch]

Good point, thanks. I give it a try and test possible use cases. Do not know how I missed this simple possibility.

[pavel-ch]

Works for me, closing. Thanks.