RFC: Fl:: methods for setting default font/color/etc

[Greg Ercolano]

This came up on fltk.general:

On 10/16/22 10:01, lifeatt...@gmail.com wrote:

I have searched for a while for this but haven't come up with an answer. (I'm guessing it's obvious).

Fltk has defaults for eg. Colour, Font Size etc and I would like to set my own so I don't have to code them on each individual widget. Can someone tell me how to do this.

Thank you for asking this question. I don't feel it was "obvious" : I've been using FLTK for some time now, could have used the answer, and didn't know it!

    Perhaps some well named wrapper methods could make this
    easier to find/more intuitive, as I think few would expect UPPER_CASE
    values to be settable globals. We can hide these historical warts
    by adding improved methods, like:
   
        Fl_Fontsize Fl::default_fontsize() const          { return FL_NORMAL_SIZE; }
        void        Fl::default_fontsize(Fl_Fontsize val) { FL_NORMAL_SIZE = val; }

        Fl_Color    Fl::default_background_color() const       { return FL_BACKGROUND_COLOR; }
        void        Fl::default_background_color(Fl_Color val) { FL_BACKGROUND_COLOR = val; }

    ..etc..

    Perhaps we can also pivot away from setting FL_HELVETICA to change
    "the default font" (because that's a really bad way to do it)
    by creating a NEW variable FL_DEFAULT_FONT:

Fl_Font FL_DEFAULT_FONT = -1;  // default uses FL_HELVETICA

    ..and then in the Fl_Widget ctor, make this change:

Fl_Widget::Fl_Widget(int X, int Y, int W, int H, const char* L) {
   [..]
   label_.value   = L;
   label_.image   = 0;
   label_.deimage = 0;
   label_.type    = FL_NORMAL_LABEL;
-  label_.font    = FL_HELVETICA;
+  label_.font    = (FL_DEFAULT_FONT != -1) ? FL_DEFAULT_FONT : FL_HELVETICA;
   label_.size    = FL_NORMAL_SIZE;

    This way old apps that set FL_HELVETICA would work as it does now,
    but if the app uses "the new way" by setting Fl::default_font(),
    a new wrapper around FL_DEFAULT_FONT, then it would take precedence.

    Anyway, things like this could clean up some bad API warts
    and make it easier for new users to search the docs for how to change
    the defaults.

[Albrecht Schlosser]

On 10/16/22 19:49 Greg Ercolano wrote:

This came up on fltk.general:

On 10/16/22 10:01, lifeatt...@gmail.com wrote:

I have searched for a while for this but haven't come up with an answer. (I'm guessing it's obvious).

Fltk has defaults for eg. Colour, Font Size etc and I would like to set my own so I don't have to code them on each individual widget. Can someone tell me how to do this.

Thank you for asking this question. I don't feel it was "obvious" : I've been using FLTK for some time now, could have used the answer, and didn't know it!

    Perhaps some well named wrapper methods could make this
    easier to find/more intuitive, as I think few would expect UPPER_CASE
    values to be settable globals. We can hide these historical warts
    by adding improved methods, like:
   
        Fl_Fontsize Fl::default_fontsize() const          { return FL_NORMAL_SIZE; }
        void        Fl::default_fontsize(Fl_Fontsize val) { FL_NORMAL_SIZE = val; }

Looks good, +1

        Fl_Color    Fl::default_background_color() const       { return FL_BACKGROUND_COLOR; }
        void        Fl::default_background_color(Fl_Color val) { FL_BACKGROUND_COLOR = val; }

Same here, +1

    ..etc..

What else ?

    Perhaps we can also pivot away from setting FL_HELVETICA to change
    "the default font" (because that's a really bad way to do it)
    by creating a NEW variable FL_DEFAULT_FONT:

Fl_Font FL_DEFAULT_FONT = -1;  // default uses FL_HELVETICA

    ..and then in the Fl_Widget ctor, make this change:

Fl_Widget::Fl_Widget(int X, int Y, int W, int H, const char* L) {
   [..]
   label_.value   = L;
   label_.image   = 0;
   label_.deimage = 0;
   label_.type    = FL_NORMAL_LABEL;
-  label_.font    = FL_HELVETICA;
+  label_.font    = (FL_DEFAULT_FONT != -1) ? FL_DEFAULT_FONT : FL_HELVETICA;
   label_.size    = FL_NORMAL_SIZE;

    This way old apps that set FL_HELVETICA would work as it does now,
    but if the app uses "the new way" by setting Fl::default_font(),
    a new wrapper around FL_DEFAULT_FONT, then it would take precedence.

Good idea, but I don't think it would work well as proposed, for at least two reasons:

1. Most of our fonts are used in 4 variants, hence 'FL_DEFAULT_FONT + n'  *and*  'FL_DEFAULT_FONT | N' for N in {0, 1, 2, 3} should be valid font numbers as well.

2. Changing the constructor alone would not be sufficient. Users would want to assign fonts during runtime for whatever reasons.

A possible solution would be to assign four new font numbers FL_DEFAULT_FONT, FL_DEFAULT_FONT+1, FL_DEFAULT_FONT+2, and FL_DEFAULT_FONT+3 that get the same font variants as FL_HELVETICA assigned (normal, bold, italics, bold italics) in the correct order.

Then we could use FL_DEFAULT_FONT instead of FL_HELVETICA in all widgets, or something like that. However, users using FL_HELVETICA to assign another font would be surprised that it doesn't affect the font of their widgets.

That said, my idea doesn't look promising as well, but maybe we can think about it, combine the ideas, and find something better?

    Anyway, things like this could clean up some bad API warts
    and make it easier for new users to search the docs for how to change
    the defaults.

Yes, I like the idea, but it must work and be backwards-compatible.

What if we use another method like you proposed above for setting the fonts, like

  Fl::default_font(N, "valid-font-name");

and assign this to the 'FL_HELVETICA+N' slot? Index N would be 0-3 to set the normal, bold, italics, and bold-italics variants ...

That said, there's also a default monospaced font (FL_COURIER) which should also be considered.

Just thinking aloud. I don't have a real proposal yet. Anybody else?

[imacarthur]

I like the idea in principle, but as Albrecht notes it maybe opens a whole can of worms... it may not be trivial to make this work "transparently".

And... I have nothing actually constructive to add here. Sorry.