feat: Add Widget, dropdown menu with autocomplete from predefined list

[flef]

Hi,

I propose a new widget, it's basically a Dropdown menu from predefined list of choices, as the existing one but with autocomplete.

The list is not limited to 100 items.

Regards,
Florian.

[georgweiss]

@flef , not entirely clear to me how this is supposed to work.
I guess the idea is to write a PV value selected from either of the items in the dropdown, and I suppose the items can be populated from some other (enum?) PV. How does one specify items if not pulled from a PV?

[flef]

Yes, the predefined values to write into the PV are hard-coded into the widget, similar to a dropdown menu. I do not need to dynamically populate the possible values from another PV. This widget functions like a dropdown menu but is not limited to 100 predefined values. Therefore, an auto-complete feature is needed to find the correct predefined value among a large set of possibilities.

Choices :

Auto-complete and filtering :

[georgweiss]

But how are the choices set in the widget editor?

[flef]

The choices are set from the properties panel. (See Autocomplete Item)
Maybe I can rename the property by "Items", as for the dropdown widget.

[georgweiss]

I have a usability concern:
If I type a (string) value not present in suggestion list and press <ENTER>, the value is written to the PV. If on the other hand I type a value that is present in the list, pressing <ENTER> will not write the value. Instead I need to select form the dropdown to trigger a write operation.

This raises the question: should values other than those offered in the list be accepted?

It would also be of value to add an example (or extend existing) in the app/display/model/src/main/resources/examples folder.

[flef]

I have a usability concern: If I type a (string) value not present in suggestion list and press , the value is written to the PV. If on the other hand I type a value that is present in the list, pressing will not write the value. Instead I need to select form the dropdown to trigger a write operation.

This raises the question: should values other than those offered in the list be accepted?

It would also be of value to add an example (or extend existing) in the app/display/model/src/main/resources/examples folder.

Yes, actually, we want to allow the user to add custom input. This works more like a suggestion list rather than a real constraint. However, it may be interesting to add a property to forbid users from typing a string that is not in the suggestion list.

[flef]

I'll push example.

[georgweiss]

Thanks, but I still find it a bit confusing that pressing the <ENTER> key when typing a value present in the list does not write to PV.

[georgweiss]

@flef, we feel there is overlap between this widget and existing widgets. Consequently we would like to discuss use case and details in next developer meeting. If you send me your email address (to georg.weiss@ess.eu) I will make sure to invite you.

[flef]

Hi,

I have significantly improved the initial version.

• The PV is only written when pressing the key (as for a TextEntry) or when a suggestion is selected
• Possibility to allow or disallow values outside the list of suggestions (via an option)
• Different search algorithms (startswith, fuzzy, contains)
• A more comprehensive example page detailing all the options

As a reminder, the purpose of this widget is to offer a list of suggestions based on what the user types. It works like a "Text Entry" for entering PVs (validation using the Enter key). This widget is a complement to the "ComboBox". In addition, it allows the management of a large number of suggestions (whereas ComboBox is limited to 100). In our case, we sometimes have up to 10,000 possible values listed.

Example with 100,000 suggestions:

It could eventually replace the ComboBox, as all of its features are available in this new widget.

Here's the demo page from Home menu :

Regards,
Florian

[shroffk]

Thanks florian
Do you think you will be able to attend the developers meeting on the 14th. We had a few questions about your work and its potential to replace/augment text update and combobox

[kasemir]

It could eventually replace the ComboBox

I like that idea! What are the remaining differences?

Combo: Enter list of "Items" or select "Items from PV"

New widget: "Autocomplete Item" contains "Option1\nOption2\nOption3"

The combo approach seems better for the typical use cases: Get options from PV, fall back to a handful of "Items".
It doesn't scale to 10,000 possible values. There, one long "Autocomplete Item" string, or even an external file seems better.

[flef]

Sure.

We also have a much larger topic that we want to integrate. We have made significant progress on supporting our database InfluxDB.

InfluxDB is an open-source time series database designed to efficiently store and query large volumes of time-stamped data, such as monitoring metrics, events, and real-time analytics. It is optimized for high write and query performance, making it a popular choice for industrial applications and data monitoring solutions.

In another related branch, we have also integrated ChartFx from fair-acc, as we have already discussed in this thread.

We will share this work here as soon as we have been able to test the solution on our installations to a minimum extent.

[kasemir]

As for InfluxDB, we had been working on support for that, see presentation under http://www.rri.kyoto-u.ac.jp/EPICS/program.html

It was faster than an RDB, but we eventually decided to not use it because

• It's implemented in go, a somewhat uncommon language

• The data is transferred in JSON, and the actual implementation resulted in lost detail for small/large floating point values, which was a problem for our vacuum readings which are something like "1e-20" which turned into "0". Reported, Incorrect long values returned due to json to java conversion influxdata/influxdb-java#276, but closed as “wont-fix” which was at the time quite frustrating.

• While influx supports auto-aggregation, for example replacing older samples with the 1-hour-average to reduce the data size, how it does that exactly by storing the data under a different name wasn't convenient. The data retrieval would basically need to look in several different places: Is there recent data? Is there data reduced to the 1 hour avg? Is there data reduced to the daily avg?

• Compared to RDB systems with a track record of having been available for decades and keeping data for that long, influx is still quite new. Cool for system logs or your Arduino fishtank controller data from last month. But control system data going back to 2006??

Also, the two options we have are pretty good: RDB for those who prefer generality, Archive Appliance for those who prefer something optimized for control system data.

[flef]

Thank you for the information, I am interested in the branch that supports InfluxDB. I wasn’t aware of this rounding issue. That is indeed unfortunate. I will check if this bug is still present in InfluxDB versions 2 and 3.
I think it might be interesting for me to present our usage context, as I feel that our use case is a bit different. On our side, we collect telemetry data at relatively high frequency (more than 5,000 values at over 250 Hz) over relatively short periods (from 1 hour to a maximum of 2 days).

[flef]

Thank you for the information, I am interested in the branch that supports InfluxDB. I wasn’t aware of this rounding issue. That is indeed unfortunate. I will check if this bug is still present in InfluxDB versions 2 and 3. I think it might be interesting for me to present our usage context, as I feel that our use case is a bit different. On our side, we collect telemetry data at relatively high frequency (more than 5,000 values at over 250 Hz) over relatively short periods (from 1 hour to a maximum of 2 days).

I confirm that the rounding issue originates from the Java client and not from the database itself, at least in InfluxDB 2.x. The value is correctly stored into DB.

[kasemir]

we collect telemetry data at relatively high frequency .. over relatively short periods

That might be a very good fit for influx.

rounding issue .. not from the database itself

Good. Worst case, you could use a patched java client lib

[flef]

@kasemir @georgweiss , can one of you send me an invitation for the meeting please ?

[georgweiss]

meet.google.com/ztf-udpr-xra<https://meet.google.com/ztf-udpr-xra?hs=224> From: flef ***@***.***> Reply to: ControlSystemStudio/phoebus ***@***.***> Date: Thursday, 14 August 2025 at 13:04 To: ControlSystemStudio/phoebus ***@***.***> Cc: Georg Weiss ***@***.***>, Mention ***@***.***> Subject: Re: [ControlSystemStudio/phoebus] feat: Add Widget, dropdown menu with autocomplete from predefined list (PR #3442) [Image removed by sender.]flef left a comment (ControlSystemStudio/phoebus#3442)<#3442 (comment)> @kasemir<https://github.com/kasemir> @georgweiss<https://github.com/georgweiss> , can one of you send me an invitation for the meeting please ? — Reply to this email directly, view it on GitHub<#3442 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIPUEEGUQ7XARQQ2Z3TFNBD3NRUMRAVCNFSM6AAAAAB746LXFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOBYGA2DMMJZGM>. You are receiving this because you were mentioned.Message ID: ***@***.***>