FLTK 1.4.0rc1 released on Oct. 20, 2024

44 views
Skip to first unread message

Albrecht Schlosser

unread,
Oct 20, 2024, 5:25:47 PM10/20/24
to fltk.coredev
We're pleased to announce the release of FLTK 1.4.0rc1.

This is the first release candidate of a new release with major
enhancements, some new widgets, macOS and CMake improvements, and some
bug fixes.

FLTK 1.4 is based on the final release of FLTK 1.3.4. Later updates have
been backported to 1.3.5 - 1.3.9. FLTK 1.3.10 with the latest backports
is planned to be released shortly after 1.4.0 or 1.4.1.

FLTK 1.4 is intended to be mostly API compatible with FLTK 1.3.x so you
don't need to change source code when you switch to FLTK 1.4. However,
all programs must be recompiled with FLTK 1.4 because the ABI
(Application Binary Interface) has changed.

Potential source code conflicts are documented in chapter "Migrating
Code from FLTK 1.3 to 1.4" of the user documentation [1].

FLTK 1.4 adds some new widgets (e.g. Fl_Flex, Fl_Grid) for flexible GUI
layout, Fl_Scheme_Choice for scheme selection by users, and more. Other
widgets (Fl_Tabs, Fl_Tile, Fl_Spinner etc.) have been improved for
better user experience.

CMake support has been improved significantly and requires CMake 3.15 or
higher, autotools/configure/make is still supported. The latter will be
dropped in the next minor release (1.5.0).

macOS is supported up to 15.0 "Sequoia".

The platform dependent code in FLTK 1.4 was rewritten to enable better
porting to new platforms. Basically all platform dependent code has been
isolated and implemented in virtual methods of "driver" classes. See
src/drivers and subdirectories.

FLTK is now compatible with the Wayland platform on current Linux
distributions and FreeBSD. The default build of the library on these
platforms supports both X11 and Wayland in a "hybrid" library. Programs
compiled and linked to this library start using Wayland if it is
available at runtime and fall back to using X11 if not. Programs using
X11 specific code that are not yet ported to Wayland can still be used
on pure X11 systems or by disabling the Wayland support on startup so
they fall back to using X11 only.

The current development branch on GitHub [2] is `master`. This will be
changed to `branch-1.4` when development of FLTK 1.5.0 begins and 1.4
will move to maintenance mode.

Feedback and bug reports (if necessary) will be appreciated.

The next release candidate or the final release will be published
between 7 and 14 days from now. Earlier, if we need to make bug fixes,
later (up to 14 days) if no bugs are reported.


[1] https://www.fltk.org/doc-1.4/ (HTML) and
    https://www.fltk.org/doc-1.4/fltk.pdf (PDF)<br>
[2] https://github.com/fltk/fltk.git

melcher....@googlemail.com

unread,
Oct 20, 2024, 5:28:34 PM10/20/24
to fltk.coredev
HOORAY for RC1!

Albrecht Schlosser

unread,
Oct 20, 2024, 5:45:48 PM10/20/24
to fltkc...@googlegroups.com
On 10/20/24 23:28 'melcher....@googlemail.com' via fltk.coredev wrote:
HOORAY for RC1!

Wow, that was a  Q U I C K  reply!

Matthias, please check commit d85b67beac200357756e61b25f05f64c7c103501 where I tried to fix one .fl file in fluid because it looks as if you edited the .cxx file. I had to decide which one was correct and I decided to use the .cxx file and to "fix" the .fl file. If that's wrong, please correct it. TIA.

I uploaded the new FLTK (HTML + PDF) docs but I did not yet upload new Fluid docs, and there are no "Fluid docs" tarballs on the "Download" page yet. I'm planning to do this later. The current docs are fine AFAICT.

Albrecht

Manolo

unread,
Oct 21, 2024, 3:14:20 AM10/21/24
to fltk.coredev
Le dimanche 20 octobre 2024 à 23:25:47 UTC+2, Albrecht-S a écrit :
We're pleased to announce the release of FLTK 1.4.0rc1.

It's great to see 1.4.0rc1 out after so much work in it! Many thanks to Albrecht.

I suggest the annoucement of the new release should include one additional item:

FLTK 1.4 adds or improves support of HighDPI displays under Linux/Unix and Windows.

That's because I believe HighDPI support is a major new feature of 1.4, especially
under Linux where HighDPI displays were just not readable with 1.3.

Albrecht Schlosser

unread,
Oct 21, 2024, 9:11:08 AM10/21/24
to fltkc...@googlegroups.com
On 10/21/24 09:14 Manolo wrote:
Le dimanche 20 octobre 2024 à 23:25:47 UTC+2, Albrecht-S a écrit :
We're pleased to announce the release of FLTK 1.4.0rc1.

It's great to see 1.4.0rc1 out after so much work in it! Many thanks to Albrecht.

Welcome. Many thanks to you as well, particularly for your continuing macOS support and for adding Wayland.

Not to forget: Many thanks to Matthias' support for fluid, docs, and more, to Greg, Ian, and all other contributors.


I suggest the annoucement of the new release should include one additional item:

FLTK 1.4 adds or improves support of HighDPI displays under Linux/Unix and Windows.

Sure, I forgot to mention it. I added a paragraph to the release article [1]:

"FLTK 1.4 supports HighDPI displays under Linux/Unix and Windows and improves HighDPI support on macOS. The initial screen scaling factor is read from the system and application windows can be zoomed (in/out/reset) by the user with ctrl/+/-/0 shortcuts, respectively."

I'm open for other suggestions. I will use this full text in the next announcements (RC2, ..., final release).


[1] https://www.fltk.org/articles.php?L1947

Bob Tolbert

unread,
Oct 21, 2024, 9:46:31 AM10/21/24
to fltkc...@googlegroups.com
I have been a user and a fan of FLTK since 2001 and it is great to see continued progress. Congratulations on this milestone (I know it has been hard) and here’s to continued to success.

Now that I am fully retired, I hope I can help a bit and give back to a tool that helped me so much over the last 20+ years.

Bob Tolbert

--
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/59968a81-9338-422d-a7cc-51b9a2c6c2ab%40aljus.de.

Basile STARYNKEVITCH

unread,
Oct 21, 2024, 10:24:50 AM10/21/24
to fltkc...@googlegroups.com, te...@refpersys.org

I suggest saying:

1. how on Linux compile with both DWARF debugging information and optimizations without assuming expertise with cmake (e.g. giving the shell commands). Since DWARF is required by the libbacktrace library https://github.com/ianlancetaylor/libbacktrace and that library and FLK is used in the RefPerSys inference engine project on https://github.com/RefPerSys/RefPerSys/

2. what open source license is FLTK compatible with. I hope that it is compatible with GPLv3+ (the license of RefPerSys).

3. Any porting hints from FLTK 1.3.9 to FLTK 1.4 (for Linux mostly)

4. If you know of any binding of e.g. Ocaml with FLTK please mention them.

A big thanks for your efforts on FLTK

Regards.

-- 
Basile STARYNKEVITCH           <bas...@starynkevitch.net>
8 rue de la Faïencerie
92340 Bourg-la-Reine           mobile: +33 6 8501 2359
France                         http://starynkevitch.net/Basile/

Albrecht Schlosser

unread,
Oct 21, 2024, 10:57:27 AM10/21/24
to fltkc...@googlegroups.com
On 10/21/24 15:46 Basile STARYNKEVITCH wrote:
On 10/21/24 15:11, 'Albrecht Schlosser' via fltk.coredev wrote:
[...]

I'm open for other suggestions. I will use this full text in the next announcements (RC2, ..., final release).


I suggest saying:


Thanks for your suggestions.

1. how on Linux compile with both DWARF debugging information and optimizations without assuming expertise with cmake (e.g. giving the shell commands). Since DWARF is required by the libbacktrace library [...]


We don't give build instructions in the announcement, such info would be useful in the docs.

Personally I don't know how to do what you request. If you can contribute such info, please open a GitHub issue or PR, or maybe a GitHub Discussion thread in section "Show and tell": https://github.com/fltk/fltk/discussions/categories/show-and-tell

A *small* but complete example would be preferred. If it's really short we might add it to README.CMake.txt .


2. what open source license is FLTK compatible with.


Good point, this could be added to the announcement, although it is in the docs (LGPL with exceptions).


I hope that it is compatible with GPLv3+ (the license of RefPerSys).


You hope? Really? ;-)

Seriously: if RefPerSys already uses FLTK you should know that the license is compatible, shouldn't you?


3. Any porting hints from FLTK 1.3.9 to FLTK 1.4 (for Linux mostly)


This is written in the announcement: usually no changes, and the reference to the docs for potential issues is given in the announcement.


4. If you know of any binding of e.g. Ocaml with FLTK please mention them.


Personally I know of pyFLTK (Python) and fltk-rs (Rust) bindings but there are certainly more. I don't think that the announcement should list such bindings because we can never be sure not to forget relevant ones and last but not least: since FLTK 1.4.0 has not yet been released finally, how would we know which bindings (already) work with FLTK 1.4 ?

We could perhaps find a way how users could contribute to a list of bindings known to work and add this to the docs but I'm not sure if we should really do this. We'd have to check and know that such bindings still work after changes to FLTK etc. etc.. This would be hard to prove and extra work we probably can't justify.


A big thanks for your efforts on FLTK

Welcome, thanks for your kind words.

melcher....@googlemail.com

unread,
Oct 21, 2024, 2:28:25 PM10/21/24
to fltk.coredev


bas...@starynkevitch.net schrieb am Montag, 21. Oktober 2024 um 16:24:50 UTC+2

4. If you know of any binding of e.g. Ocaml with FLTK please mention them.

I found https://github.com/Termite/ocamlfltk which starts to wrap fltk2 according to its README. I am sure that an FLTK 1.4  wrapper can be written based on the code. fltk2 is outdated despite the higher version number.

Albrecht Schlosser

unread,
Oct 22, 2024, 9:25:42 AM10/22/24
to fltkc...@googlegroups.com
On 10/21/24 15:46 Bob Tolbert wrote:
> I have been a user and a fan of FLTK since 2001 and it is great to see
> continued progress.

That's about as long as I am working with FLTK as a user. I became a
developer some time later.

> Congratulations on this milestone (I know it has been hard) and here’s
> to continued to success.

Welcome.

> Now that I am fully retired, I hope I can help a bit and give back to
> a tool that helped me so much over the last 20+ years.

That's awesome, all help will be appreciated. For a start, here are some
ideas:

You could start testing some old STR's [1], whether they are still
relevant, add comments, test code [2], and potentially patches. Whenever
you find something that could be fixed you can copy an old STR over to a
GitHub Issue [3] and propose a patch - or even make a PR. Patches and
PR's for documentation could also be a good start...

Thanks in advance for all help.


[1] https://www.fltk.org/roadmap.php

[2] Many of the old STR's (and certainly some GitHub Issue) have
descriptions but no test code, i.e. they are missing a small but
complete test program that shows the issue. It would be a big help if
such small test programs would be available so devs can test and develop
fixes with less effort.

[3] https://github.com/fltk/fltk/issues

Bob Tolbert

unread,
Oct 22, 2024, 9:57:52 AM10/22/24
to fltkc...@googlegroups.com


> On Oct 22, 2024, at 08:25, 'Albrecht Schlosser' via fltk.coredev <fltkc...@googlegroups.com> wrote:
>
> On 10/21/24 15:46 Bob Tolbert wrote:
>> I have been a user and a fan of FLTK since 2001 and it is great to see
>> continued progress.
>
> That's about as long as I am working with FLTK as a user. I became a
> developer some time later.
>
>> Congratulations on this milestone (I know it has been hard) and here’s
>> to continued to success.
>
> Welcome.
>
>> Now that I am fully retired, I hope I can help a bit and give back to
>> a tool that helped me so much over the last 20+ years.
>
> That's awesome, all help will be appreciated. For a start, here are some
> ideas:
>
> You could start testing some old STR's [1], whether they are still
> relevant, add comments, test code [2], and potentially patches. Whenever
> you find something that could be fixed you can copy an old STR over to a
> GitHub Issue [3] and propose a patch - or even make a PR. Patches and
> PR's for documentation could also be a good start...
>
> Thanks in advance for all help.

These are great ideas. It was unclear the best way in and this is fantastic.

Thanks for all the info.

Bob

>
>
> [1] https://www.fltk.org/roadmap.php
>
> [2] Many of the old STR's (and certainly some GitHub Issue) have
> descriptions but no test code, i.e. they are missing a small but
> complete test program that shows the issue. It would be a big help if
> such small test programs would be available so devs can test and develop
> fixes with less effort.
>
> [3] https://github.com/fltk/fltk/issues
>
> --
> 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/8d0c426f-5d7c-46a3-a75d-79a14a34270d%40aljus.de.

Reply all
Reply to author
Forward
0 new messages