DOC: start to document project goals and scope #6
Conversation
tacaswell
force-pushed
the
doc_manifesto
branch
from
0b17004 to
df3115b
Compare
| Other dependencies (databroker, xarray, scikit-beam, scipy, etc) may | ||
| be injected into widgets. | ||
|
|
||
| - widgets that take in structured meta-data should take in documents |
There was a problem hiding this comment.
This is the only thing I'm slightly unsure about. No problem with "data" being entered in the event model, but does this include the setup of other widgets. For instance, using the spinbox with label example, it would be nice if this could be setup with a dictionary of configuration information about a Signal but are we going to enforce that this is a describe document?
There was a problem hiding this comment.
I am also a bit skeptical to enforce the event model.
There was a problem hiding this comment.
Sorry, I think this is data/meta-data meaning getting crosswise. I agree with @teddyrendahl that we do not need full document model from configuration-of-widgets dictionaries!
I was thinking more of "I am a widget that takes an x-y pair and then plots a time-trace of them" or https://github.com/lbl-camera/Xi-cam.gui/pull/4/files .
It may be in scope to put Qt aware versions of some of the core-callbacks from blue sky here (ex, table, some of the plotting) so it can be shared by {xi-cam, databroker-browser, bluesky-ui}.
There was a problem hiding this comment.
I think we should revisit this down the road a bit.
There was a problem hiding this comment.
To elaborate, as long as we may use event-model in places, as an optional dependency inside the widget, same as others listed above, we can wait on the decision of whether the library should take a position of whether widgets "should" do so where applicable.
There was a problem hiding this comment.
Also, nothing blocks the library to create a section of:
Event Model Aware Widgets... or something like that...
Co-Authored-By: tacaswell <[email protected]>
|
@NSLS-II/mily can people please approve this if / when they are happy with it? |
| - prefer numpy arrays, pandas dataframes, and xarray objects to support | ||
| richer 'bulk' data. | ||
| - define (simple) interfaces when needed, but prefer to ducktype | ||
| standard objects. |
There was a problem hiding this comment.
Might be worth clarifying that "standard objects" means Python built-in or widely-used data structures.
There was a problem hiding this comment.
Tweaked this wording a bit to refer to built in types and the bullet point above.
| - data I/O code | ||
| - business logic | ||
|
|
||
| Related projects |
There was a problem hiding this comment.
Could be related: https://github.com/leofang/ptycho_gui, a GUI based on PyQt5 to provide control and visualization of ptychography reconstruction.
Below is a short description we wrote for the GUI (unpublished yet, sorry):
For users’ convenience, we also provide a GUI for pre-processing the scan data, executing an ptychographic reconstruction, monitoring the result as the reconstruction progresses, and post-processing the obtained probe and object, as shown in Fig. 6. The overall framework of the GUI is built with PyQt5, and previewing the scan images, plotting error metrics, visualizing resultant images and so on, are handled using Matplotlib.
In the main panel, see Fig. 6a, users can load the scan data to be reconstructed (either from the NSLS-II Databroker [30] or an existing HDF5 file) and check the associated experimental parameters. Users can open the pre-processing panel, see Fig. 6b, with the loaded data, and it provides both automatic/manual bad-pixel and region-of-interest detection on the raw diffraction data. The pre- processing panel is also equipped with convenient functionalities such as panning and zooming in/out for better inspection of the images. After that, in the main panel, users can select up to two ptychography algorithms and configure the reconstruction parameters, such as the floating- point precision, the number of iterations, the number of GPUs (or CPUs) the code is to run on, etc. Once the reconstruction starts, the monitor panel in Fig. 6c is popped up so that users can monitor/navigate the progress of the reconstruction in a streaming (or static) manner. The communication between the frontend (GUI) and the backend (CPU/GPU ptychography code) is done via POSIX shared memory, enabled by the Python package posix_ipc which provides a wrapper over the POSIX API.
The clean separation of UI design, logic implementation, and actual computation allows the GUI to be easily maintained. To smoothly manage all functionalities provided in the GUI, it is multi- threaded and managed using the signal-slot and the QThread mechanisms in the Qt framework, even though the GUI itself only runs on one CPU core. Lastly, the GUI also provides a batch mode, with which users can process over several sets of scan data in the same setting.
ps. sorry for late reply
| This is GUI for browsing runs that are stored in the databroker. | ||
|
|
||
| bluesky-qtui | ||
| Qt widgets for capturing user input to `blueksy |
There was a problem hiding this comment.
| Qt widgets for capturing user input to `blueksy | |
| Qt widgets for capturing user input to `bluesky |
| `databroker-browser <https://github.com/NSLS-II/databroker-browser>`__ | ||
| This is GUI for browsing runs that are stored in the databroker. | ||
|
|
||
| bluesky-qtui |
There was a problem hiding this comment.
| bluesky-qtui | |
| `bluesky-ui <https://github.com/NSLS-II/bluesky-ui>`__ |
| Domain specific plotting and GUI widgets for X-ray science | ||
|
|
||
| `adviewer <https://github.com/pcdshub/adviewer>`__ | ||
| AreaDetector configuration and viewing / based on typhon, pydm, and ophyd |
There was a problem hiding this comment.
Should we mention NSLS-II ISS GUI <https://github.com/NSLS-II-ISS/profile_collection/blob/master/startup/99-gui.py>__ and XFP GUI <https://github.com/NSLS-II-XFP/profile_collection/blob/master/startup/99-gui-ht.py>__?
No description provided.