I feel with you... it's always bad to lose one's work.

My main concern is others loosing their work too.
FLTK has never lost info before, so this is a scar that takes a while to heal.. I think others would feel the same if we don't prevent this.

Perhaps linking in FLTK's image libs should automatically disable the GTK stuff..?

I'm not sure what the right solution is, but we can't leave a time bomb where a runtime config could cause FLTK widgets to coredump.. esp. a file chooser which will crash just before a save.

Just for curiosity: why are you building your app with the FLTK libpng in the first place?

For the usual reasons; to statically link known compatible libs to avoid missing .so/.dll errors at runtime, and/or subtle incompatibilities with runtime DLLs (such as shown here).

FTR: there has been a proposal to use "prefixing" [1] (or something like that) to rename all
lib{png|jpeg|z} symbols (function names etc.) for internal use.

Yes, I'd thought of that too, so that app code can access the static FLTK libs directly, and not the DLLs GTK uses. I suppose some tricks could be offered via inline wrapper methods so that if the actual image function is called open_PNG(), and our FLTK version is renamed open_PNG_FLTK(), one of our #include's could implement inline int open_PNG() { return open_PNG_FLTK(); } or some such so that the FLTK app code can still call open_PNG() and get the FLTK one, whereas GTK could still get the .so/.dll version.

Prefixing works by defining other names like '#define png_something fl_png_something'

I think we've already seen how macro solutions are bad for stuff like this, as macros expand /everywhere/ (recall the problems #define open(a,b) _open(a,b) caused on windows, where the macro also affected Fl_Some_Widget::open(a,b) calls), whereas inline would at least avoid that and abide by class contexts and such.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.