Automatic plotting/configure applets from scripts

[dkienzler]

Original description

Is there a way to call applets from the script for given datasets or automaticly plot the output of a fit/scan etc.? If not, I think we need that.

Specification

• [x] Support for applet entries consisting of Python code, in addition to the current support for shell command lines. Editing such code from the dashboard shall be supported, in addition to the submission of code from the experiments.
• [x] Grouping of applets (one level only) in the dashboard’s applet list
• [x] In the dashboard, creating and deleting applet groups, renaming groups, and moving applets from one group to another via drag-and-drop.
• [x] In the dashboard, the ability to enable, disable, and delete all the applets in a group (not just one by one).
• [x] Support for functions create_applet(name, command_or_code, [default group]) and disable_applet() in experiments.
  • [x] These functions broadcast applet creation and deletion messages to all connected GUI clients
  • [x] The create_applet() function can receive either a command line string or explicit applet code as an argument (“command_or_code”).
  • [x] When an applet is created from an experiment: if its name already exists, the command or code of the existing applet with that name is replaced, and the applet is shown at its previous position. If not, a new applet entry is created and the applet is shown at any position on the screen.
  • [x] When an applet is created from an experiment: if the group does not exist, a new group is created in the applet list and the applet is made a member of this group.
• [x] Support for fully or partially ignoring the applet requests from experiments in the dashboard.

[sbourdeauducq]

How is this supposed to work?

[r-srinivas]

I think it means we should be able to start an applet from a script, i.e, create an applet with the parameters we want, set it enable so when you submit the experiment you can see the plot without having to separately set up the applet.

[sbourdeauducq]

Yes, but how is it configured? What if the applet already exists? What if the experiment creates an applet, then the user modifies its parameters in the GUI, and the experiment is run again - should it create another applet?

[sbourdeauducq]

When an experiment starts an applet, how to display it in a way that does not disrupt whatever the user was doing?

[r-srinivas]

Probably one would have to identify the applet by some sort of name. If it already exists, I think it should just enable the applet. If it doesn't exist it should create it and enable immediately. If the name of the applet is the same but the parameters are modified perhaps it should just replace the old applet of the same name?

If the experiment starts an applet I think it's fine if it just pops up like it does if you start an applet now. I imagine in the typical use case, the user has just submitted an experiment and wants to see the plot immediately so is expecting the applet to pop up somewhere anyway.

[dkienzler]

Hi,

I'm not sure if I under stand 'disrupt what the user is doing' correctly. Do you mean the current window, text box etc. looses focus? Or is there something more fundamental? Would it be possible to leave these decisions to the user? It might be that we see that we need some plots to open and focus and not replace other plots but some data from several experiments might be plotted in just one applet replacing whatever was in there before. Or we might want to plot several data sets from multiple runs of the same experiment in the same graph/plot. For now I would be happy to be able to open a applet and tell it what to plot from the experiment script. and the applet overrides an applet with the same name/id or just overrides the data with the new data, but leaves the position of the app as it was. Is there some documentation about the applets or some sort of roadmap/future feature list? One option might also be to include plots in the experiment window.

D.

[jordens]

That applet dock would appear at some random time. Completely independent and unrelated to a user action. This goes against HIG in a rather offensive way and kills usability. Imagine you are just dragging and dropping something or just about to click on some TTL button and the UI changes under your nose/mouse. In the worst case your click will now end up on the new applet. Sensibly, we could think about doing this but only at the request of the user ("fill/open suggested applets").

[dhslichter]

Come on, Robert. This was a hostile answer to a legitimate proposal for how things might work. If the user has the ability to select whether the applet receives focus or not when it appears (and the default behavior is for it not to receive focus), then users should be able to customize to their taste, regardless of generalized principles of UI design saying that having a window receive focus when it appears is not a good idea. If this is the functionality that is being requested by multiple users, it seems clear that it does not in fact "kill usability".

The big issue is this: right now there is no way of sending data from an analyze() method to be displayed in an applet in an automated way. So how about something like this:

• applets have a name attribute that can be set when they are created
• there is a method that sends data to an applet by name which can be called from an experiment.
• if the named applet does not exist, the default action is to create a new applet of that type with the specified name and dock the window without focus.
• the user can set a flag to have the applet come up with focus if desired
• some preferences menu (or other mechanism, such as a method that can be called from an experiment or a specific named boolean variable in the dataset) allows one to globally suppress automatic applet creation/population, if for example you are running an experiment a bunch of time to troubleshoot something and you don't want the applets to keep popping up (alternatively you could comment out the applet code for the moment).

What would the difficulties be in implementing such a specification? Are there corner cases not considered here that would need to be handled?

[jordens]

No Daniel. Calm down. It is hostile to attack the style of a contribution or the person behind it. And others would even take it personal if their technical comments are brushed away and consider that hostile. But attacking the content of a comment with specific criticism is not hostile. That's just an argument. You should really not use "many people want something like this" as a means to short-circuit a technical discussion on how to implement it.

Did you really just completely ignore the proposal to resolve my criticism?

If a user interface changes in certain ways (stuff appearing, disappearing or moving around) not as a response to a request by the user, then that's is problematic. Users are offended by applications creating windows and docks when they didn't ask for them and when they can't at least roughly predict when they will jump at them. Calm, organized, and predictable behavior of a UI is so much more valuable. The docks/windows don't even have to steal focus. Whether a new window gets focus or not is not relevant. Its mere appearance can easily lead to undesired effects because the user does not expect it.

This is not some hypothetical and obscure corner case construct that we are making up just to get rid of tedious feature requests: just try moving windows around or clicking on buttons in HfGui while it is starting and spewing more and more windows in more or less unpredictable places. Or a random fat news web page that changes while it is loading. Or just ads on the web.

The corner cases not considered are (summarizing what was said already):

• Windows/docks appearing or dock groups changing shape when the user is about to click somewhere or in general interacting with something. Sebastien mentioned it above and I elaborated a bit. But see the suggestion.
• How do you handle an experiment changing the definition of the applet, and if that's allowed how do you resolve conflicting/overlapping changes done in the dashboard? Sebastien already pointed at that problem.

But other than that who said the feature per se is particularly difficult to implement? It is just work. Doing it right and without breaking other things is what's difficult.

[jordens]

And it is instructive to see this feature as part of a bigger concept, scripting the dashboard. Both because discussing the bigger concept would provide clear and "obvious" guidelines on how to implement this and because other feature requests will come that also fall into this concept. Scripting the GUI would allow users to open/close/arrange groups of experiments/applets, implement typical lab work-flows (load ion, tweak things, do physics, keep stuff calibrated) etc.

[dhslichter]

OK, so let's attack the problem. Where/when do you propose to have a "fill/open suggested applets" feature? This cannot be a dialog box that pops up or else it violates the same UI guidelines that you have described. So how should it be implemented? If there is a dedicated permanent button on the UI that can be clicked by the user when desired, that would be good. So now the questions:

• this would seem to imply that there is a queue of applets waiting to be created. An experiment can send new applets to this queue, where they remain until the user clicks the "open suggested applets" button. Questions then are:
  • how is this queue flushed/cleared? One might run a bunch of experiments that want to create plots, but the user doesn't want to see. If the user then runs an experiment for which he/she does want the plots, clicking "fill/open applets" will then create an enormous number of undesired plots. One solution would be to have the queue visible (in a similar way that our experiment queue is visible), and have the same types of buttons to enable one to clear the queue, delete individual items, etc.
  • what happens when experiments request to create large numbers of plots (ones the user might not want to see, perhaps), thus making the queue very long and unwieldy to look through? For example, one might have a bunch of diagnostic plots in an experiment that may not need to be created/shown every time it runs. Should there be a checkbox that prevents experiments from populating the applet queue altogether, in this instance?
• how are updates to existing applets handled? If an existing applet is referencing a specific dataset, the applet currently updates whenever the dataset is updated by an experiment. However, what happens if one wants to put a new/different dataset into an existing applet? The analogy here would be to something like the HFGui common plot, where you have a window that can be used to show the latest counts vs scan variable scan, for example. This is primarily for diagnostic purposes in an experiment so you may not want a new window to pop up each time you change scan variable, for example. In the case of something like the common plot, you would probably not want to have to hit "fill/open applets" every time a differently named dataset is to be shown in the "common plot", so having a mechanism that allows one to update the data in an existing applet to new/differently named datasets without user clicks/interaction would be nice. However, one might want to have the functionality to allow the old datasets in the applet to persist even as the new ones are added in (for example, scanning some variable as you tweak something about the setup; you want to see if what you are doing is helping or hurting relative to the previous scan). How can this case be handled cleanly? It should not be default behavior. There needs to be a mechanism to clear the traces from a "common plot"-style applet (which could just be closing the applet), and a mechanism for determining if the previous datasets on a given plot will be persistent even when datasets with different names are sent to that plot.
• what about placing a "hold" on applets? If you get a graph you like, it would be nice to be able to make it (and the data plotted on it) persistent, such that future calls to the same experiment would instead create and populate a new applet. The datasets used for the persistent graph would not be the latest dataset value, but rather the particular value they had after the given experimental run when the . Thus the applet would change from referencing the current value of the datasets plotted to the saved values from the appropriate HDF5 file. The name of the applet would need to be changed, perhaps to something like originalname_RunID or some other unique way of specifying its name, so that subsequent calls to the identical experiment will cause a new applet for plotting the dataset to be enqueued, rather than overwriting the data in the "held" applet.

I think that a lot of these notions extend in a reasonable way to interfacing with experimental replay concepts, but all thoughts/suggestions/comments are welcome. All things with a checkbox/button listed above would also need to be scriptable obviously.

@dkienzler @r-srinivas I am interested in your thoughts on these ideas.

[dkienzler]

Hi,

@jordens @sbourdeauducq Right now we are typing the name of the data set in a new applet we create by hand in the GUI. this is very cumbersome. Is there some other way you intended the GUI plotting to be used? Is there some way of coding the applets? I don't think filling in dataset names in the GUI for ~ 200-400 experiments (which is minimum of what we've looking at for Quantum 2) is a viable option. Robert, I don't see a problem with a plot updating if it's in the background. Could you elaborate on this? This is actually the way the GUI currently behaves, if the applet is already open and the experiment is automatically re-run, the new data gets filled into the applet automatically. Another question: Right now everything seems to be happening in one main window. That's not very usable for a multi-screen environment. Is it possible to break the window up in several? Maybe I just haven't found how this works... (See also below for the option of a dashboard for plots.)

@jordens @sbourdeauducq @dhslichter @r-srinivas My experience originates from the Zurich Ionizer derivate, where you get a new plot window for every experiment you run. I see that it is not possible to use that scheme for a large-scale experiment with constant calibrations running automated. Still I think it's necessary to be able to look at these plots quickly. Do you think a dashboard might be an option, where all or most open applets live? (In Quantum 2 we are talking about ~5 calibration experiments run in the background, so not the 400 I was talking above about). I think a 'hold' feature like Daniel described it would certainly be nice, or a possibility to plot, say the last 5 scans of a calibration run, where always the oldest gets dropped when a new calibration is run. This would probably need some kind of counter on the data sets. I think the queue Daniel suggested is not the worst Idea. I would still vote for an option "open immediately". If you're operating a very basic experiment I think there is no danger of being overwhelmed by random plots popping up. The common window I think would also be a good think to have, for scans you run once in the morning, but don't have a calibration for running in the background.

[sbourdeauducq]

Right now we are typing the name of the data set in a new applet we create by hand in the GUI. this is very cumbersome.

2.0.dev has autocompletion.

[sbourdeauducq]

Another question: Right now everything seems to be happening in one main window. That's not very usable for a multi-screen environment. Is it possible to break the window up in several

You can resize the main window to span several screens, and detach docks and place them on other screens.

[sbourdeauducq]

a possibility to plot, say the last 5 scans of a calibration run, where always the oldest gets dropped when a new calibration is run.

The calibration experiment can maintain a single dataset with the output from its last 5 runs (e.g. as 2D numpy arrays where one dimension is the run number), and then a custom applet can plot them as desired.

[dhslichter]

Right now we are typing the name of the data set in a new applet we create by hand in the GUI. this is very cumbersome.

2.0.dev has autocompletion.

While it is a small improvement, this doesn't address the main issue -- one should not have to manually type in the datasets to be plotted in an applet every time. We need to be able to automate this completely given the number of plots that will be shown in typical use cases.

[dhslichter]

@dkienzler I don't think that having a new plot come up for each experiment run is the ideal way to go, given the complexity of things (although I don't think you are really proposing to do this?)

[dkienzler]

You can resize the main window to span several screens, and detach docks and place them on other screens.

OK. Thanks. I only tried this with the experiment window, for which it does not work.

[dkienzler]

@dkienzler I don't think that having a new plot come up for each experiment run is the ideal way to go, given the complexity of things (although I don't think you are really proposing to do this?)

No, not in principle, but possibly for each experiment (one for carrier A, one for rsb A, one for carrier B ...) But it would still be nice to have access to all of them. I played around a little and of course it's possible to just call the dataset the same in each experiment, that way they are going to be shown in the same window. But I guess that will make it impossible to later look again at old plots (and also it's discouraged in the manual). I think wildcards might be a viable solution. That way I could call my datasets 'X_DATASET_carier_xyz_time_scan' and call it in an applet with '--x X_DATASET*'. And I could still later open a applet to look at 'X_DATASET_carier_xyz_time_scan' specifically by defining '--x X_DATASET_carier_xyz_time_scan'. We would just need to make sure, that it always takes the newest dataset that maches the wildcard-string. I guess that way I would even be able to number the different runs of the experiment. Do you think that would be possible? Probably I've forgotten some caveat.

[sbourdeauducq]

OK. Thanks. I only tried this with the experiment window, for which it does not work.

Unlike docks, the experiment windows are captive to the main window. But there should be no problem with the main window spanning multiple screens.

[sbourdeauducq]

The analogy here would be to something like the HFGui common plot, where you have a window that can be used to show the latest counts vs scan variable scan, for example. This is primarily for diagnostic purposes in an experiment so you may not want a new window to pop up each time you change scan variable, for example. In the case of something like the common plot, you would probably not want to have to hit "fill/open applets" every time a differently named dataset is to be shown in the "common plot", so having a mechanism that allows one to update the data in an existing applet to new/differently named datasets without user clicks/interaction would be nice.

While not perfect, copying the dataset to another "common_xy_plot" dataset in the experiments is a simple way of doing this.

But I guess that will make it impossible to later look again at old plots (and also it's discouraged in the manual).

Old plots are archived in the HDF5 files, and there will be a separate tool (artiq_browser) to look at them. Though you may not want to archive "common_xy_plot" etc. in the HDF5s (but only the original copy of the datasets)...

[sbourdeauducq]

Would the following ideas solve most of the problem:

1. In addition to the actual datasets, experiment manage "display" datasets. Those work in the same way as the "common plot" in HfGui. A display dataset may contain data from multiple runs (e.g. the last 5 calibrations), and the relevant experiments push their own data and discard old data. Display datasets are broadcast-only and not stored in HDF5, unless they correspond exactly to a non-display dataset. The non-display datasets do not need to be broadcasted and are chiefly written locally to the HDF5 file.
2. For complicated cases, custom applets may have to be developed to correctly display and interact with the relevant display datasets (e.g. those that contains history). An example of an interactive applet with somewhat complex datasets is plot_xy_hist, to be run in combination with the histograms example.
3. RID and experiment name are attached to datasets (#229) and can be displayed by applets.
4. Applets gain a "hold" button that works the same as the hold button of digital multimeters/oscilloscopes.
5. Plotting data from the HDF5 archives is the job of the browser (#230) and/or user-developed scripts (HDF5 is a standard format and can be read by many tools). The browser may gain some scripting functionality (to be discussed) as we cannot simplify applets by having the concept of experiment-managed display datasets anymore.

[dhslichter]

These are good ideas, @sbourdeauducq , but I don't really see how they will address the main issue that was initially raised, namely automated generation of new applets from an experimental run. Are we backtracking completely on the "fill/open suggested applets" idea? The point is that we would like to be able to run experiments and have various results appear without having to manually invoke applets with specific dataset names.
To your individual points:

1. This would work, but it seems like we could already do this in the existing framework (except the broadcast-only, do-not-save aspect, which would reduce clutter in the HDF5 files but I think is probably not really that necessary). It does add complication/confusion to the existing design to have these two classes of datasets. I might just add a parameter like archive=True/False, similar to broadcast, to datasets, when created, to determine if they will go into the HDF5 file.
2. This would be nice, so you could see what last updated a given plot.
3. How does the behavior of the "hold" button affect updates? Are all dataset updates broadcast to the applet while on "hold" simply dropped? When the "hold" button is released, does the plot update with the current version of the dataset, or does it wait for the next broadcast?
4. Agreed that plotting retrospectively is the job of the browser/re-analyze. It seems to me that the same functionalities we are talking about for automated plotting from experiments would be directly usable for automated plotting from an experiment re-analyze functionality.

[sbourdeauducq]

Yes, with those "display datasets", I think that the applet configuration could be simple enough and rather static, and configuring them from experiments may be not needed.

Yes, the current framework can do that and already has an option to enable/disable HDF5 output per dataset, it is called save (not archive).

Datasets updates are never dropped and when "hold" is released, the applet updates to the current dataset immediately.

[ksmckay]

Im way behind in terms of actually using Artiq but trying to catch up but I will throw out an opinion anyway.

I agree that having random applets show up randomly on the screen is annoying and would drive me nuts but isn't that up to the user? Can't the user choose how to use that feature and make the decision themselves in their code.

I think the absence of the "common plot" would be really annoying. I see a lot of value in being able to write up an experiment that whenever it runs it updates the common plot. If I dont want a calibration routine to show up in that plot I can control that in the file, right?

And if i can have a "common plot" I can have "common plot 2" and so forth to use for calibrations or whatever. If the applet named common plot doesnt exist it should create it, if it does then it overwrites it.

None of this affects the integrity of the data right? The results are still stored, its just the real time plotting of that data, not analysis.

[sbourdeauducq]

Regarding your "common plot" comments, see my point 1.

[dhslichter]

All of this still does not resolve the question of having applets be automatically configurable/launchable. The approach @sbourdeauducq is proposing still means you have to manually launch applets for each of the desired named "display datasets" beforehand, and then each experiment has to reference those specific dataset names to come up in the already created plots. I still want to be able to have ARTIQ launch applets to display different kinds of data without my having to manually create the applets first. For something like just implementing a common plot (or several common plots), it's perhaps not so bad if one can script applet creation at startup (or if the state is saved each time). But let's say you do something dumb like accidentally closing the common plot, or you run a special calibration experiment that generates 3 different diagnostic graphs. One should not have to manually create all of these applets to see the data (remembering the names of the datasets to which the data is written etc). It should be possible for ARTIQ to create/recreate them automatically. The queue design for applets solves this problem while allowing for compliance with UI best practices, and can reuse code from the experiment queue for efficient implementation in the GUI. One can add a checkbox of "create applets immediately" to allow the user, as @ksmckay suggests, to have applets appear without having to click "fill/open applets", at the cost of disobeying the rule of not having windows pop up at random. Some people want this feature, but it should not be the default behavior.

None of this is at odds with what @sbourdeauducq has proposed, just adds a needed functionality.

[sbourdeauducq]

@dhslichter Closing an applet does not delete its configuration, it just unticks its "enabled" checkbox ...

[dleibrandt]

I would think that we could simply allow applets to be created but only in prepare, so that they would not pop up randomly and instead pop up immediately after the user presses run. Doesn't this satisfy ui design best practices? Then we don't need the queue, which sounds a bit annoying to use.

This is a feature I would like to have.

[sbourdeauducq]

That won't work, you can queue more than two experiments. Prepare stages are not executed in parallel.

[sbourdeauducq]

But we can define suggested applets in build and attach them to the experiment description (like arguments) for the GUI to use when submitting.

[dhslichter]

I really still fail to see what is wrong with having applets be generated automatically from experiments (without a queue) if they are docked and do not receive focus.

[sbourdeauducq]

Docked where and how?

[dleibrandt]

@sbourdeauducq - ok, right. I see the problem there. As you say, perhaps we could define the applets in build, so that they would pop up when the user opens the experiment from the experiment browser. One thing I think would be nice is the ability to have a checkbox "open applets" to control whether you want the applets to open or not, and I don't know how this would work if they are opened in build. Another thought would be that we could have a new method "submit" that gets called immediately when the experiment is submitted to the pipeline, and applets could be opened in that method.

[sbourdeauducq]

Worker processes (that are needed to run anything in a experiment) are created right before the experiment enters the prepare stage, not at submission. Keeping it that way saves resources when there is a long queue, which is why I propose attaching the suggested applets to the experiment descriptions instead of this submit method.

For doing this, build is actually not the best method, a new get_suggested_applets method called during repository scan after build sounds better.

[r-srinivas]

Would it be possible to have a specific window where applets launch instead of just creating a new dock per applet? Basically the same way all the experiment windows launch within the main window, except having a separate window just for applets that can be moved somewhere else.

[sbourdeauducq]

That doesn't really help with the problem of experiments opening windows in a way that is disconnected with the user's actions. You could be interacting with another applet when a new one pops up. Or are you suggesting this for another reason?

[sbourdeauducq]

An alternative and more user-friendly way to have asynchronous applet openings is to present the experiment-created applets in something that looks like a list or web page. New applets are added at the bottom without disturbing existing ones, and applets are removed when the user closes them.

An applet is put in hold mode automatically when the experiment that created it finishes.

Problems with that approach are:

• avoiding excessive resource consumption if the GUI is left unattended and too many applets are opened.
• a good way for the user to resize applets; maybe vertical (line) resize only is enough (NB: Qt is brimming with bugs related to tree/list layouts and to applet embedding - mixing both may create a toxic cloud)

In the browser, the list of applets created by an experiment could be stored in the HDF5 file, and the browser closes and opens the corresponding applets when a HDF5 file is selected. Since applet startup may be slow and there are UI problems with restoring the scroll positions of the applet list, we may want to do that semi-manually and/or reuse applets.

[sbourdeauducq]

avoiding excessive resource consumption if the GUI is left unattended and too many applets are opened.

When more than N applets are open, we could disable new applet creation and display a message prompting the user to close some (as a non-obtrusive banner above the applets, and there could be a warning there when M applets are open). We could also add buttons to close all applets and close all applets older than X minutes (or close the Y oldest applets).

That "applet page" functionality would come in addition to the more permanent applet docks already implemented.

[r-srinivas]

That doesn't really help with the problem of experiments opening windows in a way that is disconnected with the user's actions. You could be interacting with another applet when a new one pops up. Or are you suggesting this for another reason?

I was just wondering if limiting the area in which it could pop up would be enough, but I guess you're right in that it could still disrupt the user.

I think what you suggested is a good idea, and should have the functionality we want. There's maybe one more click than HFGUI has but this would mean the applet would only pop up without disrupting the user. Had a couple of questions though,

That "applet page" functionality would come in addition to the more permanent applet docks already implemented.

Would this be a separate list from the dock, then? It would probably be the easiest if all the applet information was in one place.

In the browser, the list of applets created by an experiment could be stored in the HDF5 file, and the browser closes and opens the corresponding applets when a HDF5 file is selected.

What happens if the different experiments share the same datasets, or if the experiment was run more than once? Would this load the data corresponding to a specific RID or just what's in the dataset_db?

[sbourdeauducq]

Would this be a separate list from the dock, then? It would probably be the easiest if all the applet information was in one place.

The applet page is populated by the experiments and operates independently from the applet docks. The only interaction the dashboard user has with the page is scrolling, interacting with applets (zooming on plots etc.), and closing old applets.

What happens if the different experiments share the same datasets, or if the experiment was run more than once? Would this load the data corresponding to a specific RID or just what's in the dataset_db?

Each applet locally stores a copy of the original dataset ("An applet is put in hold mode automatically when the experiment that created it finishes").

[ghost]

[image: Inline image 1]

I think we're making this too complicated. Here's a proposed solution that I think is easy to use and implement.

No more applets. All plotting parametric using code is contained in the experiment file. No popup windows or docks. All plots appear in one (or more) common canvases. GUI machine maintains minimal state. Canvas gets overwritten based on whatever experiment is running.

Create a new configuration file (canvas.pyon) that contains the following.

• named plot canvases with default location and size
• named plot zones within each window
• canvases and zones are used by all experiments as a shared destination for graphical output (see illustration)

Behavior at start of GUI.

• all plot windows appear (window name in printed in title bar)
• plot zones are empty (zone name printed in corner of each zone)

When an ARTIQ program runs...

• for each plot...
  • all the code needed to render the plot is in the experiment file
  • specify target (canvas, zone)
  • send code needed to render plot to GUI PC by RPC
  • as usual, stream data to GUI PC via RPC
  • if zone already has content, it is overwritten
• if program pauses...
  • other programs can use canvases as they like
• if a program resumes...
  • code needed to render plot at (canvas, zone) is sent to GUI
  • cache of data is sent to GUI
  • as usual, RPC is used to send data to GUI

Observations...

• windows and zones are for output only
  • zoom/pan individual plots using existing toolkit
  • zoom/plan is forgotten upon updating/replotting
  • if user wants persistent custom region of interest, edit the python source
• there are no "popup" windows, only the pre-defined canvas and zones -- window placement is parametrically defined
• for later experiment replay, need to record canvas.pyon (in HDF5 or git)
• ARTIQ remembers the location and size of canvases (but not zones' contents)
• plot contents are scaled (redrawn) if user changes size, location of canvas
• canvas zone contents persist until overwritten

On Tue, May 24, 2016 at 10:20 AM, Sébastien Bourdeauducq < notifications@github.com> wrote:

Would this be a separate list from the dock, then? It would probably be the easiest if all the applet information was in one place.

The applet page is populated by the experiments and operates independently from the applet docks. The only interaction the dashboard user has with the page is scrolling, interacting with applets (zooming on plots etc.), and closing old applets.

What happens if the different experiments share the same datasets, or if the experiment was run more than once? Would this load the data corresponding to a specific RID or just what's in the dataset_db?

Each applet locally stores a copy of the original dataset ("An applet is put in hold mode automatically when the experiment that created it finishes").

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/m-labs/artiq/issues/431#issuecomment-221286283

[sbourdeauducq]

Inline image missing. What is a canvas zone, if not an applet?

[dhslichter]

How about we make a single non-closable window at GUI startup (like the DDS or TTL windows, in a spatial configuration which is saved by ARTIQ between GUI restarts), which Joe has called the "canvas". The canvas is the "home base" for applet plots, and can contain one or more docked applets (again, in a configuration saved by ARTIQ between GUI restarts). The applets are all named. An experiment can send datasets for plotting to a particular applet by name. The experiment can tell the applet the names of the datasets to be plotted (i.e. the experiment can tell a given applet to change the datasets it is plotting).

The user can pop the applets out of the canvas to resize/zoom/etc, and these applets will maintain their undocked locations/sizes after GUI restart. If an applet is closed and an experiment subsequently wants to send it data, it re-appears docked in the canvas window, at the end of the current dock, without changing the focus of the canvas window.

Each applet should add a radio button set with the options "hold and drop", "hold and new", and "overwrite". If the first option is checked, subsequent datasets sent by the experiment to be plotted are just ignored. If the second option is checked, subsequent datasets sent by the experiment to the applet are instead routed to a new applet which is created as docked in the canvas. If the "hold and new" applet has name appletname, the new one will have name appletname_copy1, and so forth. The decision to create a new window is governed by the "hold and new" status of appletname_copyk, where k is the largest number if there are multiple new applets created in this manner that exist. When an applet of name appletname_copyn is closed, the applet should be stopped, not just made invisible (i.e. in current design, it should be removed from the applet list, not just have its "enable" box unchecked).

In "overwrite", the data in the applet is overwritten when the datasets change. If an applet is changed to "overwrite" from either of the "hold" settings, it is updated immediately with the current values of the plotted datasets. However, any "new" windows of the type appletname_copyn are unaffected by the change of status of appletname or any other appletname_copyn. When datasets are broadcast to applets by name (e.g. to appletname), they are sent to all applets with base name appletname (i.e. to all appletname_copyn). All copies appletname_copyn must plot the same datasets as appletname. If the name of the datasets sent to appletname changes, it will also change for all applets appletname_copyn. The compiler should throw an error if a user attempts in the experiment file to create or update an applet whose name ends in the form _copyn

This scheme:

• means no windows will be popping up in random places, in the way of the user's clicks
• allows experiments to dictate exactly what datasets they are sending, and to which plot
• gives implementation of the "hold" functionality, with a well-defined way for handling the case where an additional plot or plots are desired to compare with the data in a held plot or plots showing the same datasets
• doesn't require extra user clicks or operations for the creation/update of applets

[ghost]

Canvas zone is much like an applet. But where the source that defines what gets plotted resides in the experiment file. I've attached the image again.

[sbourdeauducq]

@jboulder What do you dislike about my "page" proposal? Or are you just trying to come up with an easier to implement system?

@dhslichter That window is very much like my "page", but a 2D grid and with the possibility to pop out applets.

[dhslichter]

@sbourdeauducq you are right, this is more or less your "page" proposal but enabling applets to be popped out. The 2D grid (a layout similar to how the TTL or DDS panels are laid out, with fixed size applets and column/row adjustment when the window is resized) would be good as well, but I think having applets just docked in the page as different tabs would be OK. However, I really want to be able to select specific applets to pop out to make larger or move to another screen location. I am fine with applets that are still in the "page" being constrained to a particular fixed size as long as they could be popped out.

@jboulder I think that the sort of gridded multizone plot array you are showing would be better suited to being its own applet, rather than the overall way in which plots are handled. I would much rather not be specifying grid coordinates in my experiment code, but rather resizing/rearranging plots using GUI tools as necessary. The grid zone scheme is both complicated to figure out how to populate (especially since many different experiments will be called, each potentially setting different applet positions) and also less flexible in terms of the allowed sizes and locations of plots than just manual layout/sizing in the GUI.

[ghost]

@jboulder I think that the sort of gridded multizone plot array you are showing would be better suited to being its own applet, rather than the overall way in which plots are handled.

That's an interesting idea. SB, can more than one experiment write to the same applet?

I would much rather not be specifying grid coordinates in my experiment code,

You wouldn't specify grid points in the experiment code -- this is setup once in canvas.pyon. Rather, you'd specify ("canvas1", "zone2") when plotting.

but rather resizing/rearranging plots using GUI tools as necessary. I'm aiming for expediency in implementation too.

The grid zone scheme is both complicated to figure out how to populate (especially since many different experiments will be called, each potentially setting different applet positions) I proposed that new plots overwrite existing plots. With a small number of canvases and a large number of possible experiments, the bookeeping of what goes where is then upto whatever convention is adoped by particular labs.

Broadly, I'm aiming for a solution where plot contents and plot presentation (canvas & zone) can be fully defined parametrically from within the experiment source. To me that's a higher priority than being able to click and drag to reconfigure things using fancy docks. I advocate to starting with less interactivity and adding GUI features that require sophisticated behind-the-scenes bookkeeping later.

-Joe

[dhslichter]

Since we already have the GUI set up to pop out applets, move them around, and have their states remembered, my proposal doesn't require much new stuff to be developed, which was part of my goal. While I agree that fully scripted plot/display windows could be a nice feature for users, it seems like a better intermediate-term goal rather than the short-term goal we should be pushing for here. Right now the idea is to get it so that experiments can create plots, any plots, from within the experiment code. It seems that having them be able to create complex layouts of plots from within the experiment code would be a logical next step, but perhaps not the first step to take.

[sbourdeauducq]

Since we already have the GUI set up to pop out applets, move them around, and have their states remembered, my proposal doesn't require much new stuff to be developed

It's not that simple.