[Pipet Devel] J.W. Bizzaro; TODO 20000218

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> > 1.  Split gi workspace up into many more modules to keep things easy to manage.
> 
> This is a really good idea. I was thinking it might be helpful to add a
> new connector/dot class (which will probably be needed once dots get more
> complicated). Then we could move the event stuff for dots/lines to this
> class and also move the locus event stuff to the locus class.

I was thinking about the event handlers being in their own modules.  But, do
you think splitting up such highly accessed methods (e.g., whenever a locus
gets dragged) will slow things down?  This is a question I have about Python
operation.  Maybe someone here knows the answer to that.

> > 2.  Make windowlets resizable via dragging frame.
> 
> Do we still need this if we have "automatically scrolling windows"?

Yeah, windowlets should have much of the functionality of full-fledged X
windows.  This is especially useful for composite/sub-workspace windowlets,
where you may need lots of room to work within a windowlet.  We/I will be
adding some 'window manager' features to the workspace.

> > 3.  Add multiple locus selection to gi workspace.  SHIFT-button1 and
> >     CTRL-button1 will do this.
> 
> This would be really helpful--they we could start setting up simple piping
> stuff (ie. a document to a viewer)

It is certainly needed to make composites: Select the loci to be composited,
choose 'composite' from pop-up menu, and ZAPP-O, one locus takes the place of
many.
 
> > 4.  Work on locus deletion.  Brad started this.  There should be 2 types:
> >     (1) complete removal and (2) change to a composite locus, which uses (1).
> > 5.  Work on locus disconnection via pop-up menu over connector.
> 
> Let me know if the stuff I did makes sense when you start looking at this.
> I might be able to make it cleaner/more usable if there are problems.

I was planning on making a method that is the inverse of the connect_loci
method.  I'll go check out what you did.

> > 6.  Add windowlets to locus connectors.  These will give connector status/info.
> > 7.  Pop-up menu needs to reflect the item selected: locus, connector or
> >     workspace.
> 
> Don't forget about my button 3 "fix." We'll need to think of something new
> to do for this if you want to start adding more functionality to the
> pop-up menu.

Right, I need to add that to my TODO list.

> > 8.  For the time being, I want locus addition to take place via DnD with
> >     containers.  The 'Add' pop-up submenu in the end will be for adding MIME
> >     and connection type-compatible loci to other loci.  We're a long way from
> >     doing that, so I want to remove it (Brad).
> 
> Okay, that shouldn't be too big a problem for most stuff since we have
> drag and drop working.
> However, what about database stuff--right now I'm connecting through a
> blank added container. How would this work under the new system?

Can we put a blank database container in one of the main
containers/directories?

    $LOCIHOME/back/private/container/

Blank containers are wrappers with an XML description (like all loci), right? 
Then we can put the wrapper in the container/directory.

(I know you argued for a different way to manage private loci.  I have to get
back to you on that.)

> > 9.  We need a locus clipboard for doing copy/cut/paste of loci.  I think this
> >     should be a subtype of the composite locus type and able to be placed on
> >     the workspace.
> 
> Do you have a plan for keeping these type of containers out of the way?
> Have a toolbar contiainer of useful loci? You could drag them out of the
> toolbar to add stuff to them, but when they get deleted from the
> workspace, they go right back to the toolbar. Is this an idea?

I was thinking the clipboard should be a 'composite' type locus rather than a
'container' type locus.  This is because composites preserve connectivity,
which should be preserved during copy/cut/paste.  Trash loci should also be
composite type for the same reason.  But then again, if you composite the stuff
that is to be trashed/copy/cut/pasted, you can then put it in a container.

As for keeping 'permanent' loci 'out of the way', How about having a 'hide
locus' option that makes a locus invisible although not deleted?

> > 10. Loci needs to start up with a few loci already on the workspace:
> >     containers.
> 
> Maybe this would be how to deal with the database problem I mentioned
> earlier?

Well, I think we can have a permanent container representing a Loci directory
(as mentioned above), and a blank database container can be pulled out.

> > 11. Establish communication pipe with middleware.  NOTE that the gi workspace
> >     is a 'dumb' front-end to the middleware, and that some of what has been
> >     hard-coded into the gi workspace (by Brad) needs to be abstracted out to
> >     the middleware.
> 
> You are absolutely right about this. The middleware and frontware XML
> stuff is especially tangled. I've started to untangle it, and this what
> I'll be working on asap. I think I have a better model for how this can
> work and how I can extract things to be nicer. A lot of that ugliness are
> my kludges to make things work when I didn't really have a view about how
> all the code would look in the long term. I see some things a little
> clearer now, and I definately think fixing this up should be a priority
> for me so that we'll have less code breaking in the future.

What may be confusing, and I'm not sure how much I wrote about this to you, is
that the front-end(s) and the middleware will communicate by sending XML tags
back and forth.  And the tags are commands.  Here's an example:

    <gi locus_select id=387hwj7843>        gi requests selection of locus
    <middle locus_select id=387hwj7843>    middle approves
    ...

The middleware will have to echo back an approval for the front-end to proceed.

This will be a 'dialog' that occurs through a pipe (Gary mentioned that this
might occur via HTTP).  This dialog can then be saved.  Recall early
discussions about an 'electronic laboratory notebook'.  Well, saving the dialog
allows us to do that.  Heck, we can even 'play back' the entire work session,
with the workspace reenacting for the user what was done.  Cooooool.

Plus, abstracting the middlware from the front-end allows us to swap something
else for a front-end.  Remember the natural language interface (NLI)?  Imagine
how that would work in place of gi:

    user>  Select the locus 387hwj7843
    loci>  Okay.  Locus 387hwj7843 selected.

The XML is always hidden from the user.

Gary and I developed this approach together.  If you have more questions,
perhaps Gary can join in on the conversion ;-)

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+