On 04/17/12 06:49, Fabien Costantini wrote:
That said, flu combo tree rely on the full tree which permits path
navigations, not sure the Fl_Tree permits that ?
(i.e. /foo/bar would reference a root foo with a child bar)
Yes -- Fl_Tree supports paths (see examples which all use them):
On 04/16/12 18:45, Fabien Costantini wrote:
From the top of mind (I might miss some other flu goodies):
- Show leaves + Show branches - selectable independently
- Sorted, Front, Back, reverse insert api
- Shaded entries
- Multiple selection drag ignore
- {Vertical|Widget} Gap (Fl_Tree has
On 04/17/12 06:49, Fabien Costantini wrote:
Also, on the previous related Fl_Tree design discussion(selection list
as opposed to traverse tree like selection approach) , I wouldn't buy the
performance point on redraw() as you still know what to be redrawn from
the externalized selection list
If it's just the tree widget that's needed, I guess I have
to ask, before we embark on having two tree widgets in the
FLTK api.. perhaps I'm missing something obvious, but:
What exactly are the benefits of Flu's tree
over Fl_Tree?
From the top of
Of course read below : *NOT* to be ashamed of in any ways.
Yet, I am open to keep only one tree class if more conservative opinions are
emitted,as Fl_Tree is definitly a class to be ashamed of in any ways.
We could improve it continually instead ...
On 04/16/12 18:45, Fabien Costantini wrote:
If it's just the tree widget that's needed, I guess I have
to ask, before we embark on having two tree widgets in the
FLTK api.. perhaps I'm missing something obvious, but:
What exactly are the benefits of Flu's tree
Yes, glad I read this first ;)
On 04/16/12 18:49, Fabien Costantini wrote:
Of course read below : *NOT* to be ashamed of in any ways.
Yet, I am open to keep only one tree class if more conservative
opinions are emitted,as Fl_Tree is definitly a class to be ashamed of in any
ways.
