More widgets

[CC-g2ca]

Hi there, we are working to add some widgets for phoebus. With CSS we had many widgets used to supervise the accelerator. With them we have a full overview of our equipments. We would like to know if you are interested by adding them to the Phoebus source code.

Widgets we want to include in Phoebus :

• Acct/Dcct --> Alterning Current Current Transformer / Direct Current Current Transformer
• Beam stop
• BEM (Beam Extention Monitor)
• BPM (Beam Position Monitor)
• Dipole
• Quadrupole
• Faraday cage
• Steerer
• Solenoid
• RF Cavity
• RFQ --> this is where the beam will be cut into package and it’s the first acceleration area
• Scraper / Chopper
• Slots
• Diaphragms
• Grouper
• Hexapole
• Vacuum Valve (isolation valve)
• Profilers
• Emittancemeter

Each one of these widgets are displayed as following :

The left part is the widget’s image. The right part is used to display more informations (called infopart) like the defect (LED widget), his name and the attached PV name. The infopart and the embedded widgets can be displayed or not. It can be configured with widgets properties.

In Java terms, in CSS, each widget extends a super widget called CommonWidgetsSp2. This one defines the following properties :

• property to set position of information elements
• property to show/hide info on widget
• property to add transparent background information part
• property to rotate picture
• property to add short name
• property which hide the value text update
• property to change font size
• property to vertical align name
• property to horizontal align name

For now, each widget is specific to GANIL. Nevertheless, we would like to work with you to create more generic and reusable widgets. We think many widgets may interest many laboratories.

[kasemir]

Well, image + LED + label + text update is one possible combination. Other sites might want to add a button that opens a detail page for the associated dipole etc. Instead of implementing a new widget for each such combination, have you considered simply using embedded widgets? I.e. you create a small display with image + LED + label + text update, and then embed that? Compared to BOY, the display builder loads embedded displays in parallel background threads, so the load time tends to be faster. Embedded displays are certainly easier to create and change than custom widget implementations.

[DorianHas]

Maybe, we can create a generic widget that can be any other synoptic widgets as the widget Label (that can be a normal text, a title, ...).

We have considered that. However, we think it would be easier to use, when creating a synoptic, having a dedicated widget.

Moreover, these or this widget will have some different properties.

[DorianHas]

The widget or widgets we propose is a specific widget for synoptics. It's a bit more than a simple group or an embedded widget. It has specific properties.

How your and other research centers handle specific widgets for synoptics ?

[kasemir]

I'm sure everybody repeats some patterns in their displays, like label + text:

Or LED + button for detail screen + button that enables/disables alarm:

Or Button for detail screen + checkbox to enable + 3 LEDs to indicate some part of its state:

Or a template for a motor with basic control and read back elements, plus button to open a whole subtree of detail displays:

As you can see, none of these match your preferred pattern of image + led + label + text update. At the same time, we didn't create a custom widget for each of these, because that would be too much work to implement & maintain. Instead, the screens were created via copy/paste, or by using embedded displays, or by auto-generating the complete screen, whatever is appropriate for the situation.

If you see a good use case for your site specific widget, by all means go ahead and implement it for your product, I just don't see it as a candidate for inclusion into the core set of widgets.

[kasemir]

As mentioned, embedded displays have been around for a while. For the copy/paste approach, #1340 offers added support.

[georgweiss]

Agree with @kasemir. Providing the basic building blocks in Phoebus keeps the application maintainable. At ESS users are extracting repeated OPI components and re-using them together with macros to build a palette of "derived widgets".

[pavel-ch]

Let me few words: Embedded Display is a common solution for this demand. There is one "design flaw" - our embedded display widget does not have any kind of property mapping to "inside" widgets. In our implementation, we have to use macros for all configs to inside embedded content. Some other systems I know support, on embedded widget equivalents, something like creation of "user defined properties" , which can be somehow mapped to properties of inside widgets. Yes I see this is more or less the same as macros. The difference is that properties are more familiar and straightforward for end users. Thus derived widgets described by Georg come with familiar property set and not with a bunch of potentially mysterious macros. This is not a suggestion for any change, only an info what I see behind. And definitely, the basic widget set must be kept as compact as possible.

[kasemir]

Yes, the embedded display is by design a "black box", https://github.com/ControlSystemStudio/phoebus/wiki/Display-Builder-Compatibility#embedded-displays. The content is loaded in background threads. The content can actually change at runtime in case a script changes the file_name. As a corollary, the embedded widget assumes no knowledge of its content. You can pass macros to the content, but you cannot enforce that the content actually uses the macros, and you also can't know which macros the content may expect.

[DorianHas]

Thank you all. We're evaluating embedded + macro.

Sash container doesn't exist anymore. Is it replaced by another widget or can it be reproduced ?

What about Boolean Symbol Monitor and Multi State Symbol Monitor ? We are using SVG images that change color depending of a PV state. Are macros/rules suitable ? and is SVG still accepted ?

[georgweiss]

SVG is supported. However, tools may produce SVGs that do not follow specifications so you might end up in Phoebus not rendering a file correctly. In particular, SVGs containing animations may need special attention.

[kasemir]

As you noted, there is currently no sash container.

The symbol widgets that you mention were contributed to BOY by ITER, and have not been ported. I've never used them, but as far as I understand they displayed a "black and white" type of image in different colors. The "picture" widget can display that type of image, incl. SVG, but it won't change the color. For the purpose of displaying for example a "pump" or "switch" with N different states like "off", "on", "broken", the new symbol widget can be used which displays one of N images. In principle, that's pretty straight forward, you just supply a PV and one image per state. But it's different from the ITER symbol widget where the color of one image is changed in a certain way.

[glcj]

First of all cordial greetings,

1. There is a document for the creation of the Widgets for Phoebus (There are several for CSS with the details to follow)?.
2. It is possible to load the Widgets dynamically without the need to recompile the Phoebus (I understand that they are loaded during startup through SPI).

Thanking you for your information,

Best regards.

[kasemir]

1. https://github.com/ControlSystemStudio/phoebus/tree/master/app/display#development-details
2. As described under 1, we use SPI. You don't need to recompile phoebus. You can add widgets in your own jar file. You will then need to add your jar to your product, i.e. put it onto the class path, which is usually done in the manifest of the product. See https://github.com/ControlSystemStudio/phoebus/tree/master/phoebus-product