[Pipet Devel] UI/DL and selection

[Brad Chapman]

> But I think we need to have ONE clear and simple rule about deciding 
which
> function is handled by the UI and which is handled by the DL:
> 
>    Whatever is common amongst all UI's should be handled by the DL.
>    Whatever is unique to a UI should be handled by the UI.
> 
> Selection of nodes is something ALL UI's will have to do.  This 
means the
> code
> and system for doing this will have to be duplicated for EACH UI, 
and even in
> DIFFERENT LANGUAGES in some cases.

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

> Gee, it seems you and I are always arguing "code reuse" vs. "code
> duplication"
> ;-)

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!

Brad