> > 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. I was a little confused about the WorkBench. I thought figures were displayed in the Benchtop. If I understand you correctly, there are three requirements for display loci: present a control in the WFD on the Benchtop present a figure in the FigBuilder present a GUI in it's own window bizzaro at bc.edu said: > You know, we can really makes things simple for the locus developer by > having a "locus browser". As I mentioned once before, the browser > would have all of the code required to communicate using the Loci > infrastructure. It really only needs a Python script to call on the > megawidgets. > Viewer = Browser + pyscript + megawidgets; So this would make the design like so: Workbench = Browser + Benchtop + FigBuilder browser = code to handle display, benchtop controls, export to figbuilder. display locus = plugin for browser code to manage specific LocusML entities We could colapse this further by making the browser == figbuilder. So all loci display directly on the figbuilder canvas, using loci display API, and present controls on the benchtop using loci control API. 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. Since the benchtop must have some way of controling a locus interactively, we can use this same mechanism to script a locus. A locus that conforms to the display API and the control API, can now become a megawidget. -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz at neurobio.upr.clu.edu