Preparation of release 1.4.5

[Albrecht Schlosser]

I am in the process of preparing the next public release 1.4.5, but
there is still something to do before we can release it. There is no
schedule yet but I hope we can release 1.4.5 by the end of February
(2026 ;-) ).

For now I updated the version number(s) in all relevant files with the
goal to check ABI compatibility. So far I didn't find any issues.

I created a new milestone "FLTK 1.4.5" on GitHub:
https://github.com/fltk/fltk/milestone/11

Please add issues that *must* be fixed in 1.4.5 to this milestone, but
keep in mind that only severe bugs should be fixed, and that no new
features should be added to 1.4.x releases. Note that we have already 36
commits since release 1.4.4.

Please add a comment to this thread if you think anything else is worth
(necessary) considering for 1.4.5.

[Daniel Harding]

Hi Albrecht,

I understand you may be trying to slow down changes to branch-1.4 in order to have something stable to prepare for the release, but I politely request that you consider backporting the following 3 bug fixes to branch-1.4 before releasing FLTK 1.4.5:

1. https://github.com/fltk/fltk/commit/2b3cb9be65a1ca392e9d277c6b494ad77277d38a

2. https://github.com/fltk/fltk/commit/ea1b1bddd96be6616e1b2b0eccbe815f9b71ad11

3. https://github.com/fltk/fltk/commit/99648c047c01fb1868c2adab8b515cec9739ea38

Thanks for considering.

-Daniel

[Albrecht Schlosser]

Hi Daniel and others,

on 4/20/26 19:09 Daniel Harding wrote:

I understand you may be trying to slow down changes to branch-1.4 in order to have something stable to prepare for the release, 

In fact it's not "slow down" but "stop" changes. The gist is that I want to wait about 14 days after the last commit for potential issues to come up after these commits to avoid having to push yet another release quickly after the previous one.

Another rule is our agreed-upon policy that only severe bugs shall be fixed in a patch releases.

... I politely request that you consider backporting the following 3 bug fixes to branch-1.4 before releasing FLTK 1.4.5:

1. https://github.com/fltk/fltk/commit/2b3cb9be65a1ca392e9d277c6b494ad77277d38a

2. https://github.com/fltk/fltk/commit/ea1b1bddd96be6616e1b2b0eccbe815f9b71ad11

3. https://github.com/fltk/fltk/commit/99648c047c01fb1868c2adab8b515cec9739ea38

Thanks for considering.

I'm willing to consider this, but I can't do any significant work on FLTK before Wednesday (April 22). Since the release is scheduled for Saturday, there's not much room to consider and backport the commits you mentioned. I'll need most of the time (besides my private life ;-) ) to finalize the release. I'm sorry, but chances to backport these changes to branch-1.4 right now (before the release) are minimal.

Others have asked for a quick release, and I promised to do it on Saturday, 25th. As you can see, there are conflicting requests.

OTOH I think that two of these commits are pretty simple and safe, but I have no idea what the third commit (ea1b1bddd96be6616e1b2b0eccbe815f9b71ad11) is about. I mean, I know what it's intended to do, but I don't know if there's any risk changing the macOS code this way, or if there's potential for regressions.


Albrecht


PS: I'm generally open for FLTK developer votes on including these three patches in 1.4.5. I request that those who vote +1 for a particular patch have reviewed it thoroughly and tested on the platform in question or on at least two platforms (if not platform specific). Please vote for each patch separately, and mention the platforms you tested it on. I need final votes until Thursday, 4 pm (UTC). Maybe we can make an exception - if the risk of issues is (or at least seems) very small. Please don't expect much feedback from me tomorrow (Tuesday UTC) because I'll be busy.

PPS: I'm personally not willing to break these rules further for 1.4.x without a discussion and consensus about changing our policy, but note also that I am for not changing this. I support, however, releasing 1.5.0 soon (about July/August might be possible), and also to release more often in the future. This should reduce the pressure on backporting. Hopefully.

[melcher....@googlemail.com]

https://github.com/fltk/fltk/commit/2b3cb9be65a1ca392e9d277c6b494ad77277d38a

disables tooltips on popup menu windows for all platforms, not only for "Unix". I am indifferent to this fix. It doesn't seem to break anything, but it *does* change some behavior on macOS and Windows - probably to the better.

https://github.com/fltk/fltk/commit/ea1b1bddd96be6616e1b2b0eccbe815f9b71ad11

is mediating a rendering artifact. There is no risk of breaking much. It does not solve all possible rendering attribute combinations. +1

https://github.com/fltk/fltk/commit/99648c047c01fb1868c2adab8b515cec9739ea38

seems minimally invasive and fixes a true bug. +1

[melcher....@googlemail.com]

melcher....@googlemail.com schrieb am Dienstag, 21. April 2026 um 17:41:36 UTC+2:

https://github.com/fltk/fltk/commit/ea1b1bddd96be6616e1b2b0eccbe815f9b71ad11

is mediating a rendering artifact. There is no risk of breaking much. It does not solve all possible rendering attribute combinations. +1

I change this to -1. The patch changes the graphics produced for fl_begin_loop()/fl_end_loop() to FL_CAP_SQUARE, even if the user may have explicitly called fl_line_style(FL_CAP_ROUND), overriding the user's decision.

The correct solution IMHO is to define the default line cap for FLTK (if we did not do that yet) and implement that correctly for all graphics drivers. The rendering code for each symbol can then call fl_line_style(FL_CAP_SQUARE) if that is not the default, or whatever other cap style it wants to use. As with all changes in line style, the code must set the cap style back to whatever the default is after use.

 

[Daniel Harding]

On Wednesday, April 22, 2026 at 10:38:38 AM UTC-5 melcher....@googlemail.com wrote:

The rendering code for each symbol can then call fl_line_style(FL_CAP_SQUARE)

Adding `fl_line_style(FL_CAP_SQUARE)` myself to each of my symbol draw functions is a good enough fix for me to work around this issue myself. I withdraw my request to backport commit ea1b1bd. Thank you for that suggestion.

Commit 99648c0 is still important to me, because it ensures that I am able to override as many symbol draw functions as I wish.

On Tuesday, April 21, 2026 at 10:41:36 AM UTC-5 melcher....@googlemail.com wrote:

https://github.com/fltk/fltk/commit/2b3cb9be65a1ca392e9d277c6b494ad77277d38a

disables tooltips on popup menu windows for all platforms, not only for "Unix". I am indifferent to this fix. It doesn't seem to break anything, but it *does* change some behavior on macOS and Windows - probably to the better.

In my testing, it doesn't actually change any behavior on Windows. It does change behavior on macOS, by fixing a significant blemish. See my video in the bug report for more detail: https://github.com/fltk/fltk/issues/1408

Thanks

[Manolo]

Le mercredi 22 avril 2026 à 17:38:38 UTC+2, melcher....@googlemail.com a écrit :

melcher....@googlemail.com schrieb am Dienstag, 21. April 2026 um 17:41:36 UTC+2:

https://github.com/fltk/fltk/commit/ea1b1bddd96be6616e1b2b0eccbe815f9b71ad11

is mediating a rendering artifact. There is no risk of breaking much. It does not solve all possible rendering attribute combinations. +1

I change this to -1. The patch changes the graphics produced for fl_begin_loop()/fl_end_loop() to FL_CAP_SQUARE, even if the user may have explicitly called fl_line_style(FL_CAP_ROUND), overriding the user's decision.

I disagree with this statement. The modified virtual function is used only by FLTK function fl_end_loop() which ends and draws a closed line.
A closed line has no endpoint. The graphics property CGContextSetLineCap that the commit transiently changes 

"sets the style for the endpoints of lines drawn in a graphics context."

This property should not affect a closed line because it has no endpoint, and it's a Quartz bug that it does (by missing to draw a pixel in a difficult to

predict geometrical position). That's visible for example when Cairo is used instead of Quartz:

when the Cairo version of the same virtual member function is changed to call   cairo_set_line_cap(cairo_, CAIRO_LINE_CAP_SQUARE)

or  cairo_set_line_cap(cairo_, CAIRO_LINE_CAP_BUTT) or   cairo_set_line_cap(cairo_, CAIRO_LINE_CAP_ROUND),

no change occurs to the resulting loop. The commit restores, when the modified function returns, the setting of the line cap property to 

the value it had when that function was called.

[melcher....@googlemail.com]

I pushed a fix to 1.5 master.:

https://github.com/fltk/fltk/commit/e19bc59ec1543c399c621d9a54d7ab5548bce89c

Adding CGContextClosePath will make line drawing behave as expected, and line cap settings are ignored as they should be:

https://developer.apple.com/documentation/coregraphics/cgcontext/closepath()

+1 on back porting

[Manolo]

Le mercredi 22 avril 2026 à 21:15:41 UTC+2, melcher....@googlemail.com a écrit :

Adding CGContextClosePath will make line drawing behave as expected, and line cap settings are ignored as they should be:

Great! closing the path is the true fix for sure. Strangely, and that's true also in FLTK 1.3, CGContextClosePath() was

used everywhere else (fl_loop, fl_end_polygon, fl_arc, fl_pie, fl_polygon, fl_end_complex_polygon) but not in fl_end_loop!

[Manolo]

Le lundi 20 avril 2026 à 21:18:42 UTC+2, Albrecht-S a écrit :

PS: I'm generally open for FLTK developer votes on including these three patches in 1.4.5.

In case it's useful,  my votes are +1 for all 3 patches to be backported to 1.4.5.
These are their commit numbers:

2b3cb9b

99648c0

ea1b1bd + e19bc59

Manolo

[melcher....@googlemail.com]

https://github.com/fltk/fltk/commit/99648c047c01fb1868c2adab8b515cec9739ea38 fixes the main bug. Stays +1 for me.

fl_add_symbol() has still two more bugs, but that is irrelevant for FLTK 1.4 . I will file an issue and fix then using C++11 code after the 1.5 solution is back ported - If Albrecht decides to do so.

The -1 of https://github.com/fltk/fltk/commit/ea1b1bddd96be6616e1b2b0eccbe815f9b71ad11 is now a +1 from my side for https://github.com/fltk/fltk/commit/e19bc59ec1543c399c621d9a54d7ab5548bce89c

[Albrecht Schlosser]

Thanks to Manolo and Matthias for your feedback, to Matthias for the additional fix (e19bc59ec1543), and to Manolo for confirming this fix.

I agree now to backport the solutions for the three requested and discussed issues, i.e. my votes are +1 for the final fixes.

But, please note: This should be considered a unique exception because it breaks our rules regarding bug fixes in maintenance branches.

Anyway: I am closing the survey on backporting these three problems (prematurely) since we have reached a consensus: 3 votes / result +3. Thanks to all.

I'll backport (cherry-pick) the fixes and my plan is to merge the two commits to the macOS "close-path" issue so we will finally have three separate commits.

After that I'll prepare the release for Sat. April 25, as announced. If everything goes smoothly I will try to release earlier, but that depends on my progress.

[Albrecht Schlosser]

On 4/23/26 12:58 schrieb 'Albrecht Schlosser' wrote:

On 4/23/26 10:20 Manolo wrote:

...

I'll backport (cherry-pick) the fixes and my plan is to merge the two commits to the macOS "close-path" issue so we will finally have three separate commits.

Finally I had to push one more commit to the macOS "close-path" and merged these three commits to one commit in branch-1.4. These are the new commits which will be included in release 1.4.5:

fltk/branch-1.4 $ git log -3
commit efef8eb219907464a9c879b0f753739c57452e4b
Author: ManoloFLTK <41016272+...@users.noreply.github.com>
Date:   Tue Apr 14 16:10:48 2026 +0200

    Fix "Mac: Most fl_symbols missing corner pixels" (#1409).
    
    + Fix line loop drawing on macOS (#1409)
    + macOS: yet another fix of line drawing (#1409)
    
    All fixes backported and merged from master, commits:
    
     - ea1b1bddd96be6616e1b2b0eccbe815f9b71ad11
     - e19bc59ec1543c399c621d9a54d7ab5548bce89c
     - 3c8bc27458d649a85a04ee0483fec6023fa4c83e

commit 1869ba9455526734570a0470fcef50a1eee50fa2
Author: ManoloFLTK <41016272+...@users.noreply.github.com>
Date:   Tue Apr 14 16:33:44 2026 +0200

    Fix "fl_add_symbol() *always* increments symbnumb" (#1410).
    
    Backported from master: 99648c047c01fb1868c2adab8b515cec9739ea38

commit 49bc0a4fb1a2cae2d41aeb15b28354826e6a42ab
Author: ManoloFLTK <41016272+...@users.noreply.github.com>
Date:   Tue Apr 14 12:17:13 2026 +0200

    Fix "Mac: Stubborn tooltips when menu window is open" (#1408)
    
    The fix extends to all platforms the check that doesn't post a tooltip
    window if a menu window is active. Therefore, virtual member function
    Fl_System_Driver::use_tooltip_timeout_condition() is no longer necessary.
    
    Backported from master: 2b3cb9be65a1ca392e9d277c6b494ad77277d38a.

Note: the top commit in this list is now a collaboration of Manolo, Matthias, and me. Great teamwork.

After that I'll prepare the release for Sat. April 25, as announced. [...]

If nothing unforeseen happens, the release schedule remains unchanged.