Brad Chapman wrote: > > You are absolutely right. I have a way to kind of hack in support for > holding selected nodes, and I'll do that. The problem is that it is > not really consistent with the overall style of how I'm handling > things in the dl, which is to save all changes permanently in xml. I think node selection is not a permanent change to any network and should probably NOT be added to permanent XML storage. As I mentioned before, you may want to make a separate, temporary data structure to hold the ID's of selected nodes. > I think the biggest problem that I was trying to point out is that > I don't know if the streaming xml dialog is going to cut it, which > makes me *extremely* sad :-< I don't think we should consider scrapping it until a CORBA API is in place and proves to be better. > Another thing that we need to add is > support for the xml holding the position of nodes on the canvas. > Overflow supports this, and it will be necessary if we are going to > implement crash-recovery stuff and saving of work-flow diagrams. According to our simple rule, canvas positions are NOT common to all UI's, so they should not be managed by the DL. HOWEVER, speaking of "crash recovery", these positions are for permanent storage. A user can save a network and share one with others. It would be great if the network actually looked the same when reloaded. So, let me modify the rule a bit: I think the DL SHOULD save information such as icons, XY positions, widget descriptions/libraries in PARALLEL to the common network information. Brad, how can the DL manage this? I mentioned a while ago that if the DL kept XML info in the filesystem, such as... ls.xml then the DL could keep UI stuff along side it, such as... ls.xy ls.widget ls.icon But, I guess some things have changed recently. How would you do something like this now? As for Overflow, Jean-Marc said he recognized that node positions really shouldn't be included with the network XML. But my question is: Does Overflow REQUIRE the node positions in the XML? If Piper sends Overflow/PL a network description that does not include node positions, will Overflow crash? > However, if we keep pushing everything through the socket like we > this, using Piper is going to be as slow as surfing the web with a > 28.8 modem you got at a garage sale. Something we probably need to do > is start trying to define a corba interface to replace this dialog. Selecting nodes will be slow enough. I don't want to send XY info as well :-P > The problem with this is that I know implementing ui's on top of > corba will be more technically demanding then implementing them on top > of a socket with xml parsing stuff, so I don't know how this will > limit the desire/ability of people to make different ui's. > Specifically, I know Gary mentioned this previously, so I'm not sure > how he feels about all of this... I don't know if Gary is partial to sockets, but we both agree that simplicity matters. Again, I think we should continue to develop the sockets API until it is clear that a CORBA API is better. > Yeah, I guess so :-) That is why it is good to have lots of people on > a project, so you can have lots of ways to looking at problems. Go > open source development model! Woohoo! Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+