On 10.09.2009, at 00:52, Albrecht Schlosser wrote:
> 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).
Ouch, yes, why did I think that FLTK uses doubly linked lists for
that? Anyways, the "child" system is there, but "prev" and "next" are
quite time consuming.
> Side note: but
> what is a line number for a hierarchical (tree) browser with nested
> groups? ;-)
Every hierarchy has a fresh line numbering:
1
2
3
3.1
3.2
4.1
4.1.1
...
>> 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.
Sigh. Yes ;-). I was surprised how much work it was to get Fl_Input
UTF8 safe. I am not sure I want to touch Fl_Text_Editor :-) (well, of
course I do - I like my challenges, but I have no clue when I will get
a chance to do it).
>> 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?
Ah, see, in a tree browser, most groups are usually closed. And having
a hundred items within a group of a hundred items within... suddenly
is bearable, both for the user and the code basse.
>> 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.
It is. I just got it running on Snow Leopard. It basically works, but
I need to iron out a few humps (if you build only one target, all
others get deleted, for example, plus the "real" applications (Fluid)
don't get their app icon, "demo" does not find the menu structure or
the apps)
Matthias
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
