[Pipet Devel] UI/DL and selection

[Brad Chapman]

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

Agreed. It won't be that hard because I already have this in place (to 
store passwords in memory). I was just mentioning how it contrasts 
with the beautiful model I'd tried to set up :-)

> I don't think we should consider scrapping it until a CORBA API is 
in place
> and proves to be better.

100% agreed.
 
> 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?

I would like to store everything in one format only, and I want to 
stick with xml since we already have that. I don't see any reason why 
we can't have an xml tag like:

<widget name='gtk_selection_widget' x='25' y='38' />

and if the ui doesn't have widgets (ie. a text based ui) it just 
ignores these tags (assuming it is using a script saved on a gui based 
ui). 
    I think one thing we don't need is more files being introduced 
into the filesystem and would like to keep everything describing a 
node in a single file of xml. If we introduce the idea of xml that can 
be parsed into a widget by the ui, then this should be in a separate 
file, but I want to keep simple info like widgets and x/y position 
together. *Most* uis that are implemented will want this type of info.

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

It requires it in the current api, but I'll just pass x=0 and y=0 to 
make Overflow functions happy, since the bl won't be needing this 
information anyways. I want to keep Jean-Marc's interface intact so 
Overflow still works standalone, but we can incorporate his code, 
which is why we'll have these extra attributes that aren't used, in 
the xml passed to the bl.

Brad