Write to NTTables

[jjaraalm]

Currently, the table widget does not appear to write to NTTable PVs. Since NTTable is well defined, it would be nice if there was (limited) support for writing to NTTable PVs.

Potential Issues

• It looks like all tables are lists of lists of strings, so only tables of strings should be supported for now. It would be the server's job to validate entries and convert data internally, Phoebus would just pass on whatever raw data is entered.

Suggested Options

• Allow different update modes
  1. Write to PV on focusout. In other words, after each cell is updated, update the PV. In this mode, regular PV updates could continue to occur on all non-focused cells.
  2. Write to PV on blur. Once the user clicks away from the table, the PV is updated. In this mode, regular PV updates should be paused while the table is being edited.
• Configuration option to prevent creation of rows (hide buttons in header)
• Configuration option to prevent creation of columns (hide buttons in header)
• Configuration options to prevent editing column labels (hide buttons in header)

[ttkorhonen]

Has anybody taken a look at this issue? It is still unassigned. The write functionality would be a really highly appreciated feature to have.
I am not sure if all tables are arrays of strings though, at least this is not how we (ESS) foresee the tables to be used.

[shroffk]

We discussed this in today's meetings.. we have 2 AI associated with this request

[ttkorhonen]

All right, that sounds promising, thanks!

[kasemir]

Each table use case seems to basically describe its own little application, requiring specialized behavior.
You can already handle that via a script behind the table where you put that application code. Alternatively, you are adding an open-ended list of properties and options to the table widget to describe all the possible scenarios, which I don't think is practical.

At best you could add "limited" write support, as you suggest, only for string cells.
But when to write? As a control system GUI, we generally require some sort of confirmation.
In a text field, you need to type 'ENTER' to write. Leaving focus/blur/click outside/press Escape/... all restore the original value. I don't think it's a good idea to change this for the table, where you would suddenly write many values without confirmation.

[ttkorhonen]

Well, I can do pvput's to NTTables so I do not immediately see why that would not be doable from a table widget?
I do not fancy a lot having users to write scripts each time they want to use a table widget.
OTOH, I fully agree with requiring "ENTER" or similar to write. Write on focusout...no, please not. Editing a table and then somebody taps your shoulder...

[shroffk]

So I think the agreement was to aim for a "limited" write support... something that covers basic cases and avoids the use of scripts.
This could surely limit the type of write supported to only string cells...

I agree with maintaining the "confirmation" behavior... we can do a write each cell when Enter is pressed.

[kasemir]

we can do a write each cell when Enter is pressed

That's good because it matches the text entry field behavior.
Also means the table widget doesn't need to buffer the 'current' value of all cells, somehow highlight what changed and would be written in case we did write. All that's limited to just one cell.

But I don't think you can write just one cell, so each cell change would write the complete table.
And you have to handle the case where the table keeps changing while you edit.
Lock changes to the complete table until the edited cell is either submitted or restored?
Lock changes just to the edited cell until that cell is submitted or restored?

[shroffk]

Also means the table widget doesn't need to buffer the 'current' value of all cells, somehow highlight what changed and would be written in case we did write. All that's limited to just one cell.

exactly.. going for simple and predictable behaviour here

But I don't think you can write just one cell, so each cell change would write the complete table.

We brought this up for discussion, it turns out that all the use cases from ESS and DLS would be fine with writing the complete table when updating a single cell.

And you have to handle the case where the table keeps changing while you edit.
Lock changes to the complete table until the edited cell is either submitted or restored?
Lock changes just to the edited cell until that cell is submitted or restored?

We can bring up this issue...
I would prefer to lock the entire table, this has been the behaviour in the old cs-studio table widget and is the behaviour of the pvTable applications. Thus locking the entire table would maintain a consistent behaviour.. Also from what I understand the tables which need write support usually consists of configuration (DLS) or setpoint or similar signals which are not actively changing.

[ttkorhonen]

In fact, I would even expect and insist on writing the full table. But after updating each individual cell...? That could be a problem. If you are for instance updating a (breakpoint) conversion table (just imagining here), you want to have the full table completed before committing it.
There may be other solutions to handle this however.

[kasemir]

for instance updating a (breakpoint) conversion table

Right, in that case you probably want to submit a consistent set of values, and assert that the values are increasing along one axis, which can be handled by a simple "values_in_column_1_increase_monotonically" option on the table widget.
That's exactly it, each use case has its own set of concerns. You can implement each use case as a standalone PyQt application, or put the logic into a script behind the table. But I'm afraid that adding all the application logic elements to the table widget will soon get tiresome.

[ttkorhonen]

That was a bit of an imagined example. I would not encourge editing breakpoint tables in a table widget anyway, this would be too risky for a number of reasons. But I still would not back up from the original argument of covering the generic use case a la pvput. No custom logic required.

[jjaraalm]

Yes, there are application specific issues, but I don't think it's hopeless.

For the breakpoint example, it would make more sense for the IOC to validate the table input and reject invalid tables. I think what @ttkorhonen is asking for is just a single option for write on blur (for the table) vs focusout (for the cell) as suggested in the original issue. This should be a simple boolean option for the widget.

[ttkorhonen]

I must add that I have no idea about how the table widget is implemented. If I write a script, would that script be executed after each cell update?

[kasemir]

The script is for example attached to a "Submit" button.
Script then reads from the table and maybe other elements on the display, combines the data into whatever it needs, and sends that to a web servlet or one or more PVs or a file or ... depending on the application.

[ttkorhonen]

Right. Then instead of the script, we could have a piece of Java code that reads the elements from the table and does a pvput. This is more or less all I would ask for. If I need custom logic, I would write a script or do something else.