Re: [LAD] Specification issues in open systems

"Chris Williams" <yikyak@email-addr-hidden> writes:
> Paul Davis wrote:
>> The biggest obstacle of all was the still-unsolved issue
>> of GUI toolkit compatibility.

[snip]

> LV2 seeks to solve this via the extension mechanism. This
> is one of the areas I'm really not happy about, especially
> the current (admittedly tentative) extension mandating not
> only a gui toolkit (gtk), but also the idea that the plugin
> should implement the Widget interface while the host should
> already be running the gtk main loop. Ouch. The problem
> with the extensibility argument is that no host is going to
> implement it fully, properly or consistently (as mentioned,
> it's hard enough for this to happen with a tightly-defined,
> compact spec) which leaves client developers still not
> knowing what they are dealing with.
>
> DSSI, IMO, *attempted* to get this right. Implicit in the
> DSSI spec is an acknowledgment that a plugin spec can't be
> in the business of mandating gui solutions on a platform
> with many to choose from, so they tried to find a way
> around it using a remote gui which communicates with the
> host via OSC. I'm not sure this is entirely correct,
> either, but it's at least "more right" than several other
> ways of doing it (*cough* LV2), especially the central idea
> of trying to abstract the gui away from the architecture.

AFAIK it is perfectly possible to implement LV2 UI extension that
handles GUIs in DSSI way, i.e. through OSC. This is probably the best
approach if plugin author wants single custom GUI that works for most
hosts. The fact that only GTK variant is defined, is caused by the fact
that all currently involved parties tend to like GTK and use it in their
hosts/plugins. I'm one of them, but I like generated UI's more, one of
the reasons I've started dynparam extension work some time ago.

So, if one wants custom GUI, options are:
 * Write one GUI per toolkit
 * Write single out-of-process GUI and route it through OSC, DSSI-like,
   or some other IPC mechanism.
 * Use low level X protocol, if possible at all - see Fons Adriaensen's
   followup mail.

If you want single GUI that could work in any host, the additional
option is generating it through some UI description mechanism, with
dynparams extension being one that I use.

As a side note, I think Lars Luthman made some time ago a research into
hosting QT plugins in GTK host or vice versa, but I'm not sure what the
result was.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev