FLTK, embedded python and SWIG

37 views
Skip to first unread message

Gonzalo Garramuño

unread,
Oct 3, 2023, 5:14:25 PM10/3/23
to fltkg...@googlegroups.com
This is a question more to the FLTK SWIG maintainers, but since here we
have several people familiar with binding FLTK to other languages, I
thought I would ask here first.

My viewer application embeds a Python interpreter (through a static
library for now).  I would like to, when they are ready, import the FLTK
1.4 python bindings onto it, so that FLTK windows can be created by the
user.  Since my viewer already has an application loop displaying the
video, I would like the FLTK python bindings to not bring in all of FLTK
once again, but use my application's embedded FLTK functions.

I am wondering how to make this work.  I think that I would have to bind
FLTK dynamically as a DSO in both the SWIG FLTK and in my embedded
python (making sure they are the same version).  I looked at the SWIG
bindings for FLTK and the make system was particularly cumbersome, but I
would be willing to contribute a CMake build system to it, so that I can
make sure I am binding to the same python version.

Any thoughts or experience on having done this?

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

Matthias Melcher

unread,
Oct 3, 2023, 6:42:26 PM10/3/23
to fltk.general
It's very important that you link FLTK only once because there can be only one event queue and one main loop. All windows create by the "other" FLTK would show (depending on the OS), but never be updated.

But it's easy. If you link with the static SWIG generated library, then you automatically also link with FLTK, because (as far as I remember), SWIG includes the target library. I believe the same is true for dynamic linking. I personally would always prefer static linking for easy distribution. 

Having a sample CMake file sure would be nice.

On another note:

The SWIG approach is great for its initial idea that SWIG is configured once, and can then create interfaces for quite a bunch of languages (https://www.swig.org/compat.html#SupportedLanguages). Do you know if the pyFLTK SWIG file can actually do that? FLTK with Go would be nice. 

Gonzalo Garramuño

unread,
Oct 3, 2023, 9:21:15 PM10/3/23
to fltkg...@googlegroups.com

El 3/10/23 a las 19:42, 'Matthias Melcher' via fltk.general escribió:
I got it working on Linux for the time being.  Here are the gotchas:

- You cannot link against pyFLTK with the static FLTK libraries in it as
pyFLTK is a DSO that gets loaded on demand by python (or in my case, the
embedded python).
- You have to link everything dynamically and then it works and I can
have my viewer and python creating windows and buttons like there's no
tomorrow even while playing the video.
- The pyFLTK build system is surprisingly good.  It found where my
python and FLTK were properly (not the system ones mind you) without
setting any variables.  I didn't investigate exactly how it happens.
- The pyFLTK installing however sucks as it installs the python .so in
site-packages/ but with a long prefix directory which makes it
impossible to find or script properly.  Need to investigate if the
setup.py script can take some flags.
- The pyFLTK startup code is somewhat broken.  It changed all my color
settings on opening a window, going to its default color scheme.


Regarding using multiple languages with swig .i files yes it can be done
with conditionals, but it can get rather messy quickly. You are better
creating .i files for each language.


--

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

Matthias Melcher

unread,
Oct 4, 2023, 12:07:12 PM10/4/23
to fltk.general
ggar...@gmail.com schrieb am Mittwoch, 4. Oktober 2023 um 03:21:15 UTC+2:
I got it working on Linux for the time being.  Here are the gotchas:

- You cannot link against pyFLTK with the static FLTK libraries in it as
pyFLTK is a DSO that gets loaded on demand by python (or in my case, the
embedded python).

Yes, SWIG itself generates a DSO, but you can also generate a static library using the same object files. Simply change the flag at the link stage to make a static library instead of a dynamically linked one. Since you said you embed the Python interpreter, you can use this code to make statically linked pyFLTK known to Python:

  PyImport_AppendInittab("fltk", PyInit_fltk); // or however SWIG names its PyObject

  Py_Initialize();

  PyRun_SimpleString("from fltk import *\n...");

  Py_Finalize();


- You have to link everything dynamically and then it works and I can
have my viewer and python creating windows and buttons like there's no
tomorrow even while playing the video.

Nice!
 
- The pyFLTK build system is surprisingly good.  It found where my
python and FLTK were properly (not the system ones mind you) without
setting any variables.  I didn't investigate exactly how it happens.
- The pyFLTK installing however sucks as it installs the python .so in
site-packages/ but with a long prefix directory which makes it
impossible to find or script properly.  Need to investigate if the
setup.py script can take some flags.

If you distribute the DSO with your binary, it can simply be in the same directory as the executable IIRC. This of course makes pyFLTK available only to your own app, but not any other app.
 
- The pyFLTK startup code is somewhat broken.  It changed all my color
settings on opening a window, going to its default color scheme.

Hmm, might be that Fl_Window::show() and Fl_Window::show(args, argv) were mixed up?!
 
Regarding using multiple languages with swig .i files yes it can be done
with conditionals, but it can get rather messy quickly. You are better
creating .i files for each language.

Ouch.

I do have Python binding code that does not depend on SWIG and caters to some of FLTKs quirks. It's full of macros though, so not necessarily less messy, and I don't want to build a competition to pyFLTK either.  

 - Matthias
Reply all
Reply to author
Forward
0 new messages