[Pipet Devel] UI/DL and selection

J.W. Bizzaro bizzaro at geoserve.net
Fri May 5 15:17:32 EDT 2000

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...


then the DL could keep UI stuff along side it, such as...


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!


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

More information about the Pipet-Devel mailing list