[Pipet Devel] What about viewers?

[J.W. Bizzaro]

Humberto,

I think we agree on the whole concept of a viewer: that there are internal and
external viewers.  It is important for the growth of Loci that it can be
expanded with viewers that do not follow the Loci standard of Python-GTK scripts
running in a "browser" (skeleton locus) and communicating with the Benchtop. 
Yes, the minimal requirement would be that it can manage the "LocusML" ;-)

I once used an analogy to basketball players passing around a ball.  The players
are the loci, the ball is the locusml, and maybe the path the ball takes is
PAOS.  I think when we're talking about internal and external viewers, it's like
a player from another team joins in.  He may not be on the team, but as long as
he can pass a ball, he is accepted.

What I have been discussing in these latter messages, is the internal viewer.  I
think we have to focus on that, and as things progress, we can look at how
others can implement external viewers.  You see, to manage this large project
more easily, I have defined a Loci "core" as being this pure, homogenous system
of basic tools.  I don't care if someone wants to add a Perl, or Java, or Tom
program at some point.  We do need to make sure it is possible.  But I want us
to develop this homogenous system to begin with.  This will define Loci.  If we
start with a mixture of languages and systems, it may be too much of a tower of
babel for us to manage and convince others that it is a standard they should
follow.

I was hoping primarily to connect command-line programs together and give them a
GUI.  I understand the need to allow other GUI programs to work with Loci.  But
I think the result would be a "bolted on" look, to quote someone I know ;-)  I
like the idea of a swallowed executable.  But I do think that anything that does
not maintain the look and feel of the Loci interface should be frowned upon by
us.  There are very good reasons to support a consistent L&F, the best one is
that users would be confused if presented with something very different each
time a window pops up.

Besides, if an external viewer is a self-contained executable with its own GUI
and printing capabilities, the reason for plugging into Loci becomes highly
diminished, especially if it can't communicate with the FigBuilder either.

> viewer locus: a program that uses the Benchtop API to display a bicml entity
> in a Benchtop (gnome?) canvas.

The viewer locus will display boxes on the Work Flow Diagram and figure in both
its own window and the FigBuilder window.

> external viewer: a standalone program (binary, interpreted script, ...) that
> can display a bicml entity in a window.

Yep.

> I think we should have the capability of using both.  That way we can just
> steal viewers wholesale (like NCBI's Cn3D structure viewer).

After the core is developed and well defined, this may be important for the
growth of Loci.

> If we could find
> a way of wrapping up a standalone program so that it displays inside a
> Benchtop canvas it would be even more awesome (compose a figure with the
> sequence and structure on the same "page").

I suppose by "Benchtop canvas" you mean any Loci canvas that can show locusml. 
The way I've been defining it is the canvas that displays the WFD and
drag-and-drop representations of documents, etc.

> Some window manager panels like
> FvwmGoodStuff, and the Siag spreadsheet can "swallow" X Window apps like this.
>  Siag can even print spreadsheets with embedded apps.

I'd like to look into this.

> 
> OK, so native viewer loci should display on the benchtop, with full
> interactivity.  At first, I guess these must be python scripts, perhaps using
> some Locus-megawidget library.  If we can export some kind of API to the
> benchtop, perhaps they could even be written in other languages.

Not as part of the core, but eventually.  You can see that there is no clear
line between internal and external viewers.  I would define a "core viewer" as
being a C-GTK locusml browser that can display C-GTK and PyGTK megawidgets using
a Python script.  Anything else is non-core.

> 
> External viewers would not have the ability to display on the bechtop, or be
> composited into figures, but would instead interact with the user in their own
> window, and be responsible for printing etc.  Note that external viewers must
> be able to understand and display a bicml entity, but we could use some kind
> of translation locus to wrap an external viewer that read CML in a BICML ->
> CML translator.
>
> A "swallowed" external viewer could display on the benchtop, and interact with
> the user, but might look "bolted on" instead of publication quality.

Yes, some of the many ways it seems we could make external (non-core) viewers.

> Wht not?  As long as it can display a bicml entity, it's a viewer.  If it
> can't interact directly with the benchtop, it's an external viewer.

Or external to a greater degree ;-)


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