On Wed, 2011-02-23 at 19:03 +0000, Rui Nuno Capela wrote: > On 02/23/2011 05:22 PM, David Robillard wrote: > <snip> > > > > 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"... :/
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 > 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
