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

[Gary Van Domselaar]

"J.W. Bizzaro" wrote:
> 
> 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). 

HTTP works well with xml and would give us the hook into an
xml-compliant web-browser interface if and when this aspect of loci
comes about.


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

OpenDX also uses this approach.  Actually, Brad, did you ever receive
those rough Loci architecture drafts that Jeff and I hacked together?  I
wouldn't mind making a wp doc from those and posting it to the group,
once it gets the stamp of approval.  Maybe I should add _that_ to _my_
TODO list.


g.
-- 
                                  Gary Van Domselaar
                               gary at bioinformatics.org
                          http://www.bioinformatics.org/~gary
                ----------------------------------------------------
                           bioinformatics.org: The Open Lab
                            http://www.bioinformatics.org/