Duncan Gibson wrote: > Was: Re: Will FLTK use more C++ features? > http://www.fltk.org/newsgroups.php?gfltk.development+v:8978 > >>> I think fltk internals *could* benefit from plain old >>> non-controversial c++ features like classes and virtual methods, > >> Two big points that I would like to address in the near future: >> ... > > I think that it's absolutely brilliant that there is a sudden surge > in FLTK-1.3.x development, with updates for Mac, printing, etc, BUT... > > aren't we losing sight of trying to solve/close the Roadmap STRs so > that we can make a proper stable release of FLTK-1.3.0 ?
Duncan, yes, there is maybe a danger that there is more work done for non-critical things. My personal opinion is: We should not add many new features to fltk 1.3, as discussed before, and the main goal should be to push the UTF-8 related changes to get a release of FLTK 1.3 that is mostly API compatible with FLTK 1.1. Unfortunately I don't know much about UTF-8, font rendering and such, so that I decided not to try to do anything UTF-8 related, but to do other things like ABI cleanup. I didn't even finish this, there's still a lot to do. One of this is to look for more virtual methods since this would change the ABI. And because the "UTF-8 people" don't seem to have much time now, I think that it is useful to do some other work meanwhile. Manolo's printing support is IMHO a very good feature, doesn't do much harm to the FLTK core (in fact, I don't think that it does _any_ harm), and this is done with "free" developer capacities. So why not do it? And, BTW, it's not yet decided to integrate it (or *when*), since a main point (Linux/Unix/X11) compatibility is still missing. But I'm confident that we can find a solution, or that we can also do it w/o Linux support. Currently this is all done in a development branch, but could be integrated in the main branch with a simple merge. And, while we're at it: IIRC there were some ideas how to integrate printing support, but nothing concrete that I remember. Does anybody know if we are on the right way, or have there been any conflicting or completely different ideas how to do it? I wouldn't like to invest too much time in a development that won't be integrated in the main FLTK development. [Duncan, I apologize for "hijacking" your thread] Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
