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 l
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
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
> Actually I'm using Flu_Combo_Box derived classes Flu_Combo_List and
> Flu_Combo_Tree, because for a moderate size list Fl_menu shows it horribly.
Very useful widgets indeed.
That said, flu combo tree rely on the full tree which permits path navigations,
not sure the Fl_Tree permits that ?
(i.e.
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
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
>>
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 ...
__
> 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
