FLTK logo

Re: [fltk.coredev] RFC: Fl:: methods for setting default font/color/etc

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: RFC: Fl:: methods for setting default font/color/etc Albrecht Schlosser Oct 16, 2022  
 
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?

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/5a00223c-00db-f878-ac45-296af4170158%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.