STR #3358: checkbox labels become bold when OPTIONS_VISIBLE_FOCUS is off

STR #3358

Application:	FLTK Library
Status:	2 - Closed w/o Resolution
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	checkbox labels become bold when OPTIONS_VISIBLE_FOCUS is off
Version:	1.3.4
Created By:	ajapted
Assigned To:	AlbrechtS
Fix Version:	None
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	AlbrechtS 05:59 Nov 25, 2016

buttons.cxx
1k

Trouble Report Comments:

#1	ajapted 00:54 Nov 25, 2016

My application does a Fl::option(Fl::OPTIONS_VISIBLE_FOCUS, false); However when clicking on a checkbox widget, the label becomes bold and stays bold indefinitely. You can confirm this by adding the above Fl::option call to test/buttons.cxx -- happens in both FLTK 1.3.3 and 1.3.4 This is under Linux and X windows, I presume it affects all OSes but I haven't tested this.

#2	AlbrechtS 05:59 Nov 25, 2016

Thanks for the report and the test instructions. Short answer: this is not a bug. Set a "drawing" box type, e.g. FL_FLAT_BOX to avoid this anti-aliasing effect. Longer answer: the effect can be seen because the (default) box type of the widgets in question (Fl_Check_Button and Fl_Round_Button) is FL_NO_BOX and clicking on the button causes the label to be redrawn. This, combined with anti-aliasing, makes the widget's label become bold. The (removal of the) focus box redraws the entire widget and its background so that this effect can not be seen with normal focus box handling. You can easily work around this anti-aliasing effect if you give your widget a solid background, i.e. not FL_NO_BOX and not one of the FRAME box types. More information: you can always clear that anti-aliasing effect if you resize the window (if it's resizable). That's why I added the resizable() instruction to the demo program. Under some systems and/or window managers you can also force a redraw of the widget or window if you (partially) occlude it by another window and raise it back to foreground. [Un]fortunately some systems (e.g. MS Windows) and some window managers save the window contents so there is no redraw after exposing the window. Modified test program: see attached file buttons.cxx. Compile with fltk-config --compile buttons.cxx Run with one commandline argument <opt> (numerical: -1..3) to see different effects: 0: normal, default behavior 1 (not 0): set OPTION_VISIBLE_FOCUS false. 2: additionally set FL_FLAT_BOX for the Fl_Round_Button widget 3: additionally set FL_FLAT_BOX for the Fl_Check_Button widget -1: do parent()->redraw() instead. see below. To test the behavior: (1) run './buttons 1' to see the effect you described. Now resize the window and see the label get back to normal state. (2) run './buttons 1' to see how the FL_FLAT_BOX "fixes" the round button (3) run './buttons 2' to see how the FL_FLAT_BOX "fixes" the check button (4) run './buttons -1' to see how the parent's redraw "fixes everything". This is not recommended, it may flicker. Just for testing purposes. Please report if setting a box type with a background helps in your case.

#3	ajapted 03:19 Nov 27, 2016

Another data point: I can trigger similar behavior without disabling OPTION_VISIBLE_FOCUS. Run test/buttons, click on a checkbox widget and hold the button down, then move the mouse off the widget. The label text will become bold-ish. I found your response was very disheartening, as though this was an issue with my usage of FLTK rather than a shortcoming of FLTK itself. Perhaps you could have acknowledged that the default boxtype for checkbox widgets should have been FL_FLAT_BOX all along, and that you guys are unwilling to "fix" that because some existing software may break. Anyway, you can fix the above issue and my original issue by the judicial use of redraw_label() in the Fl_Button code. It is interesting that the Fl_Button code is the only code outside of Fl_Widget that uses redraw_label(), perhaps because some issues like this occurred in the past. Meanwhile I will use one of the workarounds that you suggested.

#4	AlbrechtS 05:06 Nov 28, 2016

Andrew, I apologize if my response sounded disheartening to you. That was not my intention. My intention was to collect facts and show you a way to solve the issue for you. I didn't want to say it was your fault or wrong usage. I used the posted demo program for my own testing and to explain what happened to you and maybe other readers. Indeed I had thought about the questionable choice of FL_FLAT_BOX as the default box type of these button classes. We can discuss if this was a good choice and we should certainly do that, but this wouldn't solve your problem immediately. Note that I didn't write the original FLTK code and the early developers are no longer available here. So I can only guess that this choice was made in the early days of FLTK to avoid additional drawing of the background to speed up operations. In the old days (1998+) this was an important fact, and AFAICT anti-aliasing effects like those seen here were not critical (xft and anti-aliased text drawing was likely added later, but I may be wrong with this assumption). You can be sure that we are not "unwilling to 'fix' that because some existing software may break", but this is a very important and IMHO valid argument. Changing the default box type is something that may likely have an impact on many, many applications out there. We don't know these applications, so changing this is a difficult decision, particularly because these widgets are very likely present in almost all non-trivial applications. You wrote: > Anyway, you can fix the above issue and my original issue > by the judicial use of redraw_label() in the Fl_Button code. > It is interesting that the Fl_Button code is the only code > outside of Fl_Widget that uses redraw_label(), perhaps because > some issues like this occurred in the past. I take this seriously as a heads-up to check all this. However I don't think that it can easily be solved by a few statements somewhere in the code. I know off the top of my head that there is at least one check somewhere in the FLTK code that tests if a box type of a widget is transparent (NO_BOX or *FRAME*) and draws the parent (and thus its background) if this is the case. But what if the parent group also has a transparent background? This would be recursive and could result in the entire window having to be redrawn which is certainly not a good decision in all cases. And there's even more to it (window background images, 'plastic' scheme, to name only two that come to mind). This is something that needs lots of code investigation and discussion to be sure we make the right decision without too much impact on existing applications. But we're a small developer team, we're not full-time FLTK developers, and we're not paid for FLTK development. So please understand that this case is of low priority and will maybe not be solved soon. Anyway, I can offer two proposals since this is not going to be changed in 1.3, which is closed for new features: (1) we take your problem as resolved and make this STR a feature request for 1.4 which sounds sensible since there are lots of informations and a test program available here. I can do that if you agree. (2) we close this STR and you file another STR with your proposal against 1.4.0 (1.4-feature). It's your choice. Thank you for your comments and proposals.

#5	AlbrechtS 08:24 Nov 17, 2023

This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please open a GitHub Issue and refer to this STR.