Change default colors and Fl::get_system_colors()

[Alvin Beach]

Hello,

When I try to change the default value for FL_SELECTION_COLOR, it will only stick if I set it after showing the window.

Initially, I tried calling Fl::set_color(FL_SELECTION_COLOR, 200, 0, 0) after having called Fl::get_system_colors(). However, whilst debugging, I found that Fl_Window::show(int argc, char **argv) also calls Fl::get_system_colors(). This resets the FL_SELECTION_COLOR value back to the default.

Normally, get_system_colors() works fine. However, on one of my systems (Ubuntu 15.10, Unity), it does not get the right colour value for selection.

I use FLUID to generate the GUI. As a result, FLUID emits the code:

wnd->show(argc, argv);
return Fl::run();

I cannot seem to find a way/trick to inject code after the wnd->show() and the return.

My current workaround is to edit the .cxx file manually. However, my change is lost when I regenerate the .cxx file via FLUID.

I don't believe this happens with FL_BACKGROUND_COLOR since Fl::get_system_colors() sets a flag once it is set which prevents a reset.

I am using FLTK SVN r10779.

Any advice would be great.

Thanks,

Alvin

[Hannu Vuolasaho]

I did something similar and wondered that selection_color() part also.

Hope this helps: https://groups.google.com/forum/#!topic/fltkgeneral/92CQ1y3Kwmg

And Fluid can be PITA when working with extracted widget. I wrote
public customInit() which overrides Fluid settings like background
color and other stuff which I don't care to micromanager.
It is also inherited from my base class.

Best regards,
Hannu Vuolasaho

> --
> You received this message because you are subscribed to the Google Groups
> "fltk.general" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fltkgeneral...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Greg Ercolano]

On 07/01/15 06:32, Alvin Beach wrote:
> Hello,
>
> When I try to change the default value for FL_SELECTION_COLOR,
> it will only stick if I set it after showing the window.

Yes, I think this is because calling wnd->show(argc,argv)
expects to parse the command line for options that can
affect color maps, and it also has the side effect of
initializing the colormap.

IIRC, this is NOT the case if you just call show(void).

So either:

a) use show(void) instead, and don't call show(argc,argv)..
then you can setup your map before calling show(void).

b) if you want to use show(argc,argv), then set up your map
AFTER that call.

> I cannot seem to find a way/trick to inject code after the wnd->show() and the return.

Write your own main() in fluid instead of using Fluid "blank as main" approach.

Just declare a function in fluid as you would any other, make the function name
"main" with the two argc/argv arguments, then add a Code block to it, and write
whatever code you want, including the call to win->show() and at the end,
call return Fl::run();

> My current workaround is to edit the .cxx file manually.

A do it yourself approach (besides the above) would be to make your own
main.cpp + main.h files in a text editor, and put your custom code in there,
referring to the fluid objects/functions as a separate module, where you
#include the fluid-generated .h file, and link in the compiled fluid generated
.cpp file. (Or I suppose you could cheat and try to #include the .cpp file
in your main() code if you don't want to deal with linking .o/.obj files)

> However, my change is lost when I regenerate the .cxx file via FLUID.

Yes, avoid ever editing the .cxx/.h files fluid generates
if you want to continue using fluid to manage the files.

Use #include approach as a workaround, or do the suggestion higher
up in this post where you can do the whole thing /within/ fluid
using a custom main(), instead of the automatically generated one.

Fluid can be used in several ways:

a) to manage an entire small app
b) manage only the GUI parts of your app,
and treat the fluid generated code as a separate module (.h / .obj)

You can also use fluid to manage just certain classes, so that you
can mix in hand-written fltk code in a text editor with fluid
managed classes, one fluid file per class.

[Albrecht Schlosser]

On 01.07.2015 15:32 Alvin Beach wrote:

> When I try to change the default value for FL_SELECTION_COLOR, it will
> only stick if I set it after showing the window.

As noted later in this thread, this is only true if you call
show(argc,argv), because FLTK loads system colors in this case.

> Initially, I tried calling Fl::set_color(FL_SELECTION_COLOR, 200, 0, 0)
> after having called Fl::get_system_colors(). However, whilst debugging,
> I found that Fl_Window::show(int argc, char **argv) also calls
> Fl::get_system_colors(). This resets the FL_SELECTION_COLOR value back
> to the default.
>
> Normally, get_system_colors() works fine. However, on one of my systems
> (Ubuntu 15.10, Unity), it does not get the right colour value for selection.

I observed recently that there seems to be kinda patchwork in this area
of calling show(argc,argv) and Fl::get_system_colors(). Right now I
can't tell what the right behavior should be, so this is not going to be
changed now (in fltk 1.3.x).

I have this on my todo list for the next minor release (i.e. 1.4.0), so
this is likely to change in the future - but maybe not.

> I use FLUID to generate the GUI. As a result, FLUID emits the code:

I'm not going to comment on fluid usage, others have given some valuable
hints already (see for instance Greg's post).

[Alvin Beach]

On 01/07/15 21:41, Greg Ercolano wrote:
>> I cannot seem to find a way/trick to inject code after the wnd->show() and the return.
> Write your own main() in fluid instead of using Fluid "blank as main" approach.
>
> Just declare a function in fluid as you would any other, make the function name
> "main" with the two argc/argv arguments, then add a Code block to it, and write
> whatever code you want, including the call to win->show() and at the end,
> call return Fl::run();
>

Oh yes, of course! I had forgotten about this. I've create main() this way before too in FLUID. This will definately do the trick. Thanks.

Cheers,

Alvin