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
>> over Fl_Tree?
>>
> From the top of mind (I might miss some other flu goodies):
> - Show leaves + Show branches -> selectable independently
Yes, I didn't implement that one, but I take it to mean
one can show the tree as 'branches only' (such as
'directory browser' only shows folders, without files),
and vice versa.
I think it can be added trivially though by adding
a global preference, and adding a simple change
to the draw() routine.
> - Sorted, Front, Back, reverse insert api
I think this is in there already:
Sorted -- Fl_Tree::sort_order(FL_TREE_SORT_ASCENDING)
Front -- Fl_Tree::add()
Back -- Fl_Tree::insert(pos=0)
Reverse -- Fl_Tree::sort_order(FL_TREE_SORT_DESCENDING)
I could add Front and Back so that 'Front' changes
add() to call insert(pos=0).
> - Shaded entries
Yes, I think of these as 'ruler lines', where every other
item is colored a slightly darker shade.
Should be easy to add of global fg/bg colors are implemented;
see below (**).
Perhaps too, a value to let one to set /how many/ items
are drawn in alternating colors, ie. 1 for odd vs. even,
2 for every two elements, etc.
> - Multiple selection drag ignore
Hmm, yes, if I understand that right, a per-item flag
that lets one disable some items from being 'selectable'.
I should probably change the open/visible/active/selected 'char'
to be a single 8 bit char flag, so as to be more memory conservative.
(in the end it might still take 4 bytes, because most compilers
probably like to keep structs/classes 'word aligned')
> - {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)
Yes, sounds like an omission.
It sounds easy to add, but would have to look.
> - Animate: no really useful but so nice :)
Yes, I didn't delve into animation effects because none of
the FLTK 1.x widgets go there, so I decided to be 'consistent' ;)
FLTK has no precedent for such features either, and I didn't
want to pioneer one. To be done right, I could see users wanting
speed control, custom behavior control via virtuals, callbacks,
or derived classes.. didn't wanna go there ;)
>> 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
Ah, but I think you do have to store item state internally
to keep redraw() and mouse selection fast.
If during a redraw() every item involved a lookup on
the selection array, doing simple things like scrolling
and dragging mouse selection would be slow.
Also: if I switched the Fl_Tree_Item to using bitflags
for open/visible/active/selected instead of separate chars,
the added memory would be 1/8th of a byte ;)
> -> 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 ...
Heh, never-the-less, I'm unmoved. ;)
Pretty sure the need for draw speed and memory footprint
trumps that.
But if there's a way draw() and general selection overhead
can be kept trivial without heavily impacting memory, I'd
be more open.
I think the only way to get the best of both worlds is to
make it an 'option' that is default off, with a method
that returns an array by either taking a single pass at
the tree (if the option is off), or refers to a selection
array (managed by the tree if the option is on).
I think this is a big thing to implement for what I imagine
is a small use case. (I wouldn't think an app that deals with
large lists of data would need the selection list often
enough to need such an optimization where a single pass at
the list would be too slow. This can also be worked around
by other means, such as with selection state callbacks)
I also defer to Fl_Browser's current and long tested behavior;
to find a list of selected items, walk the list to determine it,
with a convenience function that does the same.
But I'd take further input.
> 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.
(**) I could probably have a per-item bit flag that, if zero,
uses a global fg/bg color (set in Fl_Tree_Prefs),
or if set, uses each item's own fg/bg color.
> 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...
I see.
I think that is easy to add with the above.
> 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.
I like choice too, but I think the features mentioned
can be added to Fl_Tree easily.
However, overall design changes, like some other way
to do widget inheritance would be an overhaul. But
I'm not sure there'd be a need for that.
> 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 ?
Not only that, but it impacts other things too:
existing developers using the existing Fl_Tree API,
fluid support, and having two duplicate widgets that
pretty much are the same functionally.
> Like I said, I'm open on the question.
Right.
I suppose I'm in a position of bias, but had this been
about a widget I didn't write, I'd feel the same way:
add features to the the one we have, rather than add
a second widget with a different API for more or less
the same features.
The new ABI feature stuff allows us to make such changes
in maintenance releases, so we're not as limited in
movement as developers.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
