FLTK to SDL Window?

[Alex Mayfield]

So i've been using FLTK to create the boot window of a game of mine, and I have to say that I've been incredibly impressed by it this far.  However, an offhand comment by someone else on the team got me thinking - what would be the lift involved in getting FLTK to work directly with SDL itself?  As in, reading in keyboard and mouse inputs from SDL, and then rendering windows inside of an SDL texture to blit to the screen, similar to Dear Imgui, nuklear, or Agar.  It would be really neat if FLTK to be both out-of-game and in-game UI at the same time.

I imagine that one would have to write a simple window manger for SDL, but assuming that could be done, I wonder what demands FLTK puts on a backend in order to be a viable porting target?  Does FLTK do enough of its own rendering to where a bitmap of a window could just be flushed into a texture and rendered?  Or is it more complicated than that?

To be clear, this isn't really a feature request, as I imagine it would be a pain in the neck to implement regardless.  I'm more curious about the viability - if it's a "Oh if someone put the work in it'd be possible" or if it's more "FLTK is not set up in a way that makes that possible."

Regards,

-Alex

[Manolo]

I would recommend to read this thread of fltk.coredev about SDL/FLTK :

   https://groups.google.com/g/fltkcoredev/c/A9_IpVlXVio

[Matthias Melcher]

Code exists to render all FLTK graphics to an RGB buffer without using any system calls. It's software implementation of line drawing, text, polygon filling, and clipping. It's pretty much what Nano and Pico were supposed to be. This may be a good solution to render into a texture.

[Matthias Melcher]

We have decided to remove unfinished drivers and experimental code from the FLTK 1.4.0 release. This includes the current SDL code, so unfortunately you will be stuck with older versions (1.4.0 until yesterday) for the time being. There will be an experimental branch, probably on my repo (MatthiasWM) at GitHub, but when I do get the time to go back to SDL/Android/Nano/Pico, there will be some major changes in code. I expect that then then rendering to RGB buffers can be implemented easily.