On Fri, Mar 4, 2011 at 4:45 PM, Pedro Alves <alves.ped@email-addr-hidden> wrote:
> On Friday 04 March 2011 19:38:28, David Robillard wrote:
>> The plugin UI provides whatever widget it is natively implemented in.
>> The host requests whatever widget type it is natively implemented in.
>
> Why widget type/toolkit at all? If you want to abstract,
> why not abstract at a lower level? Make the plugin claim
> its written for a GL context or X or Win32 or Cocoa (or
> whatever is used on MacOS), and return the relevant context
> id. Make the host do the same thing. Make the library mix and
> match at that level (or libraries: it's not like a host
> is changing between X and Win32 at runtime), and gain
> toolkit independence.
libsuil *could* do that (if someone wrote the code for it).
but why? real hosts are not written with Xlib, they are written with
Qt, or GTK or ... for this to be useful for the host (i.e. provide
some reason to use it), its much more sensible to return an object at
the same level of abstraction as the host is already using for its own
GUI. embedding another Gtk widget into a Gtk window is a LOT easier
than embedding an X window ID, and in fact is the whole reason why
libsuil exists. you're also forgetting about the event loop part of
this - its not all about on-screen objects.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Mar 5 00:15:08 2011
This archive was generated by hypermail 2.1.8 : Sat Mar 05 2011 - 00:15:09 EET