4 Mar
2011
4 Mar
'11
11 p.m.
On Fri, Mar 4, 2011 at 4:45 PM, Pedro Alves <alves.ped(a)gmail.com> wrote:
On Friday 04 March 2011 19:38:28, David Robillard
wrote:
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.
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.