[LV2] plea to plugin UI devs
Rui Nuno Capela
rncbc at rncbc.org
Thu Mar 17 10:24:53 PDT 2016
> Robin Gareus wrote on Wed, 16 Mar 2016 20:21:28 +0100
> While we're at it..
> Since there are still new plugins with GTK and QT GUI popping up, and
> it's been at least 4 years since we last pointed this out, here's a
> friendly reminder:
> **Please avoid big toolkit and be careful with C++**
imnsho. this is BS!
big toolkits and c++ are not to blame here. never was, never be.
let me babble on... :)
on my "book of knowledge", JUCE is--it has been before, ever since 10y+
ago--a niche. and still is just yet another bloated toolkit for x sake.
it just happens that it does audio and VST natively; it is of no
consequence nor reason here, besides we all know that VST is simply one
terrible source of an anti-(design)pattern catalog to start with.
maybe some seem to forget--or simply ignore--that most of those
juce-based plugins are built, packaged and distributed as linked
*statically*--yes, binary bloat in its worst form, if you ask me--it
just embodies the whole and nothing but the redundant big whole of the
nevermind, whatever, move on...
otoh. gtk2/3 and qt4/5 toolkits, are, have been distributed, deployed
and available as shared resources, long time out there. you may say
they're big but they are big only once in a (system)lifetime
(Talkingheads' pun intended;))
and they are modularized: as a developer, you may well only pick the
parts you need: you need a gui? check. need some widgets and a practical
MVC pattern implementation? check. want this and that
exhaustively/perfectly documented, api-consistent framework? check. need
some networking? need some webkit? need whatever? yes, both gtk and qt
will let you choose whatever, because they are all really true, all
encompassing c++ frameworks and they often stay on top of the c++stdlib
and are cross-platform independent (at least qt is:))
unless your true wish is about hitting the VST market, which simply put
has nothing to do with LV2, not even slightly. all things being equal,
i'd say: do not go the way of JUCE for that matter--LV2UI--it's not (or
should not be) an option here. might well be a short-term solution but
not one we're trying to solve or rather brainstorm
yeah. i digress about juce, a lot and way more than gtk ;)
and let's not go the gtk2 vs. gtk3 or qt4 vs. qt5 dilemma: this is a
packaging/deployment/roll-out decision, not a developer, architect or
even a design one--the latter (gtk3, qt5) are "the future" if not
already "the present", current and mainstream
on my call (i'm a qt guy as i'm sure you probably know), all things are
already qt5 full-throttle. i may indulge on qt4 support for say over
some time but, let's get real, it's getting rusty, bit-rotten and funky
(in a smelly way) by the day now
> That being said, keep on hacking.
if "hacking" means making things work better and faster for everyone, by
all means, yes
NOW, into the topic at hand:
i'm all in favor as for he host being the one in control, that is, it is
host business to provide by request a ARGB32 raster space for the plugin
to play with--NOT the other way around.
let's think deeper, in an api/protocol sense that is:
1) the plugin requests an (opaque) resource handle, in a designated
format (argb32, width, height, for this time);
2) the host replies ok, eventually with adequate, maybe different from
requested, width and height sizes, this being the real actual host
raster space specification (the canvas).
3) the plugin may then send paint or update requests to host, passing
the resource-id handle and the argb32 data and rectangular area extents
it wants to "bitblt" over (eg. copy, mask, xor, composite, etc.), if not
splatting the whole as is (copy);
4) the host might often request the plugin to update the whole or only
some rectangular region (in a reciprocal principle as in 3). or tell
that raster space is now invalid (eg. resized) and the plugin must
"repaint" the whole, given the (eventually new) width and size. the
plugin is then obliged to an appropriate 2) reply, eventually;
5) all "paint" requests from plugin to host are about passing a argb32
data (possibly a pointer as in "by reference") and a rectangle viewport
(x, y, width, height);
6) all "hints" requests from host to plugin are about passing the
invalidated rectangle viewport (x, y, width, height), and the opaque
i know this looks like bare bones of a raw, bread and butter, raster
device driver, but isn't that the fundamental idea?
maybe i'm just a bummer
rncbc aka. Rui Nuno Capela
More information about the Devel