>       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 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 horizontal and top bottom)
- Animate: no really useful but so nice :)


>               C. Fabien's RFE regarding getting selected items as an >array
>                  instead of walking the tree (as we do with >Fl_Browser)
>
>                  This could be done, but it shouldn't be default, because it 
> means a large memory impact for apps that might not need it.

Not necessarily so much more , as if you maintain an array list then you don't 
need to store internally the item state -> could have readonly items (modified 
only at creation time) think about the safe feeling it can provide to guaranty 
by design that selection would not alter an item internal state ...

Also there would still be some more work to get th Fl_tree more convivial to 
use.
i.e.: the color scheme permits independent fg bg colors per item, nice but when 
you change the color in fluid they don't colorize correctly->too sad.
Of course I know about (and I use) the custom API for changing default color 
for items to be created but it's a bit of pain for 99 of the use I have of it 
and I might not be the only one...

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 ...

As a user of the fltk library, I like choice ; and would be keen on having an 
"Fl_Tree2" alternative or whatever it could be called.

As a developer, I also understand that maintaining 2 differents implementations 
is a bit more work.
That probably has to be ponderated by which class represent the most work to 
achieve the same level of functionality as the other ?

Like I said, I'm open on the question.



_______________________________________________
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Reply via email to