As requested (Albrecht), here's the VS 2017's build warnings for fltk 1.4.x ( 58296c373a79) in "Release" mode.

There actually aren't many warnings now. I could have sworn there was a huge pile of warnings last week.. maybe magically fixed by elves. They seemed all over the place.

Not gonna bother with a uniq(1), this is a short list.

5>[..]src\Fl_Screen_Driver.cxx(432): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
41>[..]test\fractals.cxx(237): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(238): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(512): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(513): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(516): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(517): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(520): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(524): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(525): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(558): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
41>[..]test\fractals.cxx(560): warning C4838: conversion from 'double' to 'GLfloat' requires a narrowing conversion
44>[..]test\glpuzzle.cxx(108): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
44>[..]test\glpuzzle.cxx(188): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
44>[..]test\glpuzzle.cxx(218): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
44>[..]test\glpuzzle.cxx(335): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
44>[..]test\glpuzzle.cxx(1348): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion
44>[..]test\glpuzzle.cxx(1352): warning C4838: conversion from 'double' to 'float' requires a narrowing conversion

This PR clarifies the special cases in test/demo.cxx regarding different build systems and platform specific code.

The goal is to de-duplicate code and to reduce platform specific code to a minimum.

I also added a big comment describing the different directory layouts of the different build systems for future development. See test/demo.cxx.

Before this commit some of the test/demo programs could not be started in some builds (e.g. Visual Studio) because the paths differ between the classic (autoconf/make) and the new CMake generated build systems.

This should all be fixed now. I could test successfully under Windows and Linux but I'd like to see confirmations from others (see also the commit comments).

Summary of important changes:

• For CMake builds I removed the '/examples' folder so all executable (fluid and test/demo) programs are now directly in the /bin folder of the build root.
• I also added a new folder /data in the build root (same level as /bin). All test support (data) files including demo.menu are now in this folder to keep them apart from the executables.
• [Edit] There's no longer an executable path ../fluid in demo.menu - this is handled in the demo program depending on the build system (bug fix). [/Edit]

For all other changes please refer to the source file test/demo.cxx.

This commit adds an error message to Fl_File_Chooser so the user can see that there are no files.

To do: provide the cause of an error (if any) or document how to find it.

add example code for creating images for resize.dox based on Article #415: How does resizing work? https://www.fltk.org/articles.php?L415

see also https://www.fltk.org/str.php?L3433

Albrecht reminds us about an old 2015 fltk.coredev thread:

• Subject: "Fl_Menu_::copy() just evil"

..regarding possible memory issues with Fl_Menu (and friends) with respect to static definitions of menus and how they interact with Fl_Menu_::copy(), i.e. if it's a "deep copy", or what.

Quoting the OP (I think @CendioOssman ?) regarding Fl_Menu_::copy():

It does quite happily make a copy of the array of Fl_Menu_Item's. But it completely forgets about all the embedded strings. However Fl_Menu_::clear() still thinks it owns these strings so it calls free() on them.

It seems Pierre (the OP) suspected there were cases where free() would be called on static items.

I see no followups to that thread indicating this was either verified or solved or reported as an STR/github issue. So adding this issue to investigate, and whatever comes of it, would be good to also follow up to that thread, old as it is, to indicate one way or the other what the resolution was. [EDIT: I followed up to the thread, referring to this issue to close the loop, since any answers should end up here]

I'm using Fl_Simple_Terminal to emulate remote shell terminal monitor, and found Fl_Simple_Terminal has some strange color parsing with \033 escape. For example, remote shell returns these buffer to Fl_Simple_Terminal,

-rw-r--r-- 1 linaro linaro 4065 Dec  5 09:34 Makefile
-rw-r--r-- 1 linaro linaro  417 Mar  8  2022 README.md
drwxr-xr-x 2 linaro linaro 4096 Dec  2 02:02 \033[0m\033[01;34masm\033[0m
drwxr-xr-x 2 linaro linaro 4096 Dec  5 09:34 \033[01;34mbin\033[0m
-rwxr-xr-x 1 linaro linaro 1413 Mar  8  2022 \033[01;32mconfigure\033[0m
-rwxr-xr-x 1 linaro linaro  141 Aug  2 23:34 \033[01;32mgv.sh\033[0m
drwxr-xr-x 5 linaro linaro 4096 Jun 17 07:25 \033[01;34mlib\033[0m
drwxr-xr-x 2 linaro linaro 4096 Dec  5 09:34 \033[01;34mobj\033[0m
-rwxr-xr-x 1 linaro linaro  384 May  4  2022 \033[01;32mpackaging.sh\033[0m
drwxr-xr-x 2 linaro linaro 4096 Sep 30 09:03 \033[01;34mrefs\033[0m
drwxr-xr-x 2 linaro linaro 4096 Nov 30 00:48 \033[01;34msrc\033[0m

When ansi() enabled Fl_Simple_Terminal displays just RED color with \033[01;32m as parsed color is "1" == RED. I think it should better process checking ";" in Fl_Simple_Terminal by like this.

                            switch(*sp)
                            {
                                case ';':         // numeric separator
                                    ++sp;
                                    continue;

to

                            switch(*sp)
                            {
                                case ';':         // numeric separator
                                    ++sp;
                                    if ( tv > 0 ) tv = 0;
                                    continue;

Fl_Simple_Terminal cannot display all escape colors, but it should express similar color as I thought. Here's my forked & branched commit here.

• https://github.com/rageworx/fltk-origin/commit/c834f45aa777e8622f01f45a06c0d0c10fa2799e

I hope it may fix strange color parsing for Fl_Simple_Terminal.

Describe the bug When pulling 1.4.x into my applications, I noticed all the text on buttons and menus seemed off-center by +1 on x and y, vs. my 1.3.4-2 builds which seem normal. It's noticeable in my app because I use small buttons with the text inside, so text alignment issues are easy to see.

~~I also see this issue comparing 1.3.4-2 and 1.3.x current git, so the change happened somewhere after 1.3.4-2.~~

To Reproduce Run the test/radio demo and compare. Here's an animation comparing the radio demo in 1.3.4-2 vs. 1.4.x:

Steps to reproduce the behavior:

1. Build 1.3.x with default 'configure/make', run test/radio
2. Build 1.4.x with default 'configure/make', run test/radio
3. Compare screenshots of the two, noting text positioning offset

Hopefully the above animation shows the issue clearly. You can see how the "radio 1/2/3/4" text is now touching the group border box, whereas before it didn't. It seems ALL text is offset by +1 on x/y.

FLTK Version

• Version: 1.4.x and 1.3.x current (as compared to 1.3.4-2)

FLTK Configure / Build Options Default configure/make.

Operating System / Platform: This is on Linux Ubuntu 20.04.05 with default gnome window manager.

Linux/Unix Runtime, if applicable:

• X11

Replication with fltk.1.4.x + Linux (SciLinux 7 in my case):

1. ./configure --enable-localpng
2. make
3. `test/native-filechooser
4. Click "Pick File"
5. Application core dumps with these errors:

(native-filechooser:15756): GdkPixbuf-WARNING **: 13:34:20.782: Bug! loader 'png' didn't set an error on failure
(native-filechooser:15756): Gtk-WARNING **: 13:34:20.782: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
(native-filechooser:15756): GdkPixbuf-WARNING **: 13:34:20.782: Bug! loader 'png' didn't set an error on failure
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Adwaita/16x16/status/image-missing.png: Internal error: Image loader module ?png? failed to complete an operation, but didn?t give a reason for the failure (gdk-pixbuf-error-quark, 5)
Abort (core dumped)

I assume this is due to a difference in GTK's version of PNG and FLTK's.

Works fine if --enable-localpng is not used.

Apparently the GTK file browser doesn't like to be linked with FLTK's PNG library.

I'm not sure if this is avoidable, but it's very deadly for the app.

 93     errno = 0;
 94     e = readdir(dirp);
 95     if (NULL == e)
 96     {
 97       if (!errno)
 98       {
 99         /* No more entries in directory */
100         *entryp = NULL;
101         *len = 0;
102         result = 0;
103       }

Change line 97 to

97 if ((!errno) || (ENOENT == errno))

This is according to POSIX. GCC and DJGPP apparently have different behavior,

When using cmake + make to build on OSX, only the xxx.app version of the test programs are created. The wrapper scripts are needed too, vis a vis fltk-config --post xxx

(See also: pull request #111 )

On Ubuntu 16.04, the issue can be reproduced in both the checkers and bitmap test apps. Checkers is unplayable. Occasionally, fragments of a piece will appear if you drag the mouse around the board, but for the most part, the pieces are invisible. In the bitmap app, the sorceress is initially visible, but disappears as soon as one of the buttons is clicked. Occasionally, I can get it to reappear by resizing the window. The problem doesn't seem to affect (e.g.) Fl_PNG_Image: I replaced the checkers piece bitmap with a png and the display issue went away.

[1/2] /usr/bin/c++  ...  -Wall -Wunused -Wsuggest-override -g -std=c++2a ... /Fluid_Image.cxx.o -MF fluid/CMakeFiles/fluid.dir/Fluid_Image.cxx.o.d -o fluid/CMakeFiles/fluid.dir/Fluid_Image.cxx.o -c ../../fluid/Fluid_Image.cxx
../../fluid/Fluid_Image.cxx: In member function ‘void Fluid_Image::write_static(int)’:
../../fluid/Fluid_Image.cxx:141:15: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  141 |     if (nData == -1) write_file_error("GIF");
      |         ~~~~~~^~~~~
../../fluid/Fluid_Image.cxx:153:15: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  153 |     if (nData == -1) write_file_error("BMP");
      |         ~~~~~~^~~~~
../../fluid/Fluid_Image.cxx:206:15: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  206 |     if (nData == -1) write_file_error("JPEG");
      |         ~~~~~~^~~~~
../../fluid/Fluid_Image.cxx:218:15: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  218 |     if (nData == -1) write_file_error("PNG");
      |         ~~~~~~^~~~~
../../fluid/Fluid_Image.cxx:233:19: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  233 |         if (nData == -1) write_file_error("SVGZ");
      |             ~~~~~~^~~~~
../../fluid/Fluid_Image.cxx:239:19: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  239 |         if (nData == -1) write_file_error("SVG");
      |             ~~~~~~^~~~~
../../fluid/Fluid_Image.cxx: At global scope:
../../fluid/Fluid_Image.cxx:54:12: warning: ‘bmp_header_written’ defined but not used [-Wunused-variable]
   54 | static int bmp_header_written = 0;
      |            ^~~~~~~~~~~~~~~~~~

These are actually two different types of warnings, one repeated several times, the other one ([-Wunused-variable]) appears only once. Notes:

• commandline edited
• Git master
• commit bfe730ecbf94fb709928b735cf52c41e1e4d7ad3
• I suggest to compile/build with -Wall -Wunused -Wsuggest-override to find such warnings during development

FWIW, here is a part of my setup script which I'm using whenever I create/use a new branch. YMMV.

C_FLAGS_INIT="-Wall -Wunused"
CXX_FLAGS_INIT="-Wall -Wunused -Wsuggest-override"

# CXX_STANDARD:   -DCMAKE_CXX_STANDARD=20    # valid: 98, 11, 14, 17, 20, 23, 26
#                 https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html

CXX_STANDARD="-DCMAKE_CXX_STANDARD=20 -DCMAKE_CXX_EXTENSIONS=OFF"

cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug \
  -DCMAKE_C_FLAGS_INIT="$C_FLAGS_INIT" \
  -DCMAKE_CXX_FLAGS_INIT="$CXX_FLAGS_INIT" $CXX_STANDARD \
  ../..

HTH.

Implemented in autoconf and CMake.

This checks if libs and png system libraries are requested and available. If any of the checks fail, we fall back to the local version, so that version compatibilities are maintained. #612 .

Describe the bug When my video player application runs, it stutters and eventually hangs.

To Reproduce I am unable to reproduce it with the simple examples. However, I traced the problem to two functions. First, the stuttering happens in:

Fl_Gl_Wayland_Gl_Window_Driver::swap_buffers() when it calls:
wl_display_read_events(fl_wl_display()); // this stops the event loop for some seconds and then continues.

The hanging, happens eventually when calling fd_callback() in: wl_display_dispatch()

It is unclear to me if one is the reason for the other.

I commented all the Wayland code in swap_buffers() right before eglSwapBuffers and replaced wl_display_dispatch for wl_display_dispatch_pending and then I was able to play my movie without stuttering or blocking. This, of course, is not the solution as the demo programs became unresponsive to the mouse and my application would crash sometimes when leaving the main window and entering it again.

Expected behavior I expect Wayland to work as X11 does, playing my movie without stuttering or blocking.

Screenshots I don't have screenshots, but I have my application free to download and compile with just a simple runme.sh script. It takes about 20 mins to compile, thou. https://github.com/ggarra13/mrv2

FLTK Version

• Version: 1.4.0 HEAD
• Installed as package from: git b26db74dd0be8e4f4728e976144cb15e64b677a5

FLTK Configure / Build Options

include( ExternalProject )

set( FLTK_TAG master )

set( patch_cmd )

if (APPLE OR WIN32) set( wayland OFF ) set( pango OFF ) else() set( wayland ON ) # we'll leave it on, albet it is way too buggy. set( pango ON ) endif()

ExternalProject_Add( FLTK GIT_REPOSITORY "https://github.com/fltk/fltk.git" GIT_TAG ${FLTK_TAG} GIT_PROGRESS 1 PATCH_COMMAND ${patch_cmd} CMAKE_ARGS -DCMAKE_MODULE_PATH=${CMAKE_MODULE_PATH} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX} -DCMAKE_PREFIX_PATH=${CMAKE_PREFIX_PATH} -DCMAKE_C_FLAGS=${CMAKE_C_FLAGS} -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS} -DFLTK_BUILD_EXAMPLES=OFF -DFLTK_BUILD_TEST=OFF -DOPTION_BUILD_SHARED_LIBS=0 -DOPTION_USE_SYSTEM_ZLIB=0 -DOPTION_USE_SYSTEM_LIBJPEG=0 -DOPTION_USE_SYSTEM_LIBPNG=0 -DOPTION_USE_PANGO=${pango} -DOPTION_USE_WAYLAND=${wayland} )

Operating System / Platform: Linux. Ubuntu 22.04 on Wayland

Linux/Unix Runtime, if applicable:

• Wayland

Additional context Add any other context about the problem here.

I am not sure is it a bug, maybe failure by environment, but anyway it happended, so I report to here. In case of auto configured with ./autogen.sh, fltk/fltk fails to bilbuild libfltk_png.a by libz reference of MinGW64.

Configuration Summary
-------------------------------------------------------------------------
    Directories: prefix=/mingw64
                 bindir=${exec_prefix}/bin
                 datadir=${datarootdir}
                 datarootdir=${prefix}/share
                 exec_prefix=${prefix}
                 includedir=${prefix}/include
                 libdir=${exec_prefix}/lib
                 mandir=${datarootdir}/man
                 MSys docpath=/local/share/doc/fltk
Cross-compiling: no
       Graphics: GDI+
Image Libraries: JPEG=System
                 PNG=Builtin
                 ZLIB=System
    Large Files: YES
         OpenGL: YES
        Threads: YES
configure: creating ./config.status
config.status: creating makeinclude
config.status: creating fltk.list
config.status: creating fltk-config
config.status: creating fltk.spec
config.status: creating FL/Makefile
config.status: creating config.h
config.status: creating FL/fl_config.h

And build stops as ...

=== making png ===
make[1]: Entering directory '/d/Projects/fltk-origin/png'
make[1]: warning: -j4 forced in submake: resetting jobserver mode.
Compiling png.c...
Compiling pngset.c...
Compiling pngget.c...
Compiling pngrutil.c...
In file included from pngrutil.c:17:
pngpriv.h:920:4: error: #error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the note
s in pngpriv.h"
  920 | #  error ZLIB_VERNUM != PNG_ZLIB_VERNUM \
      |    ^~~~~
In file included from pngget.c:15:
pngpriv.h:920:4: error: #error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the note
s in pngpriv.h"
  920 | #  error ZLIB_VERNUM != PNG_ZLIB_VERNUM \
      |    ^~~~~
In file included from png.c:14:
pngpriv.h:920:4: error: #error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the note
s in pngpriv.h"
  920 | #  error ZLIB_VERNUM != PNG_ZLIB_VERNUM \
      |    ^~~~~
In file included from pngset.c:19:
pngpriv.h:920:4: error: #error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the note
s in pngpriv.h"
  920 | #  error ZLIB_VERNUM != PNG_ZLIB_VERNUM \
      |    ^~~~~
make[1]: *** [../makeinclude:168: pngget.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [../makeinclude:168: pngset.o] Error 1
make[1]: *** [../makeinclude:168: png.o] Error 1
make[1]: *** [../makeinclude:168: pngrutil.o] Error 1
make[1]: Leaving directory '/d/Projects/fltk-origin/png'
make: *** [Makefile:22: all] Error 1

It is OK when configuration set to built local image libraries - --enable-localjpeg --enable-localzlib --enable-localpng. I think it would be checked while configure to libz dependency with ZLIB_VERNUM and PNG_ZLIB_VERNUM exists.

As of FLTK 1.4 HEAD, fluid lacks a way to work with subwindows. All windows have to created under a function. A workaround to create a subwindow is to create a Fl_Group and change the C++ class to Fl_Window or Fl_Double_Window. However, if this class has child widgets, they all need to be positioned relative to the subwindow, making fluid display them at the top of the window, usually overlapping menus.

I am using FLTK

• 1.4 HEAD

Describe the solution you'd like One or two things. Either support subwindows natively, which would require work. Or... have a switch to make all positions below an Fl_Group with a custom C++ class be relative to the position of that Fl_Group, so the display of the widgets would look right, but in the resulting cxx file, you'd get the positions offset by the Fl_Group (ie. Fl_Window subwindow) position.

Describe alternatives you've considered See above.

I was tempted to use it, but in its current state it looks like it's mainly for just managing strdup()/free().

Also the static string_count seems scary for thread safety; I assume that's for debugging/development and wouldn't be in the final class.

The more I look at it, the more I'm thinking it should marked as a WIP.