Re: GUI toolkit support

On Fri, Nov 16, 2018 at 1:07 PM jonetsu <[email protected]> wrote:

> On Fri, 16 Nov 2018 17:56:23 +0100
> Robin Gareus <[email protected]> wrote:
>
> > Say you write a plugin that needs ffmpeg and uses the newer
> > libswresample2 interface, and another author writes a plugin that uses
> > the older libswresample1 API. Now you dynamically link both.
>
> Just a probably very stupid question.  If plugins from a manufacturer
> are all using the same statically-linked toolkit, then would it be
> possible for that manufacturer to ship their plugins with a .so of the
> toolkit for them to use instead of having that toolkit embedded in
> every single plugin binary ?


this might or might not be possible, but it doesn't solve the problem(s).

whether gtk+2 and/or gtk+3 come with the plugin or not, you can't have them
both in the same process address space (think "program instance").

so whether or not the plugin finds a good way to provide the library to
itself or not, it won't deal with collisions between libraries inside the
host (DAW).

characteristics of an acceptable library: no static global variables,
nothing polluting the global namespace, no module loading by the library,
preferably no symbols exported other than the ones that form the library
API.

very few desktop toolkits get all this right. they were written to be the
toolkit for an *application*, not a blob of binary code that gets loaded
into an application.

_______________________________________________
Ardour-Users mailing list
[email protected]
To unsubscribe  or change your mailing preferences please visit:
http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org