Invisible selection color
43 views
Skip to first unread message
Miguel J
Jan 6, 2026, 6:27:13 AMJan 6
to fltk.general
Hello,
I am using FLTK on Linux (Ubuntu 24.04.3 LTS, with Linux 6.8.0, amd64).
My Ubuntu flavor is MATE (Gnome 2), with a light theme (Yaru).
I have the same problem with FLTK 1.3.8 (provided with Ubuntu) and with FLTK 1.4.4 (compiled using CMake).
The problem is that the selected texts cannot be seen, because the "selection color" is the same (very light grey: RGB=250,250,250) as the "background color" and the "background color 2".
This problem happens in Fluid, and in any program which I write.
It also happens in the test program (e.g.: bin/test/input).
However, it does not happen in the example program (e.g.: bin/examples/texteditor-simple), where the selected texts appear in dark blue (RGB=0,0,128).
Needless to say that this problem does not happen in any other program on my system. For example:
- "pluma" (text editor in MATE): blue/cyan (RGB=0,115,229)
- Thunderbird light blue/cyan in active window (RGB=51,153,225), grey in inactive window (RGB=176,176,176), while the background is white (RGB=255,255,255)
Although I see that Fluid allows me to change the selection color for any widget, I do not understand why this problem happens in the first place, and how to solve it in Fluid itself (editing the callback code is very unconvenient when you cannot see the selection) and in the test programs.
Do you have any clue?
Miguel
I am using FLTK on Linux (Ubuntu 24.04.3 LTS, with Linux 6.8.0, amd64).
My Ubuntu flavor is MATE (Gnome 2), with a light theme (Yaru).
I have the same problem with FLTK 1.3.8 (provided with Ubuntu) and with FLTK 1.4.4 (compiled using CMake).
The problem is that the selected texts cannot be seen, because the "selection color" is the same (very light grey: RGB=250,250,250) as the "background color" and the "background color 2".
This problem happens in Fluid, and in any program which I write.
It also happens in the test program (e.g.: bin/test/input).
However, it does not happen in the example program (e.g.: bin/examples/texteditor-simple), where the selected texts appear in dark blue (RGB=0,0,128).
Needless to say that this problem does not happen in any other program on my system. For example:
- "pluma" (text editor in MATE): blue/cyan (RGB=0,115,229)
- Thunderbird light blue/cyan in active window (RGB=51,153,225), grey in inactive window (RGB=176,176,176), while the background is white (RGB=255,255,255)
Although I see that Fluid allows me to change the selection color for any widget, I do not understand why this problem happens in the first place, and how to solve it in Fluid itself (editing the callback code is very unconvenient when you cannot see the selection) and in the test programs.
Do you have any clue?
Miguel
Matthias Melcher
Jan 6, 2026, 6:35:18 AMJan 6
to fltk.general
It might be related to the light theme. FLTK tries to honor the theme colors of the desktop environment. Why it thinks that a selection color with no contrast is a good idea, I don't know. Are you using X11 or Wayland for the desktop graphics?
At least for Fluid, you can play around with the command line arguments -fg -bg -bg2 and -scheme and see if setting a different background color improves things, for example "fluid -bg #eeeeee`.
If you are up to it, tracing fl_open_display() will eventually lead to the code that queries the OS colors and sets them for FLTK. If we can find the bug, we can fix it for 1.4.5 and 1.5
Albrecht Schlosser
Jan 6, 2026, 8:52:58 AMJan 6
to fltkg...@googlegroups.com
On 1/6/26 12:35 'Matthias Melcher'
wrote:
It might be related to the light theme.
I agree.
FLTK tries to honor the theme colors of the desktop environment. Why it thinks that a selection color with no contrast is a good idea, I don't know.
Neither do I, but I don't think that it's FLTK's fault in the first
place. However, maybe we don't interpret the theme colors
correctly...
I remember that I had a similar problem with a particular "Knoppix" (Linux) system, years ago. The given selection color was a very light blue. My solution (at that time) was to increase the contrast level (which is far easier since FLTK 1.4.0) but this would only help in places where fl_contrast() is correctly called to set the (selection) color in contrast with the background color. The negative (side) effect would be that the selection color would be either black or white depending on the background color.
I remember that I had a similar problem with a particular "Knoppix" (Linux) system, years ago. The given selection color was a very light blue. My solution (at that time) was to increase the contrast level (which is far easier since FLTK 1.4.0) but this would only help in places where fl_contrast() is correctly called to set the (selection) color in contrast with the background color. The negative (side) effect would be that the selection color would be either black or white depending on the background color.
Are you using X11 or Wayland for the desktop graphics?
Good question, this might make a difference. The OP wrote that he's
using "MATE (Gnome 2)" which was known not to use Wayland, hence
it's likely X11 based.
(Note also that FLTK 1.3 (which the OP mentioned as well) always uses X11 because Wayland has been introduced in FLTK 1.4). If the OP didn't install Wayland development packages explicitly, it's very likely that FLTK 1.4.4 (self-built) uses X11.
@Miguel: when you're configuring CMake to build FLTK 1.4.4 you should see a configuration summary at the end. You can view it again if you
$ cd /path/to/fltk/build # adjust this path as needed
$ cmake . # notice the trailing '.'
Near the end of the output you should see a line similar to:
-- Use Wayland Yes (can also run as X11 client)
or
-- Use Wayland No (X11 is used)
Please post what you see, or ...
If you don't know whether a particular program uses X11 or Wayland, there's a simple test: start an FLTK program (or any other program) and then execute `xwininfo` or `xkill` from a terminal. Moving the mouse over the window in question would change the cursor shape as long as it is over the window. You can safely click on the window if you used `xwininfo` (which shows window attributes in the terminal) whereas clicking on the window with `xkill` would terminate that X11 program. If your desktop and the app in question both use Wayland, then the cursor shape doesn't change and clicking on the window does nothing. Obviously this test requires that the necessary tools are installed.
(Note also that FLTK 1.3 (which the OP mentioned as well) always uses X11 because Wayland has been introduced in FLTK 1.4). If the OP didn't install Wayland development packages explicitly, it's very likely that FLTK 1.4.4 (self-built) uses X11.
@Miguel: when you're configuring CMake to build FLTK 1.4.4 you should see a configuration summary at the end. You can view it again if you
$ cd /path/to/fltk/build # adjust this path as needed
$ cmake . # notice the trailing '.'
Near the end of the output you should see a line similar to:
-- Use Wayland Yes (can also run as X11 client)
or
-- Use Wayland No (X11 is used)
Please post what you see, or ...
If you don't know whether a particular program uses X11 or Wayland, there's a simple test: start an FLTK program (or any other program) and then execute `xwininfo` or `xkill` from a terminal. Moving the mouse over the window in question would change the cursor shape as long as it is over the window. You can safely click on the window if you used `xwininfo` (which shows window attributes in the terminal) whereas clicking on the window with `xkill` would terminate that X11 program. If your desktop and the app in question both use Wayland, then the cursor shape doesn't change and clicking on the window does nothing. Obviously this test requires that the necessary tools are installed.
If you are up to it, tracing fl_open_display() will eventually lead to the code that queries the OS colors and sets them for FLTK. If we can find the bug, we can fix it for 1.4.5 and 1.5
Hint: start with setting a breakpoint at `void
Fl::get_system_colors()` [currently line #131 in
src/Fl_get_system_colors.cxx, both in 1.4 and 1.5), and follow the
calling sequence through
`Fl::screen_driver()->get_system_colors();`. This should reveal
(a) if this calls a Wayland or X11 method, and (b) give some insight
how the colors are selected.
Finally you could add a printf() statement in src/drivers/X11/Fl_X11_Screen_Driver.cxx, line 534:
X11: set_selection_color(r = 0, g = 0, b = 128)
The equivalent function in the Wayland driver is in line 1696 of src/drivers/Wayland/Fl_Wayland_Screen_Driver.cxx. You may want to add:
instead.
I tried it on my system with both X11 and Wayland and get the same result values. However, this would only show the result, not the way the value was retrieved.
Finally you could add a printf() statement in src/drivers/X11/Fl_X11_Screen_Driver.cxx, line 534:
532 static void set_selection_color(uchar r, uchar g, uchar b)
533 {
534 printf("X11: set_selection_color(r = %u, g = %u, b = %u)\n", r, g, b); // add this line
535 Fl::set_color(FL_SELECTION_COLOR,r,g,b);
536 }
If your FLTK version uses X11 this should at least output the
selected color when a program is started. On my system I see:X11: set_selection_color(r = 0, g = 0, b = 128)
The equivalent function in the Wayland driver is in line 1696 of src/drivers/Wayland/Fl_Wayland_Screen_Driver.cxx. You may want to add:
printf("Wayland: set_selection_color(r = %u, g = %u, b = %u)\n", r, g, b); // add this line
instead.
I tried it on my system with both X11 and Wayland and get the same result values. However, this would only show the result, not the way the value was retrieved.
Miguel J
Jan 6, 2026, 9:57:06 AMJan 6
to fltk.general
Thanks for your help.
And it says:
-- Use Wayland Yes (can also run as X11 client)
I will now recompile FLTK in debug configuration and look at what the code does.
Yes, Ubuntu-MATE is using X11 only, at least in 24.04 LTS.
I ran CMake with these options:
-D CMAKE_BUILD_TYPE=Release\
-D FLTK_BUILD_EXAMPLES=ON\
-D FLTK_BUILD_FORMS=OFF\
-D FLTK_BUILD_SHARED_LIBS=ON\
-D FLTK_OPTION_OPTIM="-Os"\
-D FLTK_OPTION_STD=ON
-D CMAKE_BUILD_TYPE=Release\
-D FLTK_BUILD_EXAMPLES=ON\
-D FLTK_BUILD_FORMS=OFF\
-D FLTK_BUILD_SHARED_LIBS=ON\
-D FLTK_OPTION_OPTIM="-Os"\
-D FLTK_OPTION_STD=ON
And it says:
-- Use Wayland Yes (can also run as X11 client)
My tests:
$ fluid -bg '#ff8080'
Not better: the window background becomes red, but the text background is still light grey with light grey selection.
$ fluid -bg2 '#ff8080'
Better: the text background becomes red, and the light grey selection is visible.
$ fluid -bg2 '#ffffff'
Not good: text background is white (255,255,255), selection color is very light grey and almost invisible (250,250,250).
I will now recompile FLTK in debug configuration and look at what the code does.
Miguel J
Jan 6, 2026, 12:43:19 PMJan 6
to fltk.general
OK, I have run the code in debug and found the explanation.
It might make sense (it's a feature, not a bug), but FLTK appears to be almost the only software that behaves this way, so it might not be very good.
Call stack:
#0 getsyscolor (key1="Text", key2="selectBackground", arg=0, defarg="#000080", func=<set_selection_color(uchar, uchar, uchar)>) (fltk-1.4.4/src/drivers/X11/Fl_X11_Screen_Driver.cxx:541)
#1 Fl_X11_Screen_Driver::get_system_colors(this=<optimized out>) (fltk-1.4.4/src/drivers/X11/Fl_X11_Screen_Driver.cxx:563)
#2 Fl::get_system_colors() (fltk-1.4.4/src/Fl_get_system_colors.cxx:133)
#3 Fl_Window::show(this=..., argc=1, argv=...) (fltk-1.4.4/src/Fl_arg.cxx:290)
#4 main(argc=1, argv=<optimized out>) (fltk-1.4.4/fluid/fluid.cxx:2261)
#1 Fl_X11_Screen_Driver::get_system_colors(this=<optimized out>) (fltk-1.4.4/src/drivers/X11/Fl_X11_Screen_Driver.cxx:563)
#2 Fl::get_system_colors() (fltk-1.4.4/src/Fl_get_system_colors.cxx:133)
#3 Fl_Window::show(this=..., argc=1, argv=...) (fltk-1.4.4/src/Fl_arg.cxx:290)
#4 main(argc=1, argv=<optimized out>) (fltk-1.4.4/fluid/fluid.cxx:2261)
The calls in Fl_X11_Screen_Driver::get_system_colors() produce:
* getsyscolor("Text","background", fl_bg2, "#ffffff", Fl::background2);
XGetDefault(fl_display, "Text", "background"); => "#fafafa"
* getsyscolor(key1, "foreground", fl_fg, "#000000", Fl::foreground);
XGetDefault(fl_display, "fltk", "foreground"); => "#3d3d3d"
* getsyscolor(key1, "background", fl_bg, "#c0c0c0", Fl::background);
XGetDefault(fl_display, "fltk", "background"); => "#fafafa"
* getsyscolor("Text", "selectBackground", 0, "#000080", set_selection_color);
arg = XGetDefault(fl_display, "Text", "selectBackground"); => "#fafafa"
* getsyscolor("Text","background", fl_bg2, "#ffffff", Fl::background2);
XGetDefault(fl_display, "Text", "background"); => "#fafafa"
* getsyscolor(key1, "foreground", fl_fg, "#000000", Fl::foreground);
XGetDefault(fl_display, "fltk", "foreground"); => "#3d3d3d"
* getsyscolor(key1, "background", fl_bg, "#c0c0c0", Fl::background);
XGetDefault(fl_display, "fltk", "background"); => "#fafafa"
* getsyscolor("Text", "selectBackground", 0, "#000080", set_selection_color);
arg = XGetDefault(fl_display, "Text", "selectBackground"); => "#fafafa"
And this is consistent with the values returned by the X11 Resources on my system:
$ xrdb -query
...
*Text.activeBackground: #fafafa
*Text.activeForeground: #3d3d3d
*Text.background: #fafafa
*Text.foreground: #3d3d3d
*Text.highlightBackground: #fafafa
*Text.highlightColor: #3d3d3d
*Text.selectBackground: #fafafa
*Text.selectForeground: #3d3d3d
...
*Text.activeForeground: #3d3d3d
*Text.background: #fafafa
*Text.foreground: #3d3d3d
*Text.highlightBackground: #fafafa
*Text.highlightColor: #3d3d3d
*Text.selectBackground: #fafafa
*Text.selectForeground: #3d3d3d
...
But it looks like very few softwares use the "*Text.selectBackground" information, at least when it is stupidly the same at the other text backgrounds.
These lines are not taken from an Xresources file, instead they appear to be generated by /usr/libexec/mate-settings-daemon and sent to "/usr/bin/xrdb -merge -quiet" when the session is started or when the theme is modified. In my case, it generates a text containing:
#define BACKGROUND #fafafa
#define FOREGROUND #3d3d3d
#define SELECT_BACKGROUND #fafafa
#define SELECT_FOREGROUND #3d3d3d
#define WINDOW_BACKGROUND #fafafa
#define WINDOW_FOREGROUND #3d3d3d
...
#define FOREGROUND #3d3d3d
#define SELECT_BACKGROUND #fafafa
#define SELECT_FOREGROUND #3d3d3d
#define WINDOW_BACKGROUND #fafafa
#define WINDOW_FOREGROUND #3d3d3d
...
*Text.background: WINDOW_BACKGROUND
*Text.foreground: WINDOW_FOREGROUND
*Text.highlightBackground: WINDOW_BACKGROUND
*Text.highlightColor: WINDOW_FOREGROUND
*Text.activeBackground: WINDOW_BACKGROUND
*Text.activeForeground: WINDOW_FOREGROUND
*Text.selectBackground: SELECT_BACKGROUND
*Text.selectForeground: SELECT_FOREGROUND
*Text.foreground: WINDOW_FOREGROUND
*Text.highlightBackground: WINDOW_BACKGROUND
*Text.highlightColor: WINDOW_FOREGROUND
*Text.activeBackground: WINDOW_BACKGROUND
*Text.activeForeground: WINDOW_FOREGROUND
*Text.selectBackground: SELECT_BACKGROUND
*Text.selectForeground: SELECT_FOREGROUND
I just created the file ~/.Xresources containing the single line:
*Text.selectBackground: #80FF80
and run:
$ xrdb -merge ~/.Xresources
$ xrdb -merge ~/.Xresources
$ xrdb -query
...
*Text.selectBackground: #80FF80
*Text.selectBackground: #80FF80
...
And the selected texts now appear with a light green background, as requested.
My theme in Ubuntu-MATE is "Yaru-blue".
A similar problem was reported with a similar theme, when using Tcl/tk applications:
So I know how to do a workaround for my system, but I don't know whether this is a bug that needs to be fixed.
What I do know is that the other softwares don't care about it.
Albrecht Schlosser
Jan 6, 2026, 5:24:31 PMJan 6
to fltkg...@googlegroups.com
Hi Miguel,
thank you very much for engaging so intensively with this topic.
I also read your previous mail where you confirmed that your self-built FLTK 1.4.4 was built with Wayland support although Mate uses X11 only. That should be fine.
thank you very much for engaging so intensively with this topic.
I also read your previous mail where you confirmed that your self-built FLTK 1.4.4 was built with Wayland support although Mate uses X11 only. That should be fine.
On 1/6/26 18:10 'Miguel J' via
fltk.general wrote:
OK, I have run the code in debug and found the explanation.It might make sense (it's a feature, not a bug), but FLTK appears to be almost the only software that behaves this way, so it might not be very good.
Yep, I agree (see more below).
Call stack:#0 getsyscolor (key1="Text", key2="selectBackground", arg=0, defarg="#000080", func=<set_selection_color(uchar, uchar, uchar)>) (fltk-1.4.4/src/drivers/X11/Fl_X11_Screen_Driver.cxx:541)
#1 Fl_X11_Screen_Driver::get_system_colors(this=<optimized out>) (fltk-1.4.4/src/drivers/X11/Fl_X11_Screen_Driver.cxx:563)
#2 Fl::get_system_colors() (fltk-1.4.4/src/Fl_get_system_colors.cxx:133)
#3 Fl_Window::show(this=..., argc=1, argv=...) (fltk-1.4.4/src/Fl_arg.cxx:290)
#4 main(argc=1, argv=<optimized out>) (fltk-1.4.4/fluid/fluid.cxx:2261)
This call stack confirms that your program runs with the X11
backend.
The calls in Fl_X11_Screen_Driver::get_system_colors() produce:
* getsyscolor("Text","background", fl_bg2, "#ffffff", Fl::background2);
XGetDefault(fl_display, "Text", "background"); => "#fafafa"
* getsyscolor(key1, "foreground", fl_fg, "#000000", Fl::foreground);
XGetDefault(fl_display, "fltk", "foreground"); => "#3d3d3d"
* getsyscolor(key1, "background", fl_bg, "#c0c0c0", Fl::background);
XGetDefault(fl_display, "fltk", "background"); => "#fafafa"
* getsyscolor("Text", "selectBackground", 0, "#000080", set_selection_color);
arg = XGetDefault(fl_display, "Text", "selectBackground"); => "#fafafa"
OK ...
And this is consistent with the values returned by the X11 Resources on my system:
$ xrdb -query...*Text.activeBackground: #fafafa
*Text.activeForeground: #3d3d3d
*Text.background: #fafafa
*Text.foreground: #3d3d3d
*Text.highlightBackground: #fafafa
*Text.highlightColor: #3d3d3d
*Text.selectBackground: #fafafa
*Text.selectForeground: #3d3d3d
...
But it looks like very few softwares use the "*Text.selectBackground" information, at least when it is stupidly the same at the other text backgrounds.
This raises the question of whether we should really do this, i.e.
whether we should really read X resources (nowadays) and rely on
their contents.
More comments below...
More comments below...
These lines are not taken from an Xresources file, instead they appear to be generated by /usr/libexec/mate-settings-daemon and sent to "/usr/bin/xrdb -merge -quiet" when the session is started or when the theme is modified.
Wow, that's really surprising. I'm wondering what "generates" these
color settings and why they *are* created in the first place!
In my case, it generates a text containing:#define BACKGROUND #fafafa
#define FOREGROUND #3d3d3d
#define SELECT_BACKGROUND #fafafa
#define SELECT_FOREGROUND #3d3d3d
#define WINDOW_BACKGROUND #fafafa
#define WINDOW_FOREGROUND #3d3d3d
It's really weird that several "*background" items have the same
value.
...*Text.background: WINDOW_BACKGROUND
*Text.foreground: WINDOW_FOREGROUND
*Text.highlightBackground: WINDOW_BACKGROUND
*Text.highlightColor: WINDOW_FOREGROUND
*Text.activeBackground: WINDOW_BACKGROUND
*Text.activeForeground: WINDOW_FOREGROUND
*Text.selectBackground: SELECT_BACKGROUND
*Text.selectForeground: SELECT_FOREGROUND
I just created the file ~/.Xresources containing the single line:*Text.selectBackground: #80FF80
and run:
$ xrdb -merge ~/.Xresources$ xrdb -query...
*Text.selectBackground: #80FF80...
And the selected texts now appear with a light green background, as requested.
Awesome. I'm not an X11 user of the old X11 days. I know that Bill
and others of the FLTK Team used X11 much earlier than I did, and I
guess that using Xresources was the standard at the time FLTK was
developed.
However, I doubt that this is still the case today, where every Linux desktop has its own settings and themes, and users manage their desktop appearance by using config dialogs rather than editing Xresources.
However, I doubt that this is still the case today, where every Linux desktop has its own settings and themes, and users manage their desktop appearance by using config dialogs rather than editing Xresources.
My theme in Ubuntu-MATE is "Yaru-blue".A similar problem was reported with a similar theme, when using Tcl/tk applications:
ISTR that we also had another issue report earlier where the user
noticed that the selection color was the same as the background
color. In this case the solution was to use fl_contrast() to set a
better color when needed, but IMHO a much better solution would be
not to set such silly color combinations in the first place.
So I know how to do a workaround for my system, but I don't know whether this is a bug that needs to be fixed.
I'm at least agreeing that this needs to be investigated, and I am
also beginning to believe that we could call it a bug.
What I do know is that the other softwares don't care about it.
That might be the Right Thing (TM) to do for us (FLTK) as well. We
should also investigate whether we should do different things (or
"nothing") in the X11 and Wayland backends, respectively.
Question: should the Wayland backend rely on X resources or not? [ I'm going to look into the code to find out what it is doing now ... ]
Comments from other users and devs would be appreciated. Bill, Matthias, Greg, ... ?
Question: should the Wayland backend rely on X resources or not? [ I'm going to look into the code to find out what it is doing now ... ]
Comments from other users and devs would be appreciated. Bill, Matthias, Greg, ... ?
Le mardi 6 janvier 2026 à 15:57:06 UTC+1, Miguel J a écrit :
Thanks for your help.
Yes, Ubuntu-MATE is using X11 only, at least in 24.04 LTS.
I ran CMake with these options:
-D CMAKE_BUILD_TYPE=Release\
-D FLTK_BUILD_EXAMPLES=ON\
-D FLTK_BUILD_FORMS=OFF\
-D FLTK_BUILD_SHARED_LIBS=ON\
-D FLTK_OPTION_OPTIM="-Os"\
-D FLTK_OPTION_STD=ON
And it says:
-- Use Wayland Yes (can also run as X11 client)
My tests:
$ fluid -bg '#ff8080'Not better: the window background becomes red, but the text background is still light grey with light grey selection.
$ fluid -bg2 '#ff8080'Better: the text background becomes red, and the light grey selection is visible.
$ fluid -bg2 '#ffffff'Not good: text background is white (255,255,255), selection color is very light grey and almost invisible (250,250,250).
I will now recompile FLTK in debug configuration and look at what the code does.
...
Jose Quinteiro
Jan 6, 2026, 7:50:28 PMJan 6
to fltkg...@googlegroups.com
On Tue, 6 Jan 2026 23:24:25 +0100, 'Albrecht Schlosser' via
fltk.general wrote:
> Hi Miguel,
>
> thank you very much for engaging so intensively with this topic.
>
(snip)
fltk.general wrote:
> Hi Miguel,
>
> thank you very much for engaging so intensively with this topic.
>
>>
>> But it looks like very few softwares use the
>> "*Text.selectBackground" information, at least when it is stupidly
>> the same at the other text backgrounds.
>> This raises the question of whether we should really do this, i.e.
>> whether we should really read X resources (nowadays) and rely on
>> their contents.
>>
(snip)
>> But it looks like very few softwares use the
>> "*Text.selectBackground" information, at least when it is stupidly
>> the same at the other text backgrounds.
>> This raises the question of whether we should really do this, i.e.
>> whether we should really read X resources (nowadays) and rely on
>> their contents.
>>
> Awesome. I'm not an X11 user of the old X11 days. I know that Bill
> and others of the FLTK Team used X11 much earlier than I did, and I
> guess that using Xresources was the standard at the time FLTK was
> developed.
>
I am an X11 user that likes old software like Tkdiff (uses Tk,see
> and others of the FLTK Team used X11 much earlier than I did, and I
> guess that using Xresources was the standard at the time FLTK was
> developed.
>
below.)
I have even messed with my Xresources to get rxvt to look how I like.
>>> My theme in Ubuntu-MATE is "Yaru-blue".
>>> A similar problem was reported with a similar theme, when using
>>> Tcl/tk applications:
>>
The user that opened that ticket had trouble with Emacs as well. They
eventually gave up on Yaru and recommended using
clearlooks-phenix-theme
instead. Seems to me the real problem is in the Yaru theme.
It's worth mentioning that there was also trouble using Git GUI (Tk). I
suspect that's in pretty wide use.
(snip)
Thanks,
Jose
Greg Ercolano
Jan 6, 2026, 8:51:04 PMJan 6
to fltk.general
On Tuesday, January 6, 2026 at 2:24:31 PM UTC-8 Albrecht-S wrote:
Comments from other users and devs would be appreciated. Bill, Matthias, Greg, ... ?
Hmm, seems like it's a theme color issue, and I'm not sure it sounds like what FLTK is doing is wrong.
I could offer to write a small/simple pure X application that displays a window with a few boxes
showing a comparison of the X resources for bg, text fg/bg/selection colors to ensure there's no extra translation going on anywhere, if you think that'd help.
Been a looong time since I had to remember how to write pure X applications.
It's almost as bad as doing native win32 programming :^P
I could offer to write a small/simple pure X application that displays a window with a few boxes
showing a comparison of the X resources for bg, text fg/bg/selection colors to ensure there's no extra translation going on anywhere, if you think that'd help.
Been a looong time since I had to remember how to write pure X applications.
It's almost as bad as doing native win32 programming :^P
Manolo
Jan 7, 2026, 4:18:27 AMJan 7
to fltk.general
> Question: should the Wayland backend rely on X resources or not?
FLTK's Wayland backend doesn't use X resources for colors.
Foreground, background, and selection colors are set to the same default values
as those used under X11 without X resources. Global variables fl_fg, fl_bg, fl_bg2,
if set by Fl::args(), override these default values, as under X11.
Miguel J
Jan 7, 2026, 5:28:12 AMJan 7
to fltk.general
Le 07/01/2026 à 01:50, Jose Quinteiro a écrit :
> I am an X11 user that likes old software like Tkdiff (uses Tk,see below.)> I have even messed with my Xresources to get rxvt to look how I like.
> The user that opened that ticket had trouble with Emacs as well. They
> eventually gave up on Yaru and recommended using clearlooks-phenix-theme
> instead. Seems to me the real problem is in the Yaru theme.
> It's worth mentioning that there was also trouble using Git GUI (Tk). I
> suspect that's in pretty wide use.
#!/usr/bin/wish
entry .en
.en insert 0 "Sample text"
pack .en
Interestingly (or not), the selection in this Tcl/tk example is invisible even with the Xresources that makes fluid/X11 (1.3 and 1.4) display a dark green background (and white foreground) on selected texts:
$ xrdb -query
...
*Text.selectBackground: #408040
...
Miguel
Miguel J
Jan 7, 2026, 8:25:29 AMJan 7
to fltk.general
I stay on the same thread, with a minor problem, regarding Fluid, because it is also related to the selection color (but not to the Xresources).
I still have a light theme, still using Linux (Ubuntu-MATE 24.04) with X11.
The scheme is "gtk+", but the problem does not depend of the theme.
In Fluid, create a new project with just:
1) function: make_window()
2) window: Double_Window
Look at the properties for the function: toggle the Fl_Light_Button "C declaration", the mark is:
* yellow (255, 255, 0) when enabled,
* very light grey (250, 250, 250) when disabled.
On such a small mark, the difference between yellow and very light grey is almost invisible.
Now look a the properties for the window, the enabled FL_Light_Button's have a mark color:
* red (255, 0, 0) when enabled.
Now the difference between red and very light grey is clearly visible.
It is written in "FL/Fl_Light_Button.H" that:
"The color of the light when on is controlled with selection_color(), which defaults to FL_YELLOW."
So the problem seems to be: something probably has been done in Fluid so that the color of the light is red, but it does not work for the first item.
This is found in Fluid 1.3.8 and 1.4.4.
Miguel
Matthias Melcher
Jan 7, 2026, 8:33:53 AMJan 7
to fltk.general
Ok, so it seems that the theme is broken for that particular distribution. I suggest that we keep our color management code as is, except once when all colors are set by command line, themes, Xresources and what not, we do a plausibility check. We have the function to calculate contrast, so we can measure readability as well, and if fg, bg, and selection bg don't have enough contrast, we will override them with the nearest contrasting color.
Jose Quinteiro
Jan 7, 2026, 10:23:35 AMJan 7
to fltkg...@googlegroups.com
On Wed, 7 Jan 2026 01:42:52 -0800 (PST), 'Miguel J' via fltk.general
wrote:
that
"...I guess that using Xresources was the standard at the time FLTK was
developed. However, I doubt that this is still the case today, where
every
Linux desktop does it in its own different and incompatible way.
Heck, there are some of us that use X11 on something other than Linux,
even.
Thanks,
Jose
wrote:
> Le 07/01/2026 à 01:50, Jose Quinteiro a écrit :
> > I am an X11 user that likes old software like Tkdiff (uses Tk,see
> below.)
>> I have even messed with my Xresources to get rxvt to look how I
> like.
>
> In my case, rxvt works normally (white background, black chars,
> inverted colors on selected text)
>
My bad, I guess I snipped too much. I was replying to Albrecht's musing
> > I am an X11 user that likes old software like Tkdiff (uses Tk,see
> below.)
>> I have even messed with my Xresources to get rxvt to look how I
> like.
>
> In my case, rxvt works normally (white background, black chars,
> inverted colors on selected text)
>
that
"...I guess that using Xresources was the standard at the time FLTK was
developed. However, I doubt that this is still the case today, where
every
Linux desktop has its own settings and themes, and users manage their
desktop appearance by using config dialogs rather than editing
Xresources."
No, editing Xresources is still very much a thing. Precisely because
Linux desktop has its own settings and themes, and users manage their
desktop appearance by using config dialogs rather than editing
Xresources."
every
Linux desktop does it in its own different and incompatible way.
Heck, there are some of us that use X11 on something other than Linux,
even.
Thanks,
Jose
Albrecht Schlosser
Jan 8, 2026, 8:17:48 AMJan 8
to fltkg...@googlegroups.com
On 1/7/26 16:23 Jose Quinteiro wrote:
> ... I was replying to Albrecht's musing that
edited Xresources myself. I guess I've been lucky that the desktops I
used did it sufficiently well for my applications.
> Heck, there are some of us that use X11 on something other than Linux,
> even.
Yep, I forgot that. Point taken!
As Matthias wrote in another reply to this thread: then it seems to be
the best choice to implement plausibility checks (testing contrast) and
modifying selected colors after everything has been set.
> ... I was replying to Albrecht's musing that
>
> "...I guess that using Xresources was the standard at the time FLTK was
> developed. However, I doubt that this is still the case today, where
> every
> Linux desktop has its own settings and themes, and users manage their
> desktop appearance by using config dialogs rather than editing
> Xresources."
>
> No, editing Xresources is still very much a thing. Precisely because
> every
> Linux desktop does it in its own different and incompatible way.
Thanks for that insight. My personal observation was that I never ever
> "...I guess that using Xresources was the standard at the time FLTK was
> developed. However, I doubt that this is still the case today, where
> every
> Linux desktop has its own settings and themes, and users manage their
> desktop appearance by using config dialogs rather than editing
> Xresources."
>
> No, editing Xresources is still very much a thing. Precisely because
> every
> Linux desktop does it in its own different and incompatible way.
edited Xresources myself. I guess I've been lucky that the desktops I
used did it sufficiently well for my applications.
> Heck, there are some of us that use X11 on something other than Linux,
> even.
As Matthias wrote in another reply to this thread: then it seems to be
the best choice to implement plausibility checks (testing contrast) and
modifying selected colors after everything has been set.
Albrecht Schlosser
Jan 8, 2026, 8:30:40 AMJan 8
to fltkg...@googlegroups.com
On 1/7/26 14:33 'Matthias Melcher'
wrote:
Ok, so it seems that the theme is broken for that particular distribution. I suggest that we keep our color management code as is, except once when all colors are set by command line, themes, Xresources and what not, we do a plausibility check. We have the function to calculate contrast, so we can measure readability as well, and if fg, bg, and selection bg don't have enough contrast, we will override them with the nearest contrasting color.
I agree, if we can find a safe point to calculate contrast and to
modify colors. However, one serious point comes to mind: backwards
compatibility.
Imagine that program developers chose selection colors etc. of their widgets to match the "bad default colors" and create correct contrast. If we changed the "bad default colors" (maybe the background color) to something else, then it might happen that their program's color selections would conflict with our modified colors (and yield bad contrast after all).
Another issue would be programs that change their "themes" dynamically after all the initialization stuff has happened, maybe by user input ...
So, @Matthias: I would be happy if you could find a solution to this problem. This (Xresources etc.) is way outside my comfort zone of FLTK development. ;-)
Imagine that program developers chose selection colors etc. of their widgets to match the "bad default colors" and create correct contrast. If we changed the "bad default colors" (maybe the background color) to something else, then it might happen that their program's color selections would conflict with our modified colors (and yield bad contrast after all).
Another issue would be programs that change their "themes" dynamically after all the initialization stuff has happened, maybe by user input ...
So, @Matthias: I would be happy if you could find a solution to this problem. This (Xresources etc.) is way outside my comfort zone of FLTK development. ;-)
Albrecht Schlosser
Jan 8, 2026, 8:34:25 AMJan 8
to fltkg...@googlegroups.com
On 1/7/26 10:18 Manolo wrote:
> > Question: should the Wayland backend rely on X resources or not?
>
> FLTK's Wayland backend doesn't use X resources for colors.
> Foreground, background, and selection colors are set to the same
> default values
> as those used under X11 without X resources.
Thanks for the clarification, Manolo. I checked this myself meanwhile
> > Question: should the Wayland backend rely on X resources or not?
>
> FLTK's Wayland backend doesn't use X resources for colors.
> Foreground, background, and selection colors are set to the same
> default values
> as those used under X11 without X resources.
and can confirm this.
Miguel J
Jan 8, 2026, 9:53:58 AMJan 8
to fltk.general
I got the same results with the OpenBox window manager, and no Xresources.
- Fl_Light_Button on first item in Fluid (in my example: function) has a yellow mark when enabled. It can be visible enough when the background is medium grey, but not when the background is almost white.
- Fl_Light_Button's on next items (in my example: window) have a red mark when enabled.
I looked at the code but I cannot figure out where the indicator mark color is set to red, but it looks like it is a call to selection_color(1)
Jose Quinteiro
Jan 8, 2026, 10:37:40 AMJan 8
to fltkg...@googlegroups.com
Thanks for all the care and attention paid to this. You guys rock!
Ian MacArthur
Jan 8, 2026, 12:03:55 PMJan 8
to fltk.general
On Thursday, 8 January 2026 at 14:53:58 UTC Miguel wrote:
No, for this question regarding Fluid, I think it is a different problem, and it does not seem to depend on this distribution.
I got the same results with the OpenBox window manager, and no Xresources.
- Fl_Light_Button on first item in Fluid (in my example: function) has a yellow mark when enabled. It can be visible enough when the background is medium grey, but not when the background is almost white.
- Fl_Light_Button's on next items (in my example: window) have a red mark when enabled.I looked at the code but I cannot figure out where the indicator mark color is set to red, but it looks like it is a call to selection_color(1)
Can you maybe post a fluid file that demonstrates this effect?
I've had a few tries, and I'm not seeing this - it just seems to be working OK for me...
I've had a few tries, and I'm not seeing this - it just seems to be working OK for me...
I acknowledge that the "system colours" might still have a bearing on this, so maybe my test is not representative either...!
Miguel J
Jan 8, 2026, 1:21:22 PMJan 8
to fltk.general
Le 08/01/2026 à 18:04, Ian MacArthur a écrit :
> Can you maybe post a fluid file that demonstrates this effect?
> I've had a few tries, and I'm not seeing this - it just seems to be
> working OK for me...
Here you have the fluid file, and the symptoms (assuming that I can attach files).> I've had a few tries, and I'm not seeing this - it just seems to be
> working OK for me...
Matthias Melcher
Jan 8, 2026, 1:47:15 PMJan 8
to fltk.general
Oh, you meant in the user interface of Fluid itself, not the custom UI that Fluid generates. Yeah, well, in the history of Fluid, various authors have set their specific selection color for this class of widgets. Admittedly, the Fl_LIght_Button looks horrible with the default dark blue selection color, and since the button is inspired by 1980's buttons with integrated LEDs, it should probably be red. I personally don't like this button style at all.
1.5 does no longer have that second dialog box. It's all in a tab the widget dialog now. Eventually I hope I can replace all Light Buttons with something more modern.
Reply all
Reply to author
Forward
0 new messages