Upgrade destination

26 views
Skip to first unread message

Howard Lightstone

unread,
Mar 28, 2025, 7:20:28 PM3/28/25
to fltk.general
I now have to upgrade a forthcoming program that uses fltk1.1.2 (which works just fine but...).
Should I just pick 1.4x or try for 1.5x right away.

imm

unread,
Mar 28, 2025, 7:28:59 PM3/28/25
to General FLTK
On Fri, 28 Mar 2025, 23:20 Howard Lightstone wrote:
I now have to upgrade a forthcoming program that uses fltk1.1.2 (which works just fine but...).
Should I just pick 1.4x or try for 1.5x right away.

At this point, the API for 1.4 and 1.5 are (basically) the same, so if your code compiles with either it will probably be fine with both.

Do you care if it's a stable release? If so, use 1.4.
If you don't mind being a bit more bleeding edge then 1.5 is fine.
I don't expect it to make all that much difference in the immediate term.

Also, 1.1.2 is pretty old... I mean really....

Be interesting to hear how the port goes. I like to imagine it will just work, but...
--
Ian
From my Fairphone FP3

Greg Ercolano

unread,
Mar 28, 2025, 8:49:33 PM3/28/25
to fltkg...@googlegroups.com

On 3/28/25 4:28 PM, imm wrote:

On Fri, 28 Mar 2025, 23:20 Howard Lightstone wrote:
I now have to upgrade a forthcoming program that uses fltk1.1.2 (which works just fine but...).

Also, 1.1.2 is pretty old... I mean really....

    Wow, 1.1.2? That was released in 2002, it's over 23 years old.

    Howard, what OS/platform are you building on that 1.1.2 still compiles and runs?

Howard Lightstone

unread,
Mar 29, 2025, 4:43:15 AM3/29/25
to fltkg...@googlegroups.com
Still on Windoze, originally for windows 3.11,
still having to use Visual Studio 2005

hence rewrite (long) needed and still make old (FDA cleared device) logic work.

It looks like it was  from about 2003.


--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/41940f84-497b-4d31-9cab-bd75141951d7%40seriss.com.


--
Howard Lightstone
how...@eegsoftware.com

Howard Lightstone

unread,
Mar 29, 2025, 4:43:22 AM3/29/25
to fltkg...@googlegroups.com
I should add, it currently runs on 10 and 11 but the desire is for machine independence.
--
Howard Lightstone
how...@eegsoftware.com

Albrecht Schlosser

unread,
Mar 29, 2025, 10:03:52 AM3/29/25
to fltkg...@googlegroups.com


On 3/28/25 23:57 Howard Lightstone wrote:
I now have to upgrade a forthcoming program that uses fltk1.1.2 (which works just fine but...).
Should I just pick 1.4x or try for 1.5x right away.

As Ian and others wrote already, 1.4.x (currently 1.4.2) is our stable release, 1.5 is current development and thus kinda "bleeding edge". One of these should be your target.

However, for "porting" your app I suggest to use 1.3.11 as an intermediate step. Porting from 1.3 to 1.4 and/or 1.5 should be pretty easy after you're satisfied with 1.3.11, but you could always try to compile your "1.3 app" with a 1.4 FLTK library.

Things to consider:

It's important to note that FLTK 1.3 and later uses UTF-8 as internal encoding. If the app uses only ASCII (7-bit characters), then the port should be trivial, but you need to consider that users can enter international characters (encoded as multi-byte UTF-8) in text widgets etc.. If you use external interfaces (e.g. text files) you need to consider this.

Before you start you should read the special documentation chapters on "Migrating Code from FLTK 1.1 to 1.3" ( https://www.fltk.org/doc-1.3/migration_1_3.html ) and "Migrating Code from FLTK 1.3 to 1.4" ( https://www.fltk.org/doc-1.4/migration_1_4.html ). There is no chapter on migration from 1.4 to 1.5 yet.

The main points are (from 1.1 to 1.3):
 - change of coordinates from 16-bit to 32-bit int's
 - UTF-8 (8-bit multibyte characters) rather than "code pages" (8-bit single byte characters only)
 - replace Fl_Scroll::position(int x, int y) with Fl_Scroll::scroll_to(int x, int y)

The latter is important (if it is used at all) because the compiler wouldn't detect an issue and produce wrong code.

The main points are (from 1.3 to 1.4):
 - Header files should be included in all source files for all widgets and system functions you are using. If this is done correctly, it will work with FLTK 1.3 and 1.4 as well.
 - If the app uses system (Windows) specific code you should include `FL/platform.H` rather than `FL/x.H` (this file was renamed in 1.3.x). You can do this already when using 1.3.11 (or any later version).
- If the app uses its own classes derived from FLTK widgets you can use the new FL_OVERRIDE macro or (if using a C++11 capable compiler, the 'override' keyword). Then you can ignore the FL_OVERRIDE macro.
- If your app uses a splash screen or something similar, i.e. if it's waiting for a timeout w/o running the FLTK loop Fl::run(), then you should check the chapter "Fl::add_timeout and friends" as well.

Good luck with porting, and feel free to ask here again if you have specific problems.

Albrecht Schlosser

unread,
Mar 29, 2025, 10:10:10 AM3/29/25
to fltkg...@googlegroups.com
On 3/29/25 01:49 Greg Ercolano wrote:
    Wow, 1.1.2? That was released in 2002, it's over 23 years old.

    Howard, what OS/platform are you building on that 1.1.2 still compiles and runs?

I just tested `branch-1.1` on my current Debian Stable. With some special compiler flags it can still be built and the demo apps work (as far as I tested).

These flags work, although with some remaining warnings:
CXX_FLAGS='-fpermissive -Wno-deprecated-declarations -Wno-int-to-pointer-cast -Wno-register' ./configure
With the same flags even a CMake build with the included basic CMake files works, although CMake issues another set of CMake warnings.

Note: I'm not going to update branch-1.1 :-)

Albrecht Schlosser

unread,
Mar 29, 2025, 10:20:07 AM3/29/25
to fltkg...@googlegroups.com
On 3/29/25 15:03 'Albrecht Schlosser' via fltk.general wrote:
... Before you start you should read the special documentation chapters on "Migrating Code from FLTK 1.1 to 1.3" ( https://www.fltk.org/doc-1.3/migration_1_3.html ) and "Migrating Code from FLTK 1.3 to 1.4" ( https://www.fltk.org/doc-1.4/migration_1_4.html ). There is no chapter on migration from 1.4 to 1.5 yet.

You should also check the list of deprecated functions and methods in FLTK 1.3 docs [1]. The plan is to remove most of this deprecated stuff in FLTK 1.5 (still work in progress), hence if your code uses such deprecated methods in 1.3 and/or 1.4 it would likely break in 1.5, but if you check and remove the deprecated code in 1.3 it should work even with future 1.5 versions. Only stuff that's already deprecated in 1.3 will be removed in 1.5, but it would be useful to check the deprecated list of 1.4 as well [2].

[1] https://www.fltk.org/doc-1.3/deprecated.html
[2] https://www.fltk.org/doc-1.4/deprecated.html

Reply all
Reply to author
Forward
0 new messages