[LV2] plea to plugin UI devs

[Rui Nuno Capela]

 > 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 
"bloat" concept.

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

scnr.


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 
handle, ofc;

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

byee
-- 
rncbc aka. Rui Nuno Capela