search

mlabbe / nativefiledialog

A tiny, neat C library that portably invokes native file open and save dialogs.
zlib License
1.76k stars 209 forks source link

Working on experiment to dlopen/dlclose GTK...close, but need help #42

Closed ewmailing closed 5 years ago

ewmailing commented 6 years ago

I have an experimental fork that lazily loads the GTK libraries when you need them and dlcloses when the dialogs are closed. (There is a compile flag that can be used to switch between the traditional mode and this lazy load.)

This was done to try to solve two issues:

  1. Some people have expressed concern that loading the GTK libraries just for a one-off open or save dialog in their program is a lot of unnecessary RAM wasted. So loading & unloading the libraries as needed would solve that problem.

  2. Binary distribution across Linux distros can be tricky because not all target systems may have the exact GTK/GLIB libraries linked with the same exact SONAME (or they may not be installed at all). The lazy dlopen potentially allows us to provide a list of known GTK/GLIB names and load them on demand, so a single binary can be shipped and work. I also provide a new API that allows you to check if NFD is available on the platform (by looking to see if it can find/load the dll dependencies). Users can provide their own fallbacks (e.g. non-native file panel) if it is not available, and more importantly, their program still can launch and run even if NFD can't be used.

This experiment actually works on some Linux systems I've test on. But on some other Linux systems, the second time I try to create a file dialog, it crashes. I haven't been able to figure why some Linux distros work and others do not. I do not understand the crash either. It seems to happen on the very first gtk_* API call after I re-dlopen the libraries and reset the API function pointers. (I tried skipping gkt_initcheck on the second time and it then crashed on the next gtk API, gtk_file_chooser_dialog_new.)

Anyway, I'm kind of stuck on this last issue. So I'm hoping somebody else who may see what the final problem is so we can fix this.

You can find my experiment on the Blurrr branch with the following commit hash. https://github.com/ewmailing/nativefiledialog/commits/Blurrr 0b75e27f4e76cbfbed13bb2d991fbefeffe8aea8

Thank you

mlabbe commented 6 years ago

If I recall my work in 2013, Gtk was not designed to be loaded and unloaded in this way due to static state in the global scope.

The devel branch contains an optional Zenity implementation which puts GTK in an entirely different address space. I'd definitely like more eyes on that before merging it to master.

mlabbe commented 5 years ago

Closing; zenity is the solution for this

ell1e commented 2 years ago

Gtk was not designed to be loaded and unloaded in this way due to static state in the global scope.

Without the unloading IMHO this would still be useful (just keep the dlopen + function pointers around in a global var). Zenity may not always be around when GTK+ still might be, and the binary distribution issue remains.