Thank you for starting a new thread based on a digest of the old one. I like the proposed approach.
> * Each display is operated by one subprocess, which displays and manages one > window on the screen. The window gets embedded into a pyqtgraph dock by > artiq_gui. The embedding can be done with XEmbed on Unix, Will the subprocess have access to information about the size of the pyqtgraph window? This would give users the opportunity to adjust display based on resizing (eg font size). > The subprocess may use the mouse and keyboard to implement interactive > plots. The subprocess has a lot of autonomy regarding the choice of > widget/rendering/other libraries and programming languages, all it needs to > do is implement the IPC protocol and manage one embeddable window. Which of the several Linux IPC mechanisms do you have in mind? http://www.tldp.org/LDP/lpg/node7.html > * The subprocess communicates with artiq_gui using an IPC channel: > stdin/stdout redirection, or - preferably - inherited pipes and file > descriptors (Unix) or handles (Windows). Functions like msvcrt.get_osfhandle > and kernel32.SetHandleInformation with HANDLE_FLAG_INHERIT enable pipe > inheritance on Windows, as demonstrated by the MyHDL cosimulation code. Will the subprocess be able to use the ARTIQ Logging facility? What do you envision the user experience to be like while debugging code? It would be convenient if users could interact with a python environment that exposes the same API and datasets as would be available from the IPC-subprocess. > * The configuration of the display subprocess is done by command line > argument. Selection of the datasets is done through the same arguments. This is excellent. Much more expressive than plot construction by point and click. Where do you envision that the plotting code will reside? I advocate for storing it on the Master PC in the same source file as the main experiment file. Perhaps as a new classes which inheriting from a subclass that does the heavy lifting. > * The subprocess is responsible for deciding when to redraw following a > mutation of the datasets. A basic "timer" should be provided as a Python > library, that delays the redraw after the mutation of a dataset, in > expectation of further mutations (e.g. on a XY plot, if the X dataset is > updated first, the Y dataset is usually updated soon thereafter and it does > not make sense to redraw immediately after the update of the X dataset). _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
