On Tue, Feb 22, 2011 at 7:18 AM, Fons Adriaensen <[email protected]> wrote: > On Mon, Feb 21, 2011 at 09:14:31PM -0500, Paul Davis wrote: >> On Mon, Feb 21, 2011 at 6:12 PM, Fons Adriaensen <[email protected]> wrote: >> >> > This excludes Windows (TM), but again, I couln't care less. >> >> It also excludes OS X, which despite having "X11 support" isn't really >> what you mean by "supports X11". > > You can run X11 apps in OSX. So you can have the host side of a plugin > library that is an X11 client.
it will not be able interact in a direct way with any windows created with Cocoa. > If the underlying layer is not X11 this is just the same. Every > system needs some abstraction of 'an area of the screen that is > managed as a basic unit'. In X11 that is represented by a window > ID, in other systems it will be something similar. this was actually precisely my point. but you indicated that you didn't care about anything that wasn't X11. my point was that X11 is not an appropriate "abstraction" for this purpose, whereas what you just described is. >> http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29 > > ATM it doesn't even provide network transparancy. Which means you can't > even do the equivalent of ssh -X. AFAIU, there are no plans for it to do so. Since X clients can be hosted by a rootless X server running on top of Wayland, the plan is to continue to allow X to be used when network transparency matters, thus allowing Wayland to focus on a efficiently and productively implementing a drawing/display/rendering model that doesn't make very much sense across a network (in a word: compositing). _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
