[Pipet Devel] What about viewers?

[J.W. Bizzaro]

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