Albrecht Schlosser schrieb:
> On 14.04.2012 14:22, Edzard Egberts wrote:
>> 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.
>
> 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.
Sorry, I mixed up "minimum example code" and final solution. I want to
restart by explaining, how it should work and then, why it doesn't work
and what changes would be needed:
Fl_Fontsize labelsize() const
{ return h0 ? (label_.size * h())/h0 : label_.size; }
void labelsize(Fl_Fontsize s)
{ h0 ? label_.size= (s * h0)/h() : label_.size= s; }
This is almost original code, just the h0-thing was added.
When h0 is equal to zero, just original code works, when it real
starting height of the window, it will cause labelsize() to follow hight
of the window (better would be to respect ratio, but it doesn't really
matter).
I know this working (using another approach, see my template example)
and it's fine - when there is a high resolution monitor, you just need
to resize the window, save size and the whole software is adjusted to
the current resolution.
> Another problem: we can have resizable widgets and non-resizable widgets
> in windows/groups
This is no problem, because scaling of fonts depends on current widgets
size, so there is no scaling, when there is no resizing. And also if you
change local fontsizes they will keep their ratio to current window resize.
> 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.
This is the "h0= 0" case - "must be deactivated, if unwanted". Okay,
better solution would be - "must be activated, if wanted". ;o)
> (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).
What's about a private pointer? Or a private pointer inside of Fl_Label?
It could keep e.g. h0, so there is no other change to data of Fl_Widget.
But there are other problems, now the "changes would be needed" part:
The Widget provides method labelsize(), but the label doesn't use it
itself. Method is:
Fl_Fontsize labelsize() const { return label_.size; }
Method should be:
Fl_Fontsize labelsize() const { return label_.size(); }
And the h0 thing inside of label_.size().
This would break code, but I also think, this would improve code.
The next problem is textsize, because the textattributes are not methods
of Fl_Widget.
E.g. Fl_Input implements
Fl_Font textfont_;
Fl_Fontsize textsize_;
And provides methods:
Fl_Fontsize textsize() const {return textsize_;}
void textsize(Fl_Fontsize s) {textsize_ = s;}
This is reimplemented e.g. for Fl_Browser_.
I think, the textsizes should either be moved to Fl_Widget, or use
something like
Fl_Fontsize textsize() const { return label_.textsize(); }
I don't think, this would external break code, but would affekt several
FLTK classes.
Anyway, I hope now it is plain to see, where the problems are, how to
solve them and what it would achieve - rescaling of fonts on the fly,
changing fontsize on the fly.
> (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.
I think none of them is ready for productive use?
> (3) Templates - we don't use templates in FLTK, and I don't think
> that we will in the near future.
I use templates and they are a perfect way to attach subsystems to
existing classes. Also very easy to use.
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
