[Scilab-Dev] SEP #15 : Scilab Tree component

[Bruno JOFRET]

Hi Francois,

First thank you for reading that SEP !

> Well, GED is one of the hosting environment explicitly targeted by 
> SEP#15 in its introduction.
> Another target is "Any user's uses for tree visualisation".
> I understand therefore that trees will be displayable only in their 
> single window detached from the rest of any other GUI? Isn't this too 
> bad? Why not taking the opportunity of having just a tree widget like, 
> say a scrollbar widget, that can be placed in a larger GUI? My point is: 
> GED should not be a special case but the standard use case.

To start from the beginning of the story, we just wanted to have 
"something" able to display a tree in the Java GUI, specially for Scicos 
Pal Tree and Ged. So the only need we add was a Java Component.

But, keeping our ideas as wide as possible, we decided to make the tree 
visualization available from Scilab through a "Tree" representation and 
not only within Java code.

Right after came the question of having it available through the 
uicontrol system... But we had to fix one point to start and so one to 
stop.

The aim of SEP #15 is to provide a Tree Visualization :
Let the user define "something" that looks like a tree and dump it with 
some text in the console or with a gui.
Nothing more ... For now ;-) I let you read further for surprises :-)

> - Abstract says "This tree will be integrated in the docking system and 
> will be used for visualisation only". What do you mean exactly by "for 
> visualization only"? What other use do you have in mind that you want to 
> prevent by saying this? The user editing nodes labels for instance? What 
> else?

As I told before, this SEP is a first and very basic one that just deal 
with "showing" what is stored in scilab.
We just wanted to warn that we are not creation a Tree "editor".
For instance, what could be interesting is to create "graphically" the 
tree : Context Menu with add child etc... etc...
But that's not the spectrum of this SEP.

> - Performance: you plan to use tlists while Serge pointed the finger to 
> handles. Did you consider performance issues for large trees? Which is 
> the best in front of the performance criterion? Handles or tlists? Is 
> this question perhaps pointless (not sure handles are not some kind of 
> tlists anyway)?

The fact is we do not see any "need" to use handle for the trees.
They are Scilab variable so they act as this.
_BUT_ if you want to be able to manage this tree within a user GUI, you 
will need a handle : that's true. But it will not be provided by the 
tree itself, but by the uicontrol function for instance.
Handle are special Scilab variable that behaves """"""as objects"""""", 
and we did not identify any needs of that kind within the tree structure.

> - Callbacks:
>   ~ I understand that the callback string is a call to a function 
> written in Scilab language, right?

You are totally right, but it can be some piece of code too.

>   ~ Is it possible to have any Scilab code here, for instance 
> disp("hello"), or anything else, say a very long loop?

I do not see anything that can disturb this... So I will say yes.
To be a bit more technical, the callback mechanism is the same you can 
have with addmenu.

>   ~ Can I have Tcl calls such as "TCL_EvalStr(...)" in callback strings 
> and/or in Scilab functions called by the callback?

Once again it's Scilab code... So it's up to you ;-)

>   ~ How is the callback executed and when precisely in the Scilab event 
> loop?

All the callback are stored through the command queue.

>   ~ I think it could be an improvement to have another type of callback 
> which would be a direct call to a Tcl procedure written and living in 
> the main or in a slave Tcl interpreter. What do you think?

Well this means to have a hard dependency between Java and TCL...
I'm not sure this will be a good idea. Did you identify some needs for 
this ??

> - trees, nodes and leaves: I think I understand that a tree is composed 
> of nodes. Each node can be either a tree (in which case it is said to be 
> a sub-tree), or a leaf. Is this statement right? Actually you do not 
> seem to define what is a leaf (OK there are clues on page 12). Is it 
> simply that a leaf is a node without children or is it more subtle?

If we consider the types, everything is a Tree.
For "human" understanding, we talk about leaves, nodes and sub-tree.
But you are right, a node without any child is called a leaf.
(Even if they have all the same type : Tree)

> - sub-trees: SEP page 2 says "subTrees should be created before the tree 
> creation". This looks like a strong limitation. How will you handle this 
> in an environment such as GED, which will see sub-trees added whenever a 
> new curve will be added in a figure? I think most of the time you do not 
> know in advance what the tree looks like after the user will interact 
> with it. Note that this interaction may be indirect.

Well this is the crucial point, and I will try to be clear here.
The aim of the SEP is to define a Tree Structure, accessible through 
Scilab and that we can show within a GUI.

For the GED use, we will reuse the Java component that do the display.
_BUT_ it's part of GED work to watch what append in the graphic data 
structure, and to synchronize it with the Tree overview.

> - Insertion: How can the user insert a node at the very end of a tree, 
> i.e. after the last node? I don't see how it is possible. (see the top 
> of page 3 in SEP#15 and the list of errors for insertion). Actually I 
> don't see how insertion works at all. In the list of error messages it 
> is said that "if position already exists it returns an error message".

I'm not sure a very long explanation here will be good.
I keep your remark in mind and as soon as the Scilab part will be 
written, I will add this as an example.

> - I think that treeNodeParent(tree, node) may have more than one match 
> if the same node can be found at different places of the tree. How is 
> this handled? Does it return all matches? The first (in some sense TBD) 
> match? Another one?

Same things here ;-)

> - Similar comment for treeNodeChildren(tree, node). The output might 
> need to be a list containing lists of children nodes for each occurrence 
> of node in tree, unless only one children is returned even if there is 
> more than one match. On page 7 you explain that a warning is returned in 
> that situation, but what does the command return? The first match?

Same answer :-D

> - User interaction (SEP page 8) : the user can select a node or leaf. 
> What for? What can the user do once this is selected? Is it possible to 
> select more than one node? Can this behavior (single/multiple selection) 
> be decided by the programmer? Also, how can the programmer be aware that 
> the user selected one or more nodes in a tree?

Once again, the SEP describes a visualization tool and that's all.
The only action you can have on the "visualization" GUI is a double 
click that launches a callback.

> Finally I have seen that the implementation work for the tree object was 
> already committed but I couldn't figure out of to access the new 
> commands. Scilab says it does not know about the new commands. Anythin I 
> need to do to gear the new feature in? I would be happy to try the 
> examples from the SEP.

We are working on it ! :-D Please be patient.
For the moment we just implemented the Java part, so you can only access 
it through Java...
By the end of the week we will have the Scilab part, that represents the 
data's. After this you will be able to run the example and to "dump" the 
Tree as text in your console.
The last step is the link between the two. I guess it will be available 
within 2 weeks.

Regards,


-- 
Bruno JOFRET

       Software Designer
   ___ SCILAB - DIGITEO ___
   Tel : (+33/0)1.39.63.58.63
Mailto : bruno.jofret at scilab.org
    http://www.scilab.org
    http://www.digiteo.fr