Widget Architecture:
During this analysis, we make the assumtion that:
The Fl_Tree_Browser Widget would inherits directly from Fl_Group.
This Widget would aggregate (at least) two Fl_Scrollbar scrollers, opaque for
the Widget user
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)
+ nodes manipulation:
+ add a node (could reuse FL_Group add() API)
+ remove a node (could reuse FL_Group remove() API)
+ remove all nodes
Note: In the case of a Fl_Group derived object a complete
sub-tree could be added by the same API
+ nodes selections
+ two selections modes: single and multi
A new Enumeration Fl_Selection_Mode with two states at least
(FL_SINGLE, FL_MULTI) could be created.
+ select a node (sets the Widget FL_SELECTED flag value to 1
and unselect other Widgets in single select mode)
+ unselect a node (sets the Widget value FL_SELECTED flag
value to 0)
Note: value() API could be used to select
+ unselected all nodes
+ node search:
+ (At least) at first increment Fl_Group find() API would do
the job nicely
+ Further developments could overload the find() API to provide
more efficient searches algos.
+ Tree walking
+ accessors to parent(),child(), children() API could suffice
as implemented in Fl_Group
More important matters/behaviors to decide
+ all items have same height (parametrable) ? if yes, things are much, much
more simple to handle but limits a bit the Widget use in the tree
+ dnd issues are not discussed
+ In this paper, we assume that using Fl_Group/Fl_Widget as the Composite
pattern of the tree is the good way to go,
another direction (which will partially make us loose the benefits of reuse
on Fl_group) would be to create a Node class
which would implement the composite pattern (not so hard to code though
partially redundant with existing Fl_Group code)
Having a separate Node entity would permit a better decoupling and
control between widgets and their containers
Talking about this, it is not obvious that we should accept any Widget
in the tree.
It may make sense to forbid some of them, and here probably a bool
selectable() const method in the Fl_Widget class would help
A 'selectable' Widget would be proven to behave/suit correctly in a
tree.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
