Am 30.06.2009 9:20 Uhr schrieb "Gerry Weaver" unter <[email protected]>:
> FLTK2
>
> After spending some time looking at the source for both FLTK-1.3.x and FLTK2,
> I'm kind of left wondering about the goal. I understand that api cleanup was a
> line item, but it seems like there should be more.
FLTK1 was trying to stay compatible to the Forms Library from which the
FLTK1 API originates. FLTK2 was started to clean the API and bring few new
ideas in (UTF8, truly hierarchical menus, zero based groups) but did not
really extend functionality that much. FLTK2 was pushed by Bill at first
because he had a huge application (Nuke) depending on it.
But when FLTK2 was "good enough", support was going less and less. A few
pople jumped on for a while and added quite specific features that were
needed for their projects.
With every addition, more bugs were introduced, and platform support fell
behind. FLTK2 IMHO has become a jungle of good intentions.
FLTK1 has a somewhat different story: the API was fixed (Forms Library) and
the internals were a jungle to begin with. The API got worse over the years
because additions were not always consistent, however the code under the
hood by now is very stable and as for 1.1.10, virtually bug free.
Now, 1.3 has become the new hope, and all 1.1 bug fixes always go into 1.3
as well. So lloking at 1.3 it seems to have a scary and long bug list. But
looking into the details, most of these items are redundant and are
relatively minor stuff that was put off for 1.1. What 1.3 needs is full
UTF8/UC support and a release date. Other than that, it is a great library.
> The thinking here is that
> maybe the FLTK2 api should provide a higher level set of widgets. For example,
> I've been working on porting an existing application to FLTK1.3.x. There is a
> part of this app that needs to display pdf files. In FLTK this translated to a
> combination of Fl_Scroll, Fl_Group, Fl_Box, etc.. I found myself wishing for a
> higher level scrolling widget that would simply let me add widgets to it and
> handle all of the scrolling and resizing behavior for me.
FLTK1 and FLTK2 are largely redundant in what they can and can not do.
Putting a group into a scroll is not magic, but there should be some
additional resizing strategies available. All that can be sloved in a new
group or by extening the standard group.
> However, if your writing a business oriented app, perhaps you would
> want a higher level more functional set of widgets. Then, of course, you
> would link in the higher level library.
Sure, no problem with having higher level widgets. FLTK already is a
collection of libraries and I see no fault in adding a higher level library
that provides basic document view management. I would recommend to not get
lost in this tough, because there are plenty of cross platform libraries out
there that implement stuff unrelated to a GUI (threads come to mind, etc.)
> Low Level Abstraction Layer (HAL/PAL)
>
> This is something that we are very interested in. This interest has been
> echoed by a few devs on the forum as well. The project would benefit from this
> in many ways. We have already started working on this one.
Again, great thing to have, especially if two or more HAL's can coexist in a
single application. My priority still is UTF8 though.
> UTF8
>
> The consensus among us is that we don't have enough knowledge between us to
> actually make any significant contribution to the UTF8 code. However, we do
> have a lot of experience with cross-platform development. This being the case,
> we plan to look at the UTF8 code from that perspective and as it relates to
> the abstraction layer above.
UTF8 is no magic at all. The biggest issue is to replace all functions that
assume 8bit characters with the corresponding UTF8 counterparts. Much of the
keyboard handling is alredy done.
> Themes / Skins
FLTK1 once had a very extensive "theme" implementation (not to be confused
with the current scheme API). It was removed because when the author stopped
supporting it. Thems made the code incredibly complex and was rarely used.
Sure, skins are cool, but there is a very high price to pay.
> CMake
>
> We plan to bring the CMake build current.
That would be wonderful. If that Cmake setup also solves the issue of
generating new IDE support files for VC, Xcode, etc., you'd earn your first
FLTK support medal ;-)
Matthias
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
