Fabien Costantini wrote:
> API proposal:
> Nodes
> A node is the elementary entity which could be any (selectable)
> Fl_Widget derived object,
> two flags could be added to the Fl_Widget state:
>
> FL_SELECTED : valid for any widget, 1 means selected, 0 means not
> selected
> FL_OPENED: valid for a group, 1 means corresponding node is open
> in the view, 0 means node is closed
>
> A a node would also be a Widget, its layout could be controlled by
> the Tree Browser as follow:
> Two glyphs would be considered:
> + for all groups a group glyph would be first indented
> and drawn (like a + or a '>')
> + a widget default image would be the node image if
> any, this image could change when the node is selected,
> and also optionally when the mouse is over it (would
> need more images() flags and memory if we reuse this API)
Sounds like by default this node widget would have its own
methods for setting the open/close images, the 'type-of' image,
and the text area's contents and its font styles.. sounds good.
Custom Widget
I think it would be good if the app wanted to specify their
own widget, it would not replace all of those items, but maybe
only the text area of the node; it seems like the open/close
icons would still have to be there because one should be able
to click on those to open/close the tree (if it's a 'folder' node)
without the app's widget having to handle that.
> + nodes manipulation:
> + add a node (could reuse FL_Group add() API)
> + remove a node (could reuse FL_Group remove() API)
> + remove all nodes
Insert
Probably an insert() convenience would be good to have too,
even it just calls add() with an optional position argument,
eg. insert(w,pos) would just do an add(w,pos).
Open/Close
Also, an open() and close() method to make parts of the
tree open/close-able from the app.
Invisibility
Also, the ability to make individual items 'invisible'
without it affecting the open/close behavior. The ability
to make things invisible is useful for app 'filter' behavior
(ie. 'only show me the parts of the tree that contain the word xxx')
Optimization: Avoiding Unnecessary Recalc()s
One optimization I'd recommend is avoid having add()/remove()
call any kind of potentially heavy recalc() call that descends
the entire tree each time, since this can cause exponential
slowness when the app is loading a large tree.
Things could be arranged so the recalc() could be done only
once, after all the changes have been made.
One way to do this might be to have the add/remove calls
mark the tree 'dirty', and not do any recalc() calls.
Then, at draw() time, the widget would see the flag, clear
it and call recalc() just before doing the draw().
Similarly, other methods that might be called that depend
on a recalc() should do similar checks, in case such a
method is called just after the tree was constructed,
but before it was redrawn.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
