[LV2] The UI type problem

[David Robillard]

On Sun, 2014-02-02 at 19:38 -0500, David Robillard wrote:
> While we're talking about spec level problems...
> 
> As most of you know, there is a lot of contention around UI types.

As is unfortunately usual, I've gotten some IRC and private mail
feedback, so I'll just rant to myself here and go down in archived
history as the lone crazy LV2 guy :P

> typedef struct {
>     /* Type, e.g. http://lv2plug.in/ns/extensions/ui/#X11UI.
>        Maybe a string here? URID avoids allocation hassle though..
>     */
>     LV2_URID type;
> 
>     void* widget;  ///< X11 Window ID, GtkWidget*, etc.
> } UniWidget;

It's occurred to me that this it not such a great idea, since it makes
one UI binary have to support only *one* type.  Maybe a better approach
is for the host to ask for a "widget" of a given type?

void* (*ui_get_widget)(LV2_URID type);

This is not an issue if you just consider X11 vs Windows vs Cocoa, but
considering multiple options on the same platform (X11/Wayland,
Carbon/Cocoa), it's trickier.  I'm not sure it's even possible for a
single UI binary to support e.g. both X11 and Wayland, but if it is, you
could do so via this interface.

Ultimately the goal here is to not force portable UIs to have to list
several UIs in their data.  Really, that was meant for different UIs at
a user level, e.g. "mixer strip sized overview" vs "full control panel",
but it's also a nuisance.  Ideally, we'd like zero non-portable stuff in
the data or API itself whatsoever.  The best practice, copied from
examples, should be as inherently portable as possible.

For the record, I have no intention of causing a compatibility mess
here.  This part, too, could be implemented as extension_data, allowing
for full backwards compatibility with widgets of whatever type (though
this would eventually make the widget vestigial, which is slightly odd)

-- 
dr