[LV2] The UI type problem

[David Robillard]

While we're talking about spec level problems...

As most of you know, there is a lot of contention around UI types.
Mainly there are 3 aspects to this:

- Different toolkits.  Almost, but not quite, a non-issue due to Suil.

- External UI extension.  Unofficial, some like it, some hate it,
imposes on hosts, being *only* external means plugin authors have to
provide several UIs.

- Non-portable "native" types X11UI, CarbonUI, WindowsUI, etc.  Plugin
authors have to define several (possibly identical otherwise) UIs both
in code and data to support various platforms.

The second and third are the real issues.  Notice a common theme here:
plugins having to define a bunch of separate UIs for separate types
sucks.  Different platforms, external vs internal, etc.

I have a proposal that will eliminate this problem: one UI type that can
do all of these things.  Give a window  handle for embedding and other
things hosts need to do, provide a very simple command interface for
show/hide etc. for external, and allow putting a type in the structure
at runtime so the same type can work on X11, Wayland, Windows, etc.
Everybody's happy.

Something like

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 WWindow ID, GtkWidget*, etc.
} UniWidget;

takes care of the type thing.  Putting an interface here seemed like a
dumb move in the first place, so commands can go in an extension_data
struct, like

typedef struct {
    Handle* handle;  // glorified void*

    int (*show)(Handle* handle);

    int (*hide)(Handle* handle);
};

or maybe something a bit more extensible itself, like

typedef struct {
    Handle* handle;  // glorified void*

    int (*command)(Handle* handle, const char* cmd, ...);
};

Interestingly, putting the control stuff in an extension_data means
backwards compatibility with current types, e.g. a GtkUI could add this
to support external with no compatibility breakage, and no regression
for hosts/suil that embed the Gtk directly.

This is all a bit half-baked, but in short, I think we should resolve
both the external/embedded rift, and the "bunch of different UIs for
various platforms" rift, by making it possible for *one* UI to do all
these things.

-- 
dr