"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/