Humberto Ortiz Zuazaga wrote: > OK, I sit down at the Workspace, and use the Benchtop to guide the analysis, > using PAOS to control the actions of loci, both GUI loci and analysis loci. Yes. But I have been causing some confusion by saying that PAOS == Workflow System (WFS). Right now, all we have is PAOS, which is an active object server. It needs to be extended further to make a WFS. At the bottom of this message is a copy of what Carlos wrote about the WFS. > The ultimate product of an analysis workflow is a figure, displayed in the > FigBuilder. Intermediate results were presented by GUI loci (either in their > own windows or in the "Viewer"), for review or editing. Pretty much... A viewer is a type of GUI locus. A viewer has a window. The window is a "browser". The browser displays graphics. The graphics are generated by Python GUIscript The GUIscript represents the biodata. The biodata comes from the analysis. > An alternative is that selecting a figure in the FigBuilder enables editing > and control of that particular figure. Instead of viewers opening and > disapearing, all interaction with the user is through the FigBuilder. I suppose we can have one giant viewer (the FigBuilder), as long as it can be as dynamic as I was planning on making the other viewers. This just might be more difficult. For example, I thought a viewer would allow the rotation of a protein in 3D. This would be simpler if the viewer involved had nothing else going on. A static picture of this 3D protein would show up in the FigBuilder when the user is finished making adjustments. The FigBuilder maybe can handle all sorts of dynamic interactions happing at the same time, but it would be (1) more difficult to make and (2) slower for the user. So, the way I imagined it, FigBuilder is for the static view of the final product (the figure for publication). The Viewer is for the dynamic manipulation of an individual _part_ of the figure (you can put buttons, etc. on the viewers too), so there may be many viewers. (There may be many FigBuilders if multiple publication figures are being worked on). Editor is for the editing of the biodata. It will of course affect the figure in the viewer and the FigBuilder. FigBuilder == static Viewer == dynamic Do you think maybe each viewer should be a FigBuilder? Do you think this would be much more complicated? > So I'm dense: I'll admit I still don't get paos. I read the english > translation of the article at > > http://www.cs.colorado.edu/~carlosm/paos-english.html > > but I thought PAOS was just a mechanism for persistent object storage in > Python. I'll go do some more homework. So if I set a slider on the Benchtop to > ktup=6, PAOS can communicate with the analysis locus and set the appropriate > variable to the value I've chosen? Yeah. As I mentioned, PAOS will need to be extended to make a WFS. See below. > What I want to be able to do is compose a > new viewer or widget by taking an existing viewer or widget, and wrapping it > up in some code to present a dialog in the benchtop, and pass control options > back to the original widget perhaps after some preprocessing. Like subclassing > a viewer. Passing via PAOS? It should be doable. There are more updated terms for what Carlos says below: Gnome clients == Benchtop + FigBuilder Tool Manager == The part of a viewer (or maybe a separate process) that communicates via the WFS. >From Carlos: I totally agree that Paos shouldn't shuffle around real data. I see the role of Paos as a coordination tool but not as a database management system. I attached a GIF picture to this mail. This picture contains Gnome clients, Paos server, and Tool Manager (excuse me if I introduce yet another set of terms). Gnome clients and Tool Manager are Paos clients. A Gnome client consists of a GCL editor and progress monitor, among other things. A Tool Manager - parses XML data and forwards it to the actual tool, - turn the result of a tool into XML data and send it to another tool manager - sends status information to a Paos server (e.g. processing started or completed, or processing ran out of memory), - receives notifications from a Paos server (e.g. "suspend", "abort", or status query), - queries a Paos server about where to send results to, The thin lines are communicating Python objects, the thick lines communicate XML structures. Note that the destination of Tool Manager can also be a Gnome client which is used to visualize results. -------------- next part -------------- A non-text attachment was scrubbed... Name: tulip-architecture.gif Type: image/gif Size: 3548 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/19990413/60022bbb/tulip-architecture.gif