Release FLTK 1.3.9

[Albrecht Schlosser]

Dear FLTK devs,

I'm preparing the release of FLTK 1.3.9.

Current status:

- version numbers have been updated
- doxygen docs have been fixed
- some more minor bugs were fixed
- latest commit pushed to branch-1.3

Still to do:

- Update bundled image libraries and zlib (I will do this asap, likely
tomorrow).

If there are any updates you want to be in 1.3.9, then this is the time
to ask for it - or to push commits - quickly.

I don't intend to make release candidates for such minor updates. If
there are bugs we'll release 1.3.10 soon.

I would appreciate tests and feedback before the release. Please let me
know if I forgot something.

Albrecht

[Albrecht Schlosser]

On 12/3/23 00:02 Albrecht Schlosser wrote:

Dear FLTK devs,

I'm preparing the release of FLTK 1.3.9.

Current status:

- version numbers have been updated
- doxygen docs have been fixed
- some more minor bugs were fixed
- latest commit pushed to branch-1.3

Still to do:

- Update bundled image libraries and zlib (I will do this asap, likely tomorrow).

Done now. I believe I'm ready to release 1.3.9. I scheduled the release for Dec 09, 2023.
From CHANGES:

```
CHANGES IN FLTK 1.3.9                    RELEASED: Dec 09 2023

FLTK 1.3.9 is a maintenance release with some fixes and enhancements.

Highlights in this release:

  - Support macOS up to macOS 14 "Sonoma".
  - Update bundled libraries to current versions.
  - Introduce bundled image library "prefixing" to avoid conflicts
    with system libraries.
```

I would appreciate tests and feedback before the release. Please let me know if I forgot something.

Note that I decided to update the bundled libs to the same status as in 1.4.0, i.e. symbol prefixing is now available in 1.3.x as well.

There are still more than 3 days for testing and feedback. I'd appreciate test reports for particularly for Windows and macOS on different build systems, e.g. Windows with old MinGW (maybe 32-bit and 64-bit), MSYS2, Visual Studio (older versions), nmake, ...
I will test building on my Windows VM (MinGW, MSYS2, VS 2019).

Meanwhile I'll also check ABI compatibility but I don't expect any issues.

I will start the final release on Dec 09 after 13:00 CET (noon UTC) but please report issues until Dec 08 (whatever time zone you are in).

Thanks in advance
Albrecht

[Manolo]

I don't know if I should commit changes myself. In doubt, I don't.

Three obsolete Doxygen commands should be removed from file

documentation/Doxyfile.in because they trigger warnings :

% make html
Generating Doxyfile ...
Generating HTML documentation...
warning: Tag 'COLS_IN_ALPHA_INDEX' at line 758 of file 'Doxyfile' has become obsolete.
         To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'CLASS_DIAGRAMS' at line 1325 of file 'Doxyfile' has become obsolete.
         To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'DOT_TRANSPARENT' at line 1483 of file 'Doxyfile' has become obsolete.
         To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
[macbook-pro-de-manolo:fltk/fltk-1.3-git/documentation] mgouy% make html
Generating Doxyfile ...
Generating HTML documentation...

[Manolo]

Attempting configure-based build on macOS with default settings

Fails because by default JPEG and PNG are local whereas ZLIB is system,
and this error occurs
make[1]: *** [png.o] Error 1
In file included from pngtrans.c:14:
../png/pngpriv.h:911:4: error: ZLIB_VERNUM != PNG_ZLIB_VERNUM       "-I (include path) error: see the notes in pngpriv.h"
#  error ZLIB_VERNUM != PNG_ZLIB_VERNUM \

Solution: force --enable-localzlib when local PNG is selected

[Manolo]

Attaching patch to remove compilation warnings under macOS

(the changes for documentation/Doxyfile.in are in there too) :

[Manolo]

Since there was a commit, I will push too.

[imacarthur]

On Tuesday 5 December 2023 at 18:42:42 UTC Albrecht Schlosser wrote:

I would appreciate tests and feedback before the release. Please let me know if I forgot something.

FWIW, I ran "autoconf" builds of 1.3.x with various differing ages on mingw, and as best I can discern, these all worked correctly.

Note that *all* were configured with " --enable-localjpeg --enable-localpng --enable-localzlib" passed to configure explicitly, since I didn't want the "system" libs to be used (my setup has "many" mingw versions, and they do occasionally trip over each other...)

This may have some bearing on the issue that Manolo reported with the OSX configure, where it was "unhappy" about mixing system zlib with "local" png. I have not seen that problem, under mingw - but of course would not because I am explicitly selecting the local zlib...

[Albrecht Schlosser]

On 12/6/23 09:15 Manolo wrote:
> I don't know if I should commit changes myself. In doubt, I don't.

It's OK to push commits now. As I wrote before, I'll start release work
on Dec 09, 2023, after noon (UTC).

This is something we may have to live with because we can't assume that
a user has a particular Doxygen version. Since we can't fix all warnings
for all Doxygen versions this is a battle we can't win. Therefore I
wouldn't mind triggering warnings in 1.3.

One option I used in 1.4 is to remove such obsolete parameters if we can
make sure that they are indeed the DEFAULT values in those doxygen
versions that use them. But it's complicated...

Anyway, your commit doesn't hurt. Thanks for this.

[Albrecht Schlosser]

On 12/6/23 15:50 imacarthur wrote:

On Tuesday 5 December 2023 at 18:42:42 UTC Albrecht Schlosser wrote:

I would appreciate tests and feedback before the release. Please let me know if I forgot something.

FWIW, I ran "autoconf" builds of 1.3.x with various differing ages on mingw, and as best I can discern, these all worked correctly.

Great, thanks!

Note that *all* were configured with " --enable-localjpeg --enable-localpng --enable-localzlib" passed to configure explicitly, since I didn't want the "system" libs to be used (my setup has "many" mingw versions, and they do occasionally trip over each other...)

That's usually the best approach on Windows if you want to build "native" (portable) Windows applications anyway. Otherwise MinGW and MSYS may pull in dependencies on their own DLL's.

This may have some bearing on the issue that Manolo reported with the OSX configure, where it was "unhappy" about mixing system zlib with "local" png. I have not seen that problem, under mingw - but of course would not because I am explicitly selecting the local zlib...

We definitely need to make sure that we either use both (zlib, png) as system versions or as bundled versions, i.e. if *any* of libpng or zlib is either not found or explicitly selected as the bundled version then both bundled versions must be used. There are two reasons: (1) the version mismatch posted by Manolo, and (2) the new "symbol prefixing" used since 1.3.9 (and used already for a while in 1.4) which precludes mixing system and bundled versions of these two libs. libjpeg is independent of the other libs though.

@Manolo: I copied the relevant CMake code from 1.4 but I obviously missed the configure stuff. Reading only your commit I'm not sure if this fixes both cases described above. I'd appreciate if you could check this and report if it's OK or fix this if it does not. TIA.

Thanks to all for tests and feedback!

[Albrecht Schlosser]

On 12/6/23 15:01 Manolo wrote:

Since there was a commit, I will push too.

OK, as I wrote before.

However, the removal of the ability to build 1.3 on macOS using X11 constitutes formally a regression. I understand why you did it and I also understand that macOS users needing X11 can use 1.4.0, and I agree that this is necessary, hence we should keep this.

Should be document this fact? Basically:

- users wanting X11 on macOS must use either FLTK 1.3.8 or 1.4.0 but not 1.3.9

- users wanting to run on latest macOS releases need 1.3.9 though (but probably only for non-X11 builds)

Is this correct?

OTOH, even if we wouldn't document it explicitly there are chances that "nobody" uses FLTK/X11 on macOS except us FLTK devs. ;-)

[Manolo]

Le mercredi 6 décembre 2023 à 16:28:24 UTC+1, Albrecht Schlosser a écrit :

However, the removal of the ability to build 1.3 on macOS using X11 constitutes formally a regression. I understand why you did it and I also understand that macOS users needing X11 can use 1.4.0, and I agree that this is necessary, hence we should keep this.

I agree it's formally a rgeression. But we really have no choice because it's become a nightmare to compile with -U__APPLE__ for new macOS SDK versions.

Should we document this fact? Basically:

- users wanting X11 on macOS must use either FLTK 1.3.8 or 1.4.0 but not 1.3.9

It's not a question of FLTK version within branch 1.3.x . It's a question of macOS SDK version: new ones are just not able to compile code with -U__APPLE__, and removing all uses of

#ifdef __APPLE__

from 1.3 would more or less amount to transform it in the driver-organized 1.4 branch.

WIth 1.3.8, --enable-x11 will fail also with recent macOS SDKs.

In contrast, the 1.4 branch does not mess with __APPLE__ but instead uses FLTK_USE_X11 to trigger X11 on macOS,

and new as well as old macOS SDKs are happy.

- users wanting to run on latest macOS releases need 1.3.9 though (but probably only for non-X11 builds)

Yes, that is correct. Although only command-line launch of apps does not work with 1.3.8 + macOS Sonoma.

 

……

OTOH, even if we wouldn't document it explicitly there are chances that "nobody" uses FLTK/X11 on macOS except us FLTK devs. ;-)

Yes, I'm pretty sure nobody except me has ever used it. It's very useful at least for me to develop FLTK on my mac.

I have documented the change in CHANGES, and would suggest that's enough.

 

[Albrecht Schlosser]

On 12/6/23 16:50 Manolo wrote:

Le mercredi 6 décembre 2023 à 16:28:24 UTC+1, Albrecht Schlosser a écrit :

However, the removal of the ability to build 1.3 on macOS using X11 constitutes formally a regression. I understand why you did it and I also understand that macOS users needing X11 can use 1.4.0, and I agree that this [change] is necessary, hence we should keep this.

I agree it's formally a rgeression. But we really have no choice ...

I have documented the change in CHANGES, and would suggest that's enough.

I'm fine with this, well done.

Thanks for testing and helping to get 1.3.9 out.

[Manolo]

Le mercredi 6 décembre 2023 à 16:16:40 UTC+1, Albrecht Schlosser a écrit :

We definitely need to make sure that we either use both (zlib, png) as system versions or as bundled versions, i.e. if *any* of libpng or zlib is either not found or explicitly selected as the bundled version then both bundled versions must be used. There are two reasons: (1) the version mismatch posted by Manolo, and (2) the new "symbol prefixing" used since 1.3.9 (and used already for a while in 1.4) which precludes mixing system and bundled versions of these two libs. libjpeg is independent of the other libs though.

@Manolo: I copied the relevant CMake code from 1.4 but I obviously missed the configure stuff. Reading only your commit I'm not sure if this fixes both cases described above. I'd appreciate if you could check this and report if it's OK or fix this if it does not. TIA.

After commit 5b56596 , both these configure-based build work on macOS:

./configure

./configure --enable-localpng

[Albrecht Schlosser]

And what about

  ./configure --enable-localzlib

?

Assuming that a system libpng exists and was found, this would cause trouble unless libpng is forced to local by configure as well. That was my question.

Sorry, no time to test this myself...

[Manolo]

Tests made on Windows XP with MinGW + GCC 4.9

configure + make : OK

CMake + make : OK

cmake-gui + OPTION_BUILD_SHARED_LIBS + make : OK

[Manolo]

Le mercredi 6 décembre 2023 à 17:13:07 UTC+1, Albrecht Schlosser a écrit :

And what about
  ./configure --enable-localzlib ?

Assuming that a system libpng exists and was found, this would cause trouble unless libpng is forced to local by configure as well. That was my question.

I tried

 ./configure --enable-localzlib

and obtained

Image Libraries: JPEG=Builtin
                 PNG=Builtin
                 ZLIB=Builtin

and a successful build.

I'm not sure what would produce on a macOS system "a system libpng exists and was found".

On mine, libpng is present in /opt/homebrew/lib and in /opt/sw/lib and none is found

by configure as "system libpng", so there's no need to force libpng to local.

[Albrecht Schlosser]

Manolo, yes, this is true on your system, and I found that it is also true on my macOS system. But can we guarantee that this is true on everybody's system?

Investigating and testing...

This configure stuff and libpng vs. zlib versions and symbol prefixing is not only macOS specific, it is an issue on all platforms when using configure/make to build. We definitely need the code to check the libpng vs. zlib options in configure as we have in FLTK 1.4, e.g. in code with this comment at line 750:
```
# If we use the system zlib, we must also use the system png lib and vice versa.
# If either of them is not available, we fall back to using both local libraries
... code follows ... but this is maybe not the only place ...
```

If we don't have it in 1.3's configure.ac we can get library mix as this shows on my linux (!) system:

FLTK 1.4:
```
/git/fltk/master$ make distclean; autoconf; ./configure --enable-localpng
...
checking for gzgets in -lz... yes
checking for zlib.h... yes
configure: WARNING: Local png lib selected: overriding z lib to local for compatibility.
...
Image Libraries: JPEG=System
                 PNG=Builtin   <<< OK
                 ZLIB=Builtin  <<< OK
```

FLTK 1.3:
```
/git/fltk/branch-1.3$ make distclean; autoconf; ./configure --enable-localpng
...
Image Libraries: JPEG=System
                 PNG=Builtin   <<< WILL FAIL
                 ZLIB=System   <<< WILL FAIL
...
/git/fltk/branch-1.3$ make
=== making png ===
make[1]: Entering directory '/git/fltk/branch-1.3/png'
Compiling png.c...
In file included from png.c:14:
pngpriv.h:911:4: error: #error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the notes in pngpriv.h"
  911 | #  error ZLIB_VERNUM != PNG_ZLIB_VERNUM \
      |    ^~~~~
```


So, now it is clear that we need it to avoid build failures on user systems (same as in 1.4). Unfortunately I did copy the CMake code but missed the configure stuff. I suggest that we try to copy and paste the relevant parts of configure.ac from 1.4 to 1.3.

Somebody needs to do it. Please feel free to do it or drop a note here, then I'll look into it tomorrow afternoon.

Good night

Albrecht

[Manolo]

Le mercredi 6 décembre 2023 à 23:33:16 UTC+1, Albrecht Schlosser a écrit :

So, now it is clear that we need it to avoid build failures on user systems (same as in 1.4). Unfortunately I did copy the CMake code but missed the configure stuff. I suggest that we try to copy and paste the relevant parts of configure.ac from 1.4 to 1.3.

Somebody needs to do it. Please feel free to do it or drop a note here, then I'll look into it tomorrow afternoon.

That's committed at c59c400.

[Albrecht Schlosser]

Thank you, your help is very much appreciated.

[Manolo]

Hi Albrecht,

I would like to make sure you're aware of a potential difficulty in the construction of the documentation

for FLTK 1.3.9. The version of Doxygen present in today's Debian/Ubuntu releases has this bug

we've identified and discussed before that makes the documentation index unusable and that produces

a slightly wrong main HTML page. This bug is visible, for example, at our daily

updated GitLab mirror doicumentation:  https://fltk.gitlab.io/fltk/

The cure is to use a more recent Doxygen version when preparing the HTML files.

I know you know that, but it's easy to neglect one detail among the lots at hand when preparing

a new release without an RC.

Manolo

[Albrecht Schlosser]

On 12/8/23 09:20 Manolo wrote:
> Hi Albrecht,
>
> I would like to make sure you're aware of a potential difficulty in
> the construction of the documentation

> for FLTK 1.3.9. ...

> The cure is to use a more recent Doxygen version when preparing the
> HTML files.
>
> I know you know that, but it's easy to neglect one detail among the
> lots at hand when preparing
> a new release without an RC.

Thank you for the heads-up, and yes, I'm aware of this problem but I
could nevertheless forget it at the moment of the creation of the
release tarballs.

I intend to use my self-built doxygen 1.9.8 which seems to work well and
which I also used to generate our current 1.4 online docs.

Cheers
Albrecht

[Albrecht Schlosser]

On 12/5/23 19:42 Albrecht Schlosser wrote:
> I will test building on my Windows VM (MinGW, MSYS2, VS 2019).

Everything I tested on my system (systems above + NMake) worked as
expected, as well as Linux and macOS.

Together with all test results reported by others this looks great.
Thanks to all for testing and feedback.

> Meanwhile I'll also check ABI compatibility but I don't expect any
> issues.

Done. Result is 100% ABI compatibility with 1.3.8.

The only A*P*I difference flagged by the report was the changed patch
version - which would be bad if it was not changed.

See attachment: compat_report.html

> I will start the final release on Dec 09 after 13:00 CET (noon UTC)

> but please report issues until [...]

Still about 16 hours left for potential test and/or bug reports.

[Albrecht Schlosser]

On 12/8/23 17:25 Albrecht Schlosser wrote:

I will start the final release on Dec 09 after 13:00 CET (noon UTC) but please report issues until [...]

Still about 16 hours left for potential test and/or bug reports.

I made some last minute updates today, mostly for docs and CMake compatibility. CMake minimum required version is now 3.15, as in FLTK 1.4 as well.

The release is finished now and I also uploaded the new 1.3.9 docs to the FLTK server.

Please be aware that you may need to clear / reset your browser cache to see the new version. You should see the new search field with the dark mode/light mode "sun" icon



and the doxygen version 1.9.8 in the bottom right corner:



I'd appreciate feedback if anything is missing. TIA

See also my release posts in fltk.announce, fltk.general, and fltk.coredev.

[Manolo]

Well done!

[Greg Ercolano]

Nice!

Perhaps in 1.3.10 (if there ever is one), we can sneak in the new widgets
Fl_Grid, Fl_Flex, Fl_Terminal and Fl_Rect.

For sure Fl_Terminal works in 1.3.x; I gave someone a few simple mods for
how to do that, so it should be possible.

But this hopefully won't be necessary if 1.4.0 releases, though I could see
where people might not want to move to 1.4.0 until a few maintenance releases
come out. I know if I were on 1.3.x, I would wait until the minor number was
>2 or so.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/0adf18e1-d20c-45e8-9549-7227f030029b%40online.de.

-- 
Greg Ercolano, er...@seriss.com
Seriss Corporation
Tel: +1 626-576-0010 ext.8
Fax: +1 626-576-0020
Cel: +1 310-266-8906
Skype: ercolano77

      Rush Render Queue: http://seriss.com/rush/
  1A2 KSU Phone Systems: http://seriss.com/1a2-ksu/
Optical Printer Control: http://seriss.com/opcs/

[Albrecht Schlosser]

On 12/9/23 22:30 Greg Ercolano wrote:

Perhaps in 1.3.10 (if there ever is one), we can sneak in the new widgets
Fl_Grid, Fl_Flex, Fl_Terminal and Fl_Rect.

I believe not. Sure, there may be a 1.3.10 but this should only be a maintenance update if necessary. No new features.

For sure Fl_Terminal works in 1.3.x; I gave someone a few simple mods for
how to do that, so it should be possible.

Technically it's possible, at least for Fl_Terminal and Fl_Rect (which is not a widget by itself).

Fl_Grid and Fl_Flex need support by new features in Fl_Group, and these features went also into other widgets. New can of worms ...

No, we shouldn't event think of this. Let's keep 1.3.x as stable as it is now.

But this hopefully won't be necessary if 1.4.0 releases,

Yup, the plan is still to release this year, at least one release candidate (RC1).

though I could see
where people might not want to move to 1.4.0 until a few maintenance releases
come out. I know if I were on 1.3.x, I would wait until the minor number was
>2 or so.

We can enforce these versions by quickly releasing maintenance updates, maybe one every week? ;-) Kidding.

Honestly, if we plugged the new widgets into 1.3.x this wouldn't be much better than 1.4.0, 1.4.1, 1.4.2 etc. stability-wise. Although I don't want to say that 1.4.0 wouldn't be "stable" or ready for production. I believe it is but there may of course be some issues.

I released 1.3.9 to be free to work on 1.4.0 and finally to release 1.4.0 very soon now. Once it is done everybody should be able to move from 1.3.x to 1.4.0/.1/.2 (again, technically spoken). If there are other (political) reasons to wait, it's everybody's own decision.

Let's see how 1.4.0 evolves in the next two weeks, I'm pretty confident.