Matthias Melcher wrote:
>
> On 09.09.2009, at 22:30, Greg Ercolano wrote:
>
>> Matthias Melcher wrote:
>>> Um, looking at BLINE:
>>>
>>> struct FL_BLINE { // data is in a linked list of these
>>> FL_BLINE* prev;
>>> FL_BLINE* next;
>>> void* data;
>>> Fl_Image* icon;
>>> short length; // sizeof(txt)-1, may be longer than string
>>> char flags; // selected, displayed
>>> char txt[1]; // start of allocated array
>>> };
>>>
>>> isn't that a subset of Fl_Widget? Adding a "selected" flag should not
>>> be an issue. Replacing all occurences of BLINE with Fl_Widget should
>>> solve the first step of converting to using true hierarchies.
You're missing the prev and next pointers for the linked list, but this could
be
replaced by the group's children() array. More allocation overhead (realloc for
growing children arrays), but faster access, e.g. by line number (that's
obviously a performance problem for browsers with many items). Side note: but
what is a line number for a hierarchical (tree) browser with nested groups? ;-)
>> I think making the browser items an Fl_Widget would add a bit
>> of unexpected FLTK overhead to the widget.. wouldn't that add each
>> widget to the overall FLTK widget hierarchy?
>>
>> I think Fl_Browser was designed with the items specifically to be
>> non-widgets for speed and low overhead on the rest of FLTK, not sure.
>
> Yes, you are right of course. The original Fl_Browser was designed to
> be ultra light weight. But that was a long time ago. Since then we have
> added per-item color and font support through the @-notation, patched
> check box support, file icon support, and now image support. That's all
> stuff that a true Fl_Widget incorporates anyways.
>
> We are duplicating code and now we even duplicate the same BLINE struct
> and add warnings in the source code to be careful about not changing
> this code.
... until it can be fixed in a better way :-)
Unfortunately we're in a position that we _have_ this code now. Doing a
redesign
would take lots of developer capacity, but should probably be done anyway
(later). However now we should concentrate on getting FLTK 1.3 up with the
remaining UTF-8 features/fixes and make a real plan (roadmap) for 1.4/1.5. But
that's slightly OT here and now, IMHO.
> By using Fl_Widget instead of BLINE the browser does become a lot
> heavier per item, but we can throw out probably hundreds of lines of
> code in Fl_Browser, Fl_Check_Browser and Fl_File_Browser dealing with
> special cases, and end up with code that is much easier to maintain.
Fully agreed. We can leave the old browser as it is for compatibility, but
create a new one with widgets, groups, and so on.
> On top of that, Fl_Browser would get all the benefits from Fl_Widget,
> including fonts, colors, check boxes, radio boxes, images, tooltips,
> even composited widgets.
Good point.
> Is this a waste for a Browser with 65000 entries? Sure! But is a browser
> with more than a few hundred entries user-friendly?
If it is a hierarchical (tree) browser (like a file browser), maybe. But that's
the plan, isn't it?
> Anyway, back to CMake ;-)
Yes, from what I've seen and learned about CMake, I really like the idea to use
CMake to support the IDE project files and _maybe_ drop autoconf (as Christophe
did for gmsh). BTW: I didn't see XCode in the list of supported IDE's.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
