Closed rhfogh closed 9 months ago
jbflo
commented
10 months ago @rhfogh I think we should remove wf_type field Sorry for Adding it, but since we decided to create a specific component for display gphl form it is no longer needed. and should be removed.
rhfogh
commented
10 months ago No problem - it will take a few experiments before we settle all of this. I'll just remove it again ASAP.
rhfogh
commented
10 months ago The wf_type field has now been removed
This PR (and the companion PR in mxcubeqt) means that the qt UI now works with the latest mxcubecore changes (and includes some minor clean-ups and fixes).
A couple of points need consideration, for the changes to the paramsgui:
The entries for new wf_type field has been changed as it did not work with the system; this raises a general point: As the system works, the schema["properties"] contains an entry for every data field, but none for pure container fields. The ui_schema, on the other hand, contains only entries for displayed fields, as a nested structure of containers and contents. It is therefore not possible to add parameters in the ui_schema for fields that are not displayed, since these entries do not appear in the nested container structure. Also the wf_type field, as entered, was displayed on top of the main container field, proving that all displayed fields should be inside a container. As the system works after this PR, all fields that do not appear in the nested hierarchy of containers (including wf_type) are automatically treated as hidden and read_only, but can be accessed through the general dictionary of parameter values. If this is problematic for the web implementation we need to consider alternatives together.
I should add that the organisation of ui_schema could be changed if we have a good reason for wanting to do so, but this is the way it is at the moment and that was the quickest way of making the system functional.
I have replaced the signal sent from the GUI with a call to a function on the mxcubecore side (which then in turn emits the signal). To be generic this function had to be put on a fairly general object on the mxcubecore side. I opted for the Beamline object as a neutral location. The function, 'emit', is almost identical to the emit function in HardwareObjectMixin, but Beamline is not a subclass of this class, as the beamline, while yml-configured, is not a hardware object. 1) I am not sure of the exact considerations with what should be imported from core to GUI - might we want a different location? 2) it would be neater if we could avoid the semi-duplication of the emit function - does anyone have an idea?