Give the user more data about what's happening under the hood

[liamhuber]

There's a number of places where we need to expose more data to the user. I've got a few gut reactions below, but it will need some digesting and trying things out to find really nice solutions overall.

From our discussion over in #54

• For situations like above it would be helpful to have debugging tools, e.g., nodes that show the error output, the jobs, hdf5 etc.

Hmm, I guess this is actually several issues:

For the case you mentioned above where remove doesn't do anything, I actually explicitly have except AttributeError: pass that triggers when the node thinks there's no job to remove. Cases like this could easily be replaced by things along the lines of except AttributeError: self.gui._print("No job found to remove").

For browsing jobs, hdf5, etc, I actually would really like to get this working in the "show" window. For instance, right now the project node shows just the project name, but that's only because I was getting funny errors when I tried to directly put the job_table() there -- this is still my goal. With your idea of putting buttons right into that window to manipulate output, we should be able to get even more power from that window without having to introduce new nodes.

Finally, Ryven intentionally suppresses errors that arise when nodes update. If I understand, the intent is to keep the Ryven instance running smoothly even when a node borks -- a very good idea! But you're right that I should find where Ryven is routing these errors to and re-route them to our log, or even perhaps to a GUI display.

[liamhuber]

A conversation between Joerg and me about getting access to the stdout of node updates

it would be nice to get the command to open and run a node in a separate cell of the jupyter notebook. I did it manually via gui.script.nodes[index_of_node] but this is rather cumbersome since the node index has to be obtained by trial and error. For example, the command (or a button) could be placed in the box where the input of the node is controlled.

This sounds like a reasonable idea to me, but I'll need to think/read a bit about implementation. Definitely adding some sort of "(force) update" button to the nodes is super easy. I currently have no idea how hard/easy it is to use that to trigger action in a new cell. An alternative might be to reroute the stdout to a convenient window inside the gui itself. I'll probably make a separate issue for this and play around with it later as it's (potentially quite) a bit deeper.

Having it inside pyironflow would be great. If opening a new cell turns out to be difficult generating a line (string) that can be copied into a new cell would already help a lot.

[liamhuber]

#123 exposes the stdout and ryven logger (which captures node errors) to a special logging screen, and gives toggles to modify this behaviour. #127 makes it very easy to play with different nodes in the notebook by just selecting them (gui.selected_node). #126 lets users look around the file structure by leveraging pyiron_gui.ProjectBrowser. IMO these together are enough to close this for now.