linuxaudio.org

On Wed, 2011-02-23 at 19:03 +0000, Rui Nuno Capela wrote:

quoted text
> On 02/23/2011 05:22 PM, David Robillard wrote:

>

> >

> > 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.

> >

>

> >

> > (* 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"... :/

I have no idea why this is something to :/ at...
> nice, but i figure it's a solution in a world where the host and the

quoted text
> 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

quoted text
> 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.

quoted text
>

> 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
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev