Concerning r6628 fix: Mike is right about the font stack, Al you're also right I think on the 1.1 modification not changing the ABI.
Still, I feel I have something to point out clearly, for the new year : We should *definitely stop* updating modifications to 1.1.x because 1) FLTK 1.3 is not an 'attempt' but the real next version of fltk otherwise we're loosing our time, so it's worth our full time. 2) Maintaining more FLTK 1.1 (except if a critical new bug arise) is *slowing down* the 1.3 process and motivation. We all seem to have very few time currently, and like all others in the team (I hope) ; I can proudly say I have spent more than 80% of my spare time on FLTK 1.3. But still, I feel I don't have enough time, or not as much as I would like to have for our favorite toolkit. So I guess that my conclusion is : let's focus on 1.3 now please ! I would vote for stopping updating non abi breaking fixes on 1.1 and focus on a 1.3 RC ... Fabien > Michael Sweet wrote: > > Probably better to add the current color to the font stack. > > > > [email protected] wrote: > >> Author: fabien > >> Date: 2009-01-12 09:14:52 -0800 (Mon, 12 Jan 2009) > >> New Revision: 6628 > >> Log: > >> STR#890 fix attempt: correct imbricATED font color handling. > > Fabien, > > I don't see that _this_ fix (r 6628, that has been removed later from the 1.1 > branch) would break binary compatibility, as Mike noted in STR #890 on May 27, > 2005. If it can improve the behavior for FLTK 1.1, then I suggest that this > should be used for FLTK 1.1. > > However, adding the color to the font stack, as Mike suggests, would break > binary > compatibility, and I think that this was the reason why it couldn't be > applied to > 1.1. > > How about adding your solution (r 6628) to FLTK 1.1 as a minimal fix, and > adding > the color to the font stack, as Mike suggests? > > Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
