On 14.04.2012 14:22, Edzard Egberts wrote:
> Edzard Egberts schrieb:
>>
>> Harhar - I just went through the examples...
>
> and I wondered, why some texts are wrong sized. It's because there is no
> redefinition of starting values l0 and t0. So this approach is too basic.
>
> To make a version, that would work fine for existing code, it would be
> necessary to move textsize_ to Fl_Widget and to make Fl_Label use the
> labelsize() method. After that all methods can be changed like that:
>
> Fl_Fontsize textsize() const { return h0 ? (l0 * h())/h0 : l0; }
> void textsize(Fl_Fontsize s) { h0 ? l0= (s * h0)/h() : l0= s; }
>
> So the origin values will be kept and it is only possible to save h0.
>
> My original approach works better, because the template comes top down
> and overwrites methods, but the Fl_Widget is at bottom and existing code
> overwrites changes.Unfortunately your proposed changes would break *my* code that does its own resizing of font sizes as required by my application. In fact, I believe that it would break anybody's applications if you change font sizes after the initialization of widgets. As you can see above, even if I'd set h0 to 0, then your modified textsize() method (above) would always return l0 (the initial size) and not the font size that has been set later. Maybe this could be "fixed" by setting l0 (or some other variables) in labelsize(int), but there can be lots of different problems. One example is that I use different labelsize() and textsize() values for some widgets. Another problem: we can have resizable widgets and non-resizable widgets in windows/groups. If we changed the font sizes by resizing in general, then non-resizable widgets would keep their font sizes, and this would lead to different font sizes in one window. This could be annoying. There is probably no general best solution. :-( > Okay, I think that shows the basic requirements. Should I finish the > basic system, adding data to Fl_Widget, should I try my pointer version, > or go on with templates - what do you think? Hmm, that's difficult to answer. (1) Adding data to Fl_Widget would change the ABI, and we probably wouldn't do this, because this would only become generally usable in a new FLTK version (1.4 or 3.0), but ... see (2). (2) The "pointer version" looks like the "Style" approach we had in FLTK 2 and that *is* already in FLTK 3 [1], so this would be the way to go anyway. Probably. (3) Templates - we don't use templates in FLTK, and I don't think that we will in the near future. My conclusion: I think that we could /maybe/ add an auto-resizing feature based on the Style approach in FLTK 3 and later, but probably not in FLTK 1.3. But I could also be wrong... Albrecht [1] in FLTK 3: include/fltk3/Style.h etc. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
