FLTK 1.5 and SDL3

[melcher....@googlemail.com]

FLTK 1.5 will get an external SDL3 driver that can replace the internal native drivers. This will allow FLTK apps to run on iOS and Android devices without changes to the application source code.

SDL is a cross platform library that provides a way to draw onto the screen (mobile) or into windows (desktop) and receive unified events, independent of the underlying operating system. It's the go-to cross platform library for game and emulator developers. It supports a countless number of operating systems, CPUs, and graphics APIs.

 So, yes, it runs under Wayland just like any other user app, but it does not communicate with Wayland in particular. SDL typically runs in a single window, it always runs full-screen in a single window on mobile platforms. FLTK/SDL will come with its own little window system, so the user can create a popup dialog, for example, even though an Android/iOS device typically has no window system or desktop.

ggar...@gmail.com schrieb am Donnerstag, 27. Februar 2025 um 07:07:30 UTC+1:

Will SDL3 support allow FLTK to use Wayland in some way.  To me that's 
the biggest and only feature I am looking for 1.5+. 

 

On Linux, FLTK already supports Wayland via the Wayland driver since 1.4 . I have not decided yet if FLTK/SDL will support multiple SDL windows. For the start, I will target mobile devices. If there is demand (SDL based games and emulators could use an FLTK window for settings and dialogs), support for multiple SDL windows could be added later.

 - Matthias

[Gonzalo Garramuño]

On 2/27/2025 5:35 AM, 'melcher....@googlemail.com' via fltk.coredev wrote:

ggar...@gmail.com schrieb am Donnerstag, 27. Februar 2025 um 07:07:30 UTC+1:

Will SDL3 support allow FLTK to use Wayland in some way.  To me that's 
the biggest and only feature I am looking for 1.5+. 

 

Sorry.  I did not get enough sleep.  I meant Vulkan not Wayland.

Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Le jeudi 27 février 2025 à 09:35:52 UTC+1, melcher....@googlemail.com a écrit :

FLTK 1.5 will get an external SDL3 driver that can replace the internal native drivers.

Matthias: what would be an external driver? Would that be different from an additional

set of platform-specific FLTK driver classes (Fl_SDL_Window_Driver, Fl_SDL_Screen_Driver,

Fl_SDL_Graphics_Driver, Fl_SDL_Image_Surface_Driver, Fl_SDL_Gl_Window_Driver,

Fl_SDL_System_Driver) like the Wayland set which was added to FLTK 1.4?

[Albrecht Schlosser]

I think what he meant was that this driver might be in a separate repository to make the normal FLTK distribution independent of the SDL, Android, and maybe IOS stuff. We talked about this and the fact that having to maintain Android specific code had been a problem when we had the "old Android" support with all the pico, SDL, and Android stuff in the same, i.e. in our main FLTK repository.

IMHO this new repository should not become a "real fork" of our main repository but something that can be maintained separately. I imagine that there will be a new branch and that the FLTK `master` branch will be merged from time to time, whenever the "SDL repository" needs an update, or the "SDL branch" will be rebased as needed after pulling in the "upstream" changes. Or something like that, details need to be specified in the future.

[melcher....@googlemail.com]

Manolo schrieb am Freitag, 28. Februar 2025 um 13:13:32 UTC+1:

Matthias: what would be an external driver? Would that be different from an additional

set of platform-specific FLTK driver classes (Fl_SDL_Window_Driver, Fl_SDL_Screen_Driver,

Fl_SDL_Graphics_Driver, Fl_SDL_Image_Surface_Driver, Fl_SDL_Gl_Window_Driver,

Fl_SDL_System_Driver) like the Wayland set which was added to FLTK 1.4?

 

No, it's the same idea, only it is not a built-in driver, but statically linked at compile time. Plus Android needs a Java wrapper and weird linking that has no place in the FLTK repo.

I talked with Albrecht about maintainability. When I was out sick for years, a half baked SDL driver held the active developers back and wasted their time. To avoid this in the future, I want to look into the possibility to link a driver set via an external library. FLTK would get something like a NULL driver, basically a driver set that does nothing useful, but also does not crash. Then any set of drivers can be added by statically linking with a driver library that can be developed separately without interfering with core development.

I imagine it would be possible to have something standardized that mirrors the OpenGL API to allow other 3rd party renderers like Vulkan or Direct3D.

> Gonzalo Garramuño wrote:

> Sorry.  I did not get enough sleep.  I meant Vulkan not Wayland.

To get back to the OP: SDL can be compiled to run with Vulkan. This is kind of backwards, but as the SDL code stands, this would allow Vulkan rendering in any FLTK window or probably more common: Vulkan rendering full screen and FLTK rendering as an overlay.

[Gonzalo Garramuño]

On 2/28/2025 11:04 AM, 'melcher....@googlemail.com' via fltk.coredev wrote:
>
> To get back to the OP: SDL can be compiled to run with Vulkan. This is
> kind of backwards, but as the SDL code stands, this would allow Vulkan
> rendering in any FLTK window or probably more common: Vulkan rendering
> full screen and FLTK rendering as an overlay.

I have made a lot of progress with my Vulkan driver and, if you guys
will accept it, I'll add a pull request probably next month or so.

--
Gonzalo Garramuño
ggar...@gmail.com

[melcher....@googlemail.com]

Yes, that would be great. I can't promise anything though.

One of the biggest issues right now is maintainability. After all, the main reason we don't have SDL2 support was me being absent due to health issues, and with the tiny team we are, nobody was able to take one the project. So we will try to keep new drivers separate from the FLTK core from now on as much as possible, and try to modularize new major features.

I am currently testing a new CMake variable, FLTK_BACKEND_EXTERNAL and FLTK_BACKEND_PATH that is supposed to disable all internal drivers and instead link the direvers given by the path. As usual, this is much more complex than anticipated, but I feel like I am getting somewhere.

Also, if we want to add more libraries, like we did with fltk-images, fltk-gl, etc., we should also do that in an external library.

Is your Vulcan patch a complete graphics driver backend, or is it a a single (sub)window, like the Fl_GL_Window?

[Mo_Al_]

I also like the idea of a null driver and the ability to plug external drivers to it. The emscripten driver code requires some intrusive changes to FLTK's CMake script, some modifications to FLTK's sources, in addition to requiring internal headers which are not part of the public api.

[melcher....@googlemail.com]

I am very much hoping to have Emscripten as a full fledged driver option. That would be awesome!

So between the three of us, maybe we can find a way to get this driver interface working well enough for all three projects. The intention of the whole driver setup was just that, but the original pre 1.4 structure of FLTK did not allow a full separation of drivers and core. Now with 1.5, we can break ABI and modify the API, so this is the time!

My task list currently is:

- (week 14) add FLTK_BACKEND_EXTERNAL and FLTK_BACKEND_PATH for at least macOS, other platforms to follow

- (week 15 (traveling)) create a minimal driver (that does nothing) in an external git repo that links into FLTK with those settings

- (week 16) remove all interferences with the FLTK core

- (week 16) allow external drivers to integrate core drives

- (week 17) write RGB graphics driver

- (week 18) adapt to SDL3

If you guys are interested, I can share the progress with write permission. My changes will be visible in any case in my GitHub repo.

[Gonzalo Garramuño]

El 1/4/25 a las 19:00, 'melcher....@googlemail.com' via fltk.coredev
escribió:

>
> Is your Vulcan patch a complete graphics driver backend, or is it a a
> single (sub)window, like the Fl_GL_Window?

It is three things.  It is a modification to the CMakeLists.txt file to
add FLTK_USE_VK=ON like FLTK_USE_GL (code is almost identical in the
CMakeLists.txt GL path, as Albrecht's code was really easy to follow).

There's also Fl_Vk_Window and Fl_Vk_Window_Driver that handles the usual
vulkan chores (swapping buffers, create commands for drawing, add
optional depth and stencil map).  Finallly there's drivers for each
platform to create the surfaces for each platform -- macOS, X11, Wayland
and Win32.

My code would not benefit from a null driver I think.  It seems to me it
would make things harder.

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/2/25 15:12 Gonzalo Garramuño wrote:
>
> El 1/4/25 a las 19:00, 'melcher....@googlemail.com' via fltk.coredev
> escribió:
>>
>> Is your Vulcan patch a complete graphics driver backend, or is it a a
>> single (sub)window, like the Fl_GL_Window?
>
> It is three things.  It is a modification to the CMakeLists.txt file
> to add FLTK_USE_VK=ON like FLTK_USE_GL (code is almost identical in
> the CMakeLists.txt GL path, as Albrecht's code was really easy to follow).

I'm glad you say that, but that's not all my code. The initial CMake
code was from someone else, then "adopted" by me, and with additions
from Manolo and Matthias.

> There's also Fl_Vk_Window and Fl_Vk_Window_Driver that handles the
> usual vulkan chores (swapping buffers, create commands for drawing,
> add optional depth and stencil map).  Finallly there's drivers for
> each platform to create the surfaces for each platform -- macOS, X11,
> Wayland and Win32.
>
> My code would not benefit from a null driver I think.  It seems to me
> it would make things harder.

The null driver wouldn't be for your code to benefit from, as far as I
understand it. It would be something comparable to an empty (abstract)
base class all other drivers can be derived from, where the abstract
class defines the interface for other classes. Its intention would be to
improve - or enable in the first place - driver maintainability of the
FLTK library. Once the null driver exists, its interface can be used to
build other drivers on it.

Matthias, is this how you plan to design it? Can you elaborate if I'm wrong?

[melcher....@googlemail.com]

Albrecht-S schrieb am Donnerstag, 3. April 2025 um 00:33:48 UTC+2:

The null driver wouldn't be for your code to benefit from, as far as I
understand it. It would be something comparable to an empty (abstract)
base class all other drivers can be derived from, where the abstract
class defines the interface for other classes. Its intention would be to
improve - or enable in the first place - driver maintainability of the
FLTK library. Once the null driver exists, its interface can be used to
build other drivers on it.

Matthias, is this how you plan to design it? Can you elaborate if I'm wrong? 

Yes, that is correct. I am still in the trying-out phase. CMake is so capable, but also so complex that I keep maneuvering myself into dead ends. Gonzalo, I am hopeful that your PR will actually help me to find the dividing line between core, driver, and external driver. Again, this is not meant to cause (much) additional work for you, but to keep the core safe if or when a developer can no longer maintain a driver, and no other developer can take over ;-) 

The null driver is really just a base that would allow FLTK to compile with no driver code linked in at all. It's just another name for a driver base class that is self sufficient. Your Vk driver is probably building on that already anyway.

 - Matthias

 

[Albrecht Schlosser]

On 4/3/25 13:55 schrieb 'melcher....@googlemail.com' via fltk.coredev wrote:

Albrecht-S schrieb am Donnerstag, 3. April 2025 um 00:33:48 UTC+2:

The null driver wouldn't be for your code to benefit from, as far as I
understand it. It would be something comparable to an empty (abstract)
base class all other drivers can be derived from, where the abstract
class defines the interface for other classes. Its intention would be to
improve - or enable in the first place - driver maintainability of the
FLTK library. Once the null driver exists, its interface can be used to
build other drivers on it.

Matthias, is this how you plan to design it? Can you elaborate if I'm wrong? 

Yes, that is correct.

Thanks for confirmation.

I am still in the trying-out phase. CMake is so capable, but also so complex that I keep maneuvering myself into dead ends.

Please let me know by private mail if I can help, or let's have a phone call ...

Gonzalo, I am hopeful that your PR will actually help me to find the dividing line between core, driver, and external driver.

Gonzalo, I suggest to put your code in a branch of your FLTK fork and let us know about it. We can pull and test it even if you don't make a PR. Technically this PR couldn't be merged because it would provide code on a code base that's subject to be changed (add the null driver etc.) but your code in your fork would help to see what we (and particularly Matthias) need(s) to do.

Again, this is not meant to cause (much) additional work for you, but to keep the core safe if or when a developer can no longer maintain a driver, and no other developer can take over ;-)

Yep, I agree, but one of the main reasons is IMHO to simplify core code management w/o having to take care of (a lot of) optional future drivers. The maintenance of "external" drivers would - in my imagination - be done in separate repos. I imagine that such a repo would *include* the FLTK core by a mechanism like CMake's `FetchContent` so you can keep the FLTK core on a specific commit and change this reference only after the driver code has been adjusted to match potential changes in the FLTK core. Hence the responsibility of changes in each driver would be on the driver maintainer and not the core maintainers.

Example: if we decided to add new virtual methods to the core (null) driver, or if we added or changed parameters of virtual methods, then external drivers might need to be adjusted. In such a case each driver could be modified individually and the new core version (git commit/hash) would be changed (in `FetchContent` ) so the driver works on the modified FLTK core. As long as this adaptation has not been done the driver still works with the older FLTK core version (commit/hash).

Note: This is how I *imagine* how this could be done. We need to work out such a scheme to work with.

The null driver is really just a base that would allow FLTK to compile with no driver code linked in at all. It's just another name for a driver base class that is self sufficient. Your Vk driver is probably building on that already anyway.

I imagine that having the null driver in place would even simplify maintaining new drivers because each driver would be isolated from the core code. Once the null driver exists, we'd have a clear and documented interface to build a driver on.