On 5/7/24 18:00 Daniel Harding wrote:

On Tuesday, May 7, 2024 at 9:53:34 AM UTC-5 Albrecht-S wrote:

> Unfortunately it's not possible to select adequately contrasting colors
> by the program developer. Users of the program can run them on a variety
> of systems and use a variety of system "themes" (KDE, Gnome, other DE's)
> and FLTK always tries to honor the system "theme", i.e. the background
> and selection colors.

Interesting. I see your point. I suppose I don't consider this very much
because from my selfish point of view, my application only runs in 1 of 12
"fully built" themes that don't rely at all on any system defaults (AFAIK).

One of the main points is whether you call Fl_Window::show(argc, argv)
or use the one w/o arguments. The former reads system color schemes
etc., as well as if you call Fl::get_system_colors() which should be
obvious. If you don't call either, then FLTK is -  AFAICT - always in
its "default state" after startup.

It makes me wonder if FLTK is aware of whether any "system defaults" are
still "in play" or not. If FLTK is capable of being aware of this, then
perhaps it could be more "hands off" and not meddle with theming as much
when there are no more "unpredictable" system defaults. (ie, only
compensate for poor contrast whenever a system default is the culprit.)

That's very likely not going to happen, for certain reasons...

Of course, if FLTK is not already capable of making this distinction, then
this is only a hypothetical suggestion; not a very serious one.

OK.

But I do think there is value in letting the user developer have the option
to take the responsibility of ensuring the theme has adequate contrast, and
in return FLTK will not tamper with it so much (except, for example, in the
"obvious" cases like simply making sure foreground text contrasts with the
background which is virtually always desirable).

Now we're back to the point where I need to say that this (as you
describe) is the intention of using fl_contrast() anywhere. The example
we talked about seems to be a bug and not the intended behavior. I think
we agree and we should be patient to see what we can find out before we
talk about hypothetical issues. ;-)

But anyway, all comments are appreciated, thank you.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/a1c43a6b-149b-4e02-8041-c493f62e2ac4%40aljus.de.