On 15.04.2012 12:26, Edzard Egberts wrote:
> 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.
Yup, that's much better.
> 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).
okay.
> 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.
Probably only if all widgets are (and should be) resized in the same
way.
>> 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.
It is a problem. My sentence above was *meant* to be read together with
the next (two) sentence(s):
>> 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)
No, not really. Of course it would be better to activate such a feature
explicitly (instead of having to deactivate it), but you're missing the
point. What I wanted to say is that you can have some widgets that do
resize, and others that don't. The former would auto-resize their
fonts, the latter wouldn't. So, in the example where you want to
/zoom/, you'd have some widgets that still have smaller fonts.
As others (maybe Domingo) have noted, there *is* a difference between
FLTK's resizing (depending on resizable()s) and zooming an entire
application.
>> (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.
The label (struct Fl_Label) is part of Fl_Widget, hence the ABI would
change anyway.
> 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(); }
Correct. I think that we could change this, even w/o breaking the
ABI (because and/or although this is an inline method.
> And the h0 thing inside of label_.size().
Yup (but would break ABI).
> This would break code, but I also think, this would improve code.
I don't think that this would break code (i.e. change any API or
semantics), since the Fl_Label struct is private in Fl_Widget, and
the methods can be changed. But I didn't check that really.
> The next problem is textsize, because the textattributes are not methods
> of Fl_Widget.
Yes, I can see this...
> 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(); }
The former. The latter would mean that you can't have different text
and label sizes, which would definitely be wrong.
> I don't think, this would external break code, but would affekt several
> FLTK classes.
Probably okay for the API, but not for the ABI. We'd need to add new
members (at least one) to Fl_Widget. Adding the textsize() method to
Fl_Widget wouldn't harm, though.
> 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.
But only in a "relative" way, as widgets resize...
>> (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?
This question is rhetorical, isn't it? And the answer is yes.
However, since the next step forward should be to FLTK 3, we should
probably not add new API's (methods) to FLTK 1.3 that become obsolete
if (when) we use the "Style" approach in the next version.
>> (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.
It's fine to use templates for application code, but FLTK's CMP [1]
says that templates "may be not used in FLTK 1.1.x code", and the same
applies to FLTK 2.0.x code. [Well, this should probably read "must not
be used" (native English speakers, please ?).] However, there is no
official statement for FLTK 1.3, 3.0 or later (yet), but I believe
that the decision still stands.
Please don't understand me wrong: my point is not that your proposal
and your solution are bad, but they are not a general solution for
the scaling (zooming) problem. My own main application uses an own
approach of zooming and auto-resizing fonts (so I do know what we
are talking about), but I wanted to point out the problems that
need to be solved, and also the backwards compatibility we need
to keep. I also believe that such auto-resizing of fonts could be
added to FLTK - the question is, however, which way? Will there be
FLTK 1.4, or will we move to FLTK 3 with styles and such soon???
We'd need one or the other to add ABI-breaking changes (unless we
use the "version-dependent ABI changes feature", but I personally
believe that this change would be too big to do it this way).
Albrecht
[1] http://www.fltk.org/cmp.php
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
