10 Dec
2017
10 Dec
'17
9:27 p.m.
On 12/10/2017 08:43 PM, Gordonjcp wrote:
On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus
Seeber wrote:
You can still statically link for example with FLTK and derivatives or roll your
own. On Windows I think Steinberg even provides a GUI toolkit for VST plugins if
I remember correctly? Or go plain ImGui or plain OpenGL or whatever suits?
Maybe robin can give better recommendations since he seems to have done some work
on lv2 GUIs. (maybe see https://github.com/x42/robtk )
On 12/10/2017 03:31 PM, Paul Davis wrote:
So what would you write
it in instead?
On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber
<
markus.seeber(a)spectralbird.de> wrote:
That is exactly the problem with plugins. At the same time I'd say:
"Don't use these GUI librarys for plugins and do not load any plugin that
exports these symbols."
and be done with it, let offensive software die. In my eyes writing a plugin GUI
in GTK/Qt is very bad practice for exactly these reasons.
Just employ static linking when sensible.
unortunately, several large toolkits of
various types make this impossible
because they themselves use dynamic (runtime-driven) loading of shared
objects. GTK (and its dependency stack) is a particular offender there, but
I believe the same is true of Qt. You can't statically link against this
type of toolkit if your goal is to end up with a self-contained binary. the
g* stack has made a few improvements in this area in recent years, but
AFAIK it still isn't possible to build a self-contained binary. JUCE
differs from this, I believe.