On 04/16/12 15:37, Fabien Costantini wrote:
>> Sounds like Fabien is willing to do the footwork
>> to port it to FLTK:
> Yes, I would but ...
>> I imagine it should be put to vote among the devs
>> to add it to the main branch, as it's a significant
>> bit of code.
> .. then indeed it would should be discussed what exactly we should import as
> many widgets might not be worth it today with fltk1.3 and sup.
>
> I would vote personally for starting with minimum requirements would be:
> A stripped version (no Fl_DND) feature of the Fl_Tree to keep consistency
> among the current 1.3 branch.
> END
>
> Now, in the eventuality that another tree class variant like the flu tree
> would be officially welcomed ; we would probably need a serious code
> refactoring effort which I can also lead but I would need discussion on the
> naming/scoping part.
>
> I'm in if the team also is !
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?
Are they that far apart that it's better to have two
then to upgrade the existing one?
I don't think they are, but I might be missing something.
There are four items I've seen mentioned in STR#2795 and the newsgroup,
namely:
A. >10000 items slow (STR #2795)
AFAIK, fixed in r9232 (as an ABI option)
B. Domingo's recent issue when nodes *are child FLTK widgets*.
(Above optimization was for non-FLTK widget tree items)
Hasn't been solved yet, but should be simple..
haven't had time to look into it yet.
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.
As it is, hitting ^A on 80,000 items has no memory impact.
But if selections were handled as an array, hitting ^A
would allocate an 80k x 4 array just to hold the selection
in a 32bit app (80k x 8 for 64bit apps).
If it were default, this dynamic memory use would happen
whether the app actually wanted to look at selections
as an array or not.
So it should be an option. As such, it could be added
to the existing Fl_Tree. But it shouldn't be default on.
AFAIK there's no benefit to draw time either way;
selection state is managed on a per-item basis,
and it's computationally trivial to check if an item
is selected.
D. Domingo mentioned the the Fl_Tree_Item class could be smaller
to allow derived classes to work with a more efficient memory
footprint when a Tree of FLTK widgets is used instead of
Fl_Tree
text items. This would avoid a few 10's of bytes per item
in his use case.
This can be done, but I think it's something that should wait
until a major release; doing it as an ABI option would I
think
be messy, not sure. It's a very specific use case that won't
affect most people IMHO.
AFAIK, Fl_Tree's item footprint is smaller than FLU's, so
there'
not even a savings there, whether that optimization is added
or not.
I was thinking Fl_Tree and FLU are somewhat similar functionally,
but perhaps I'm missing something.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
