matthiasm wrote:
> ...
> The bigger question for me right now is, where is FLTK heading? How many
> users do we have currently, and how many do we want to attract? How do
> we want to compete with the Qt's out there? And do we want to compete at
> all, or stay in our niche? Or do we attract additional niches, like the
> embedded developers?
For me, the two main features I'd like to see in FLTK are UTF-8 and
printing support. There is already a considerable amount of code for
1.x that could be integrated to provide this, and IMHO we could
probably push it out faster than fixing 2.x.
The kicker is that I, unfortunately, probably won't have much time to
devote to FLTK for at least the next 6 months - build testing and server
maintenance is about all I'll be doing, plus the occasional bug fix. :(
> Whatever we do, we must re-bundle our energy. Splitting developers
> between 2.0 and 1.1 is a drag! But how can we get our commercial
> developers to agree on, and use the same version? "Nuke" has been with
> 2.0 for a long time now and can not "downgrade" to a 1.1 style
> interface. "Rush", Greg's software is still on a patched 1.1.6 because
> 1.1.8 is missing UTF8, but 2.0 is not stable enough. As for myself, I
> would only switch to 2.0 if I can keep the source code mostly intact.
> 500.000 lines of interwoven FLTK code are not easily changed to a new API.
I also have a lot of 1.x code, and the 1.x compatibility stuff in 2.0
isn't good enough to build any of it.
> But that brings me to my biggest issue with 2.0: the 2.0 bug list it
> full of bugs that I fixed for 1.1, and I have no intention to fix the
> same stuff again for 2.0. Yeah, I would like UTF-8 support and some of
> the label functions of 2.0, and yes, the interface is cleaner, but that
> doesn't help my existing code.
>
> So here are three possible solutions. Please comment and add solutions
> if you have any ;-)
>
> Matthias
>
>
> 1. continue separate development of FLTK1 and FLTK2:
>
> This would mean that 1.1.8 becomes the base for a new attempt at FLTK
> 1.2. We would then apply the UTF-8 patch and change the API to finally
> bring FLTK 1 up to par with other GUI libraries. FLTK2 would remain in
> Alpha stage until someone puts the effort in to fixing the STR's.
There is/was a printing patch as well that I'd like to incorporate if
we go this route. The main sticking point is UTF-8 printing support -
not hard on Windows or OSX (because they use the same API for printing
and display), but UNIX/Linux needs PS (or PDF) output and UTF-8 is
non-trivial to implement. I'm working on some stuff for CUPS and
HTMLDOC that may be applicable, but it'll be a challenge regardless.
Cairo is another option, but since it doesn't support pseudo-color
displays and has some serious problems on older X servers, I don't
think it is a good fit (yet).
What other things are you thinking about?
> 2. wrap up FLTK1 and concentrate on FLTK2:
>
> This would mean the end of the FLTK1 branch, leaving it in a very stable
> condition, a great tool for those not needing international text.
Well, not needing CJKV or Arabic support, at any rate.
> All
> developers could put their efforts into bringing FLTK2 to where FLTK1
> already is, gaining the additional features that FLTK2 already has, like
> better structure and internationalization. Will FLTK1 developers change
> over to FLTK2? Are the compatibility headers powerful enough for a
> simple switch?
Unfortunately, I haven't found them to be so thanks to changes to the
Fl_Browser implementation (0-based in FLTK 2, 1-based in FLTK 1) and
the fact that you have to port custom widgets (pretty much all of my
GUI code uses custom widgets...)
> 3. wrap up FLTK1 and FLTK2, and start FLTK3:
>
> This would leave FLTK1 and FLTK2 just where it is. Developers are free
> to add simple fixes to FLTK2, but FLTK1 would be final. We would spend
> some time listing all features of 1 and 2, combine them in a sensible
> way, and then merge the source code to generate FLTK 3.0 with all
> features needed for a future GUI library. Compatibility layers for FLTK2
> and FLTK1 would be designed in from the start, so that existing apps can
> be converted without much trouble.
Starting from scratch does have its appeal, however I fear we'd just
end up with another incompatible, incomplete version that never gets
released.
What we really need is a benevolent dictator to force releases and
milestones, like I did for FLTK 1.0 and 1.1. This person also needs
to have some level of experience with autoconf and VC++ and access to
multiple operating systems to do build tests.
I haven't had the time to take on this role for 2.0, and to be honest
it doesn't look like I will find the time any time soon.
So, I think before we get too far into discussing new releases, we need
to find a volunteer to be the release manager. All of the release and
test procedures, along with the system requirements, are documented in
our CMP:
http://www.fltk.org/cmp.php
So, if you think you have the time (figure 5-10 hours a week once you
get used to the job), the experience, and the access to the three
required operating systems (Windows, Mac OS X, Linux), please throw your
hat in the ring!
(FWIW, I'll still be available for the administrative side of things
and make sure the web site, SVN repo, mirrors, and snapshots are all
working smoothly...)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
