On 28.03.2008, at 16:20, Albrecht Schlosser wrote: > matthiasm wrote: >> * verification of 1.2 STRs and possible push up to 1.3: there are 58 >> STRs associated with FLTK 1.2. Most of these are probably fixed by >> now, >> but we will have to read through each of them and apply them to 1.3 >> if >> needed. > > How can we help? AFAICS there are some STR's that seem to target > similar > problems (e.g. more than one STR about fl_ask and friends: 1873, 1626, > 334, 275). Should we wait until one of those who have the access > rights > will move the STRs, or maybe add new STRs for 1.3, with references to > the old STRs?
We must categorize them into 1: fixed already in 1.1.8 2: does not apply to 1.3, only to a feature in 1.2 that won't be ported 3: must be fixed in 1.3 If you have the time to do this and send me a list with short comments, then I will apply the changes to the STRs accordingly. >> * better typing: we can finally break the binary interface, so we >> will >> change some types in FLTK 1.3. Widget coordinates will be 32 bit, for >> example. At this time, we will also weed out some other limitations >> that >> could not be fixed due to ABI issues. > > Also API changes? E.g. change Fl_Scroll::position() to another name so > that it doesn't overload Fl_Widget::position()? And maybe others? > Should we file STRs for such API issues? Absolutely yes, and yes, unless there is already a 1.2 STR. >> A few words on stability: >> >> Please don't ask us to push tons of tiny features into the new >> FLTK. We >> will have toime for that later. 1.3 will contain the most desperatly >> needed features in what is hopefully going to be a very short time >> and >> without ever losing the focus on stability. As soon as the features >> above are tested and OK'd, we will move on to 1.4 quickly. 1.4 >> focus on >> reorganisation of the source tree and the demo application. A >> stable 1.4 >> will then be the base for a systematically approach to integrating >> more >> excotic features without losing the F or L in FL ;-) . > > I appreciate this very much. Making more small steps will be much > better > than one big step that takes 2 years. :-P and hopefully much less frustration. >> A few words on versioning: >> >> FLTK has a quite convoluted version numbering. FLTK 1.3 follows FLTK >> 1.1. FLTK 1.2 is retired, but some of its features will flow into >> 1.3. >> FLTK 2 uses a quite different API and is not touched in this whole >> discussion. Both version will remain incompatible for quite a while, >> until a merge of APIs and code base may become feasible. > > This point is very important for me. I will be able to test and use > 1.3 > as long as it doesn't change its API (too much) so that I can follow > the > development without major source modifications. I'm not sure if this > will be possible with utf-8, however. The API will change wherever it is required for technical reasons (double naming, like you mentioned for Fl_Scroll, make a method virtual, or going from private to protected). I don't plan to do cosmetic API changes. As for UTF-8, if you never used more than ASCII, UTF-8 will look exactly ASCII to you. As for a few Umlauts, unless you added specific code for umlaut handling, all you have to do is to import your source code using the Western code page into a UTF-8 capable editor and save it as UTF-8 code again. Matthias ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
