[Pipet Devel] What about viewers?

[J.W. Bizzaro]

Humberto Ortiz Zuazaga wrote:
> 
> I was a little confused about the WorkBench.  I thought figures were displayed
> in the Benchtop.

I think you mean "Workspace".  Workspace = Benchtop + FigBuilder (+ maybe any
GUI locus like viewers and editors)

> If I understand you correctly, there are three requirements for display loci:

("Viewer loci")

> present a control in the WFD on the Benchtop

Present at least enough information so that the WFD can make a control interface
with boxes, etc.

> present a figure in the FigBuilder

Yes.

> present a GUI in it's own window

If we are talking about a Viewer GUI locus rather than an Editor GUI locus, the
GUI == the figure + some extra buttons, etc. (or simply the "GUImegawidgets").

But the purpose of the FigBuilder is to _combine_ figures.  Otherwise, the
viewers will display the parts of a figure relating only to the data being
viewed (e.g., sequence, structure).

> So this would make the design like so:
> 
> Workbench = Browser + Benchtop + FigBuilder

or Workspace = (Viewers, which contain Browsers + Editors) + Benchtop +
FigBuilder

The glossary though just says Benchtop + FigBuilder.

> browser = code to handle display, benchtop controls, export to figbuilder.

Pretty much anything that would be in common between viewers.  But like a "Web
browser".

> display locus = plugin for browser code to manage specific LocusML entities

I haven't given this part a name, but it is Pythonscript + GUImegawidgets.

> We could colapse this further by making the browser == figbuilder.

I think you mean Viewer == FigBuilder (Browser is part of the Viewer).  As I
mentioned above, they will both display figures, but the Viewers will display
one figure.  The FigBuilder will display many and be a place to put text
comments, etc., like a vector drawing program.

I also want viewers to be transient (they will pop up and disappear along the
workpath).  The FigBuilder can stay open so that the final product (the figure)
can be worked on all the way through the workpath of the user's project.

> So all loci display directly on the figbuilder canvas, using loci display API,
> and present controls on the benchtop using loci control API.

Yes.  But "display API" == Viewer API.  I just don't want to add "display" as
another term, when it means the same thing to us as "view".

> Megawidgets could be provided that are written to the locus API, and are
> controlable with the benchtop API, providing programmers with building blocks
> for new display loci.

By "locus API", do you mean "Viewer API"?  If so, that is correct.

> Since the benchtop must have some way of controling a locus interactively, we
> can use this same mechanism to script a locus.

Do you mean script the workflow?  That's right.  And PAOS is "the mechanism".

> A locus that conforms to the display API and the control API, can now become a
> megawidget.

The Browser conforms to the Viewer API and control API.  I guess the other parts
of the Viewer (Pythonscript + megawidgets) use the Viewer API, if you are
calling them a "locus".  Any high-level repackaging (other than with the Browser
itself) of megawidgets can be called a "megawidget", if this is what you are
talking about.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro at bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--