RE: [fltk.general] Fl_Check_Button - set background color of checkmark [General Use]

50 views
Skip to first unread message

MacArthur, Ian (Leonardo, UK)

unread,
Apr 12, 2017, 4:56:31 AM4/12/17
to fltkg...@googlegroups.com
> I need to change the background of the checkmark for
> a Fl_Check_Button.

> From documentation, I find :
> The selection_color() sets the color of the checkmark.
> Black is default.
> I however need to set the background - which is white as
> default.

> How do I change this color ?

Well, you could try overwriting FL_BACKGROUND_COLOR, but that would affect all widgets - not the desired effect, I imagine!

I haven't tried it, but for a checkbox, is the background not set by the color(); method?

I might have to try that, actually... Not at all sure!




Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

holm.h...@gmail.com

unread,
Apr 12, 2017, 7:26:23 AM4/12/17
to fltk.general, ian.ma...@leonardocompany.com

Hi again,

You are right, color() will set the background for most of the widget, but not for the white area where the check mark is located. That remains white whatsoever for  me.

I want to dim (make the screen darker) and then it looks a bit odd to have these white checkboxes around..

Best regards
Håvard

imm

unread,
Apr 12, 2017, 8:48:22 AM4/12/17
to general fltk

   

OK... This is a bit odd; I already posted a follow-up messages about this, but it does not appear to have turned up yet!
(I wonder if this will get through either?)

Anyway, in case the prior message really is lost to us, here's what it said...


(lost message)


> Well, you could try overwriting FL_BACKGROUND_COLOR, but that would
> affect all widgets - not the desired effect, I imagine!
>
> I haven't tried it, but for a checkbox, is the background not set by
> the color(); method?
>
> I might have to try that, actually... Not at all sure!

OK, tried that.

It is not set by color(); instead, it is hard-coded to FL_BACKGROUND2_COLOR, which is usually white (though is set during a win->show(argc, argv); call to match the system settings where possible.)

Now, doing something like:

     Fl::set_color(FL_BACKGROUND2_COLOR, 0, 250, 0);

will work, though will have side-effects, since other widgets may also be using FL_BACKGROUND2_COLOR...

The "easy" fix might be to derive your own check button that only re-implements draw() to just set/restore FL_BACKGROUND2_COLOR on the fly?

viz:


class alt_check : public Fl_Check_Button {
public:
  alt_check(int X, int Y, int W, int H, const char *L) :
     Fl_Check_Button(X,Y,W,H,L) {};
private:
  void draw ()
  {
    Fl_Color old = Fl::get_color(FL_BACKGROUND2_COLOR); // save the default colour
    Fl::set_color(FL_BACKGROUND2_COLOR, 0, 200, 0); // force green background
    Fl_Check_Button::draw(); // do the drawing
    Fl::set_color(FL_BACKGROUND2_COLOR, old); // put the default colour back
  }
};

Which works in a quick hack test...



MacArthur, Ian (Leonardo, UK)

unread,
Apr 12, 2017, 8:57:24 AM4/12/17
to fltkg...@googlegroups.com
> > I need to change the background of the checkmark for a
> > Fl_Check_Button.
>
> > From documentation, I find :
> > The selection_color() sets the color of the checkmark.
> > Black is default.
> > I however need to set the background - which is white as default.
>
> > How do I change this color ?
>
> Well, you could try overwriting FL_BACKGROUND_COLOR, but that would
> affect all widgets - not the desired effect, I imagine!
>
> I haven't tried it, but for a checkbox, is the background not set by
> the color(); method?
>
> I might have to try that, actually... Not at all sure!

OK, tried that.

It is not set by color(); instead, it is hard-coded to FL_BACKGROUND2_COLOR, which is usually white (though is set during a win->show(argc, argv); call to match the system settings where possible.)

Now, doing something like:

Fl::set_color(FL_BACKGROUND2_COLOR, 0, 250, 0);

will work, though will have side-effects, since other widgets may also be using FL_BACKGROUND2_COLOR...

The "easy" fix might be to derive your own check button that only re-implements draw() to just set/restore FL_BACKGROUND2_COLOR on the fly?

viz:


class alt_check : public Fl_Check_Button
{
public:
alt_check(int X, int Y, int W, int H, const char *L) :
Fl_Check_Button(X,Y,W,H,L) {};
private:
void draw ()
{
Fl_Color old = Fl::get_color(FL_BACKGROUND2_COLOR); // save the default colour
Fl::set_color(FL_BACKGROUND2_COLOR, 0, 200, 0); // force green background
Fl_Check_Button::draw(); // do the drawing
Fl::set_color(FL_BACKGROUND2_COLOR, old); // put the default colour back
}
};

Which works in a quick hack test...









holm.h...@gmail.com

unread,
Apr 12, 2017, 1:42:33 PM4/12/17
to fltk.general, ian.ma...@leonardocompany.com

Thank you again Ian !

I used the command

    Fl::set_color(FL_BACKGROUND2_COLOR, 0, 250, 0);
That solved my problem.

Same approach to dim the screen - works like a charm !

Very satisfied with FLTK !

Håvard

MacArthur, Ian (Leonardo, UK)

unread,
Apr 13, 2017, 5:07:00 AM4/13/17
to fltkg...@googlegroups.com

> I used the command
>    Fl::set_color(FL_BACKGROUND2_COLOR, 0, 250, 0);
> That solved my problem.
>
> Same approach to dim the screen - works like a charm !
>
> Very satisfied with FLTK !


Revised version of Greg's "dim the palette" scheme attached, now with a slider to control the "brightness setting".

Seems to work pretty well, actually.
Though any images or etc. you have drawn would likely need to be "adjusted" to match, as they will not be drawn using the default palette values...

It may be possible the alpha-blend a gray level with the entire window, of course; I wonder if that might be more flexible in the general case (though more complex to set up initially.)
dimmable-window.cxx

MacArthur, Ian (Leonardo, UK)

unread,
Apr 13, 2017, 11:38:54 AM4/13/17
to fltkg...@googlegroups.com
Well, I had thought that doing an "dimmable overlay" would be harder than "dimming" the basic palette, but it turns out it's not actually so hard after all, and doesn't seem to be too much of a resource hog either (at least, not on this machine.) YMMV.
"Dimming" the entire window area like this ought to mean that "everything" is adjusted, not just the things drawn using the basic palette. Probably...

Attached, yet another "dimmable GUI" test, this time with colour selection too.
dimmable-overlay.cxx

MacArthur, Ian (Leonardo, UK)

unread,
Apr 13, 2017, 11:51:36 AM4/13/17
to fltkg...@googlegroups.com
> Well, I had thought that doing an "dimmable overlay" would be harder
> than "dimming" the basic palette, but it turns out it's not actually so
> hard after all, and doesn't seem to be too much of a resource hog
> either (at least, not on this machine.) YMMV.
> "Dimming" the entire window area like this ought to mean that
> "everything" is adjusted, not just the things drawn using the basic
> palette. Probably...
>
> Attached, yet another "dimmable GUI" test, this time with colour
> selection too.

Aargh! Typo at line 51.
I was testing the memory usage, and commented out the delete of the intermediate RGB image.
I forgot to remove the comment markings, so the code as originally posted will leak RGB images and use up the memory.

Please restore the line saying "delete win_img;" at line 51 before use...

(Attached file is corrected.)
dimmable-overlay.cxx

Ian MacArthur

unread,
Apr 13, 2017, 6:53:13 PM4/13/17
to fltk.general, ian.ma...@leonardocompany.com


On Thursday, 13 April 2017 16:51:36 UTC+1, MacArthur, Ian  wrote:
> Well, I had thought that doing an "dimmable overlay" would be harder
> than "dimming" the basic palette, but it turns out it's not actually so
> hard after all, and doesn't seem to be too much of a resource hog
> either (at least, not on this machine.) YMMV.
> "Dimming" the entire window area like this ought to mean that
> "everything" is adjusted, not just the things drawn using the basic
> palette. Probably...
>
> Attached, yet another "dimmable GUI" test, this time with colour
> selection too.


Hmm, interesting observation: the dimmable-overlay demo works on Win7 and X11, but not on OSX...

Something with the Fl_Image_Surface perhaps? 

Or maybe it's just something not working right with win_img->color_average(...) ?

No Idea!



Reply all
Reply to author
Forward
0 new messages