23 Feb
2011
23 Feb
'11
8:39 p.m.
On Wed, 2011-02-23 at 19:03 +0000, Rui Nuno Capela wrote:
On 02/23/2011 05:22 PM, David Robillard wrote:
<snip>
I have no idea why this is something to :/ at...
http://svn.drobilla.net/lad/trunk/suil/
I have not tested the Gtk-in-Qt direction yet. You're a Qt host
author. Hint, hint. I got stuck in qtractor autohell and gave up last
night.
<snip>
(* The library itself depends on no toolkits, it uses dynamically loaded
modules for all the wrapping, but this depends on packagers doing it
right)
i see. and these dlload'ed modules which do all the wrapping have these
revealing names like "libsuil_qt4_in_gtk2" and
"libsuil_gtk2_in_qt4"... :/ nice, but i figure it's a solution in a world
where the host and the
plugin are either of those 2 toolkits and only under a x11 umbrella.
what if a plugin developer wishes to do it on fltk, juce, plain xlib,
win32/64, carbon, cocoa, whatever? (lv2_external_ui already allows that
*grin*))
Yes, it allows that by shifting the burden on the plugin authors (which
is even worse than doing it to host authors), encouraging half-assed
solutions, rampant copy/paste code duplication, bugs, and a high barrier
of entry for writing a plugin UI. On top of all that, it throws out
embedding and other niceties entirely. This is why it is a poor
solution.
aha, you'll probably say there will be a plethora
of
combinations on those modules like
"libsuil_$(plugin-toolkit)_in_$(host-toolkit)"... is that it?
Yes, that is precisely the idea. It all gets implemented in one place,
and neither the host nor plugin authors have to worry about any of it.
This is the only solution where that is true. Making all the UI authors
deal with it (repeatedly, via half-assed solutions and copy paste code
duplication) is not a good solution.
People probably will start using these new toolkits, and it will Just
Work in all the host, for free, as soon as it's implemented here. This
is a Good Thing. (The same applies to a UI exposing a low level window
ID, by the way, but there is no longer any good reason to do that).
The point, that has been repeatedly missed (which is really starting to
get irritating), is that all this IMPLEMENTATION DETAIL has become just
that. The burden on you, as a host author, to worry about the "plethora
of combinations", has been removed. That burden has also been removed
from the UI authors (which is not true of the solutions you keep
championing. As for the "plethora", there simply aren't that many
toolkits, and the modules are neither large nor complicated, but
again... implementation detail. As far as you are concerned, the magic
library just works.
Suppose Fltk plugin UIs do come along. Wonderful. Implement that in
Suil, and it will just magically work in e.g. Qtractor and Ardour with
zero changes required.
In short: Problem Solved.
sorry to be such a troll:) maybe i'll shut up
now.
anyway, i'm still looking forward to this libsuil project, by all means
an excellent effort. sincerely agree that it will do a lot better than
the current lv2_gtk_ui situation.
No future tense required, there it is. Make it happen. If I had a Qt
host to test with right now, I'd make sure Gtk2-in-Qt4 actually works,
release, and that's that.
That said, I think I will just modify the SLV2 API accordingly so you
don't have to use Suil directly, so maybe wait a day (but switching
would be easy, and the sooner I have something to test with, the sooner
this problem is solved, so don't let that stop you).
-dr