<br><br><div class="gmail_quote">On Mon, Feb 20, 2012 at 2:56 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On 02/19/2012 03:08 PM, Daniel Stone wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi,<br> There's already a Wayland session that runs on X, and as you asked<br> for, an X server that runs rootless on Wayland, with full and proper<br> integration with a Wayland session. Hope this satisfies you.<br> </blockquote> <br></div> The "Wayland session that runs on X" is, I believe, more like "a Wayland desktop inside an X window" and is *not* what he is asking for.<br> <br> I think he wants to see each window created by the Wayland program making a different X window that is completely filled by the contents of the Wayland window.<br> <br> So far it appears that toolkits like Qt are being written to internally switch between Wayland and Xlib, to provide this for him. This is probably the best solution.<br> <br></blockquote><div><br> I am asking for the ability to display a wayland app to an X server. My original suggestion was perhaps can be done via a runtime loadable client side driver that would support the wayland client API, there would be drivers for rendering from a wayland client to a wayland session and to an wayland client to an X session and they can be selected at runtime, and the selected one loaded into the wayland application. The wayland client driver for X client connection to X server could be glue code between wayland APi and Xlib.<br> <br>the qt and gtk based methods are not sufficient as there will be other applications with custom widgets which will not provide such switching. So we cannot rely on that, the support needs to be in some optional module that can be loaded into wayland. I specifically mentioned in my original message that counting on widgets and applications to implement the functionality is not sufficient, there are more than enough lazy and sloppy programmers who wont do it. <br> <br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> There could be a Wayland compositor that actually "composites" the windows into X windows, which I think matches most closely what is being asked for. There are serious problems however. In particular the window borders are drawn by the client. Stripping them off and providing enough information for the X server to draw new ones would require all the crap that is in X now for clients to communicate information to the server, and would break any new and clever uses of the window borders. Displaying them as borderless windows would also work but may make some X desktops act strange. Double window borders may be somewhat acceptable, or an api from the compositor saying "no window border is needed" similar to what is needed for fullscreen. Stacking issues due to X window managers raising on click and the inability to outwit this without sending a limited set of rules through "transient for" hints is also going to be a big pain, but it might not break clients that consist of only one window and popup menus.<br> <br></blockquote><div><br>You probably can best speak for what is the best solution. If this compositor idea is better than my idea for runtime selectable client side driver in wayland clients, than the compositor idea is what it should be. The double window borders would be tolerable for the benefit of being able to display a future flood of wayland apps into our X sessions, and over my SSH connections. <br> <br>Most window managers work fine with apps that request border less windows, i know several X clients that do this, like xmms. <br><br>Another thing that might be useful is you can display an X client into a window created by another X Client. A big window can be created on an X server, and then any X client can be displayed inside of it. By default the subwindows won't be managed by the window manager of the root window (window managers only manage one level) (though, some window managers allow you to tell it to manage the subwindows in a window other than the root window, not the root window, one is ctwm and its -w option). Also the X system has Xreparentwindow which allows windows to be moved between parent windows. <br> <br>One big window on the X server could be created for wayland apps and the wayland apps displayed into there. The utility that allows a wayland app to be displayed to an X server over an X client connection could have a -w option which would give the window id to display to as well as the -display option for address and port.<br> <br>as far as the stacking, it went a little over my head. I guess you are talking about coordination of the application stacking on the X server and the wayland server, and how the stacking models generate expose events. I suppose that the wayland server requests pixmaps for newly exposed areas from applications and manages the stacking logic and so on, if thats in a non-runtime replaceable part of the wayland server, i can see it could be a mess to work around this. Plus, the stacking would be different on the X server than on the wayland server due to X applications beingf present on teh X server but not on the wayland server. It makes one think about making a custom wayland server just for wayland client->xserver by ripping out the wayland servers stack management and expose code and just wiring X expose events straight to wayland clients.<br> <br>With my idea of putting a runtime loadable driver into the wayland client, with an xclient connection from the wayland client to an x server, the X server would send Expose events, over x11 protocol, to the xlib in the wayland client, glue code would handle the event and just get the necessary data from the wayland application itself through the wayland API. If wayland client libraries are dynamically linked it may be possible to easily swap different versions of the library at runtime.<br> <br>That idea would probably utilise some type or runtime loading and dynamic linking. <br><br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> In general I think it would be really ugly if all the mistakes of X have to be replicated in the Wayland api just to communicate this information. So I think the proper answer is "no, it is not going to support this perfectly, but there will be compositors that will try." Please do not add crap to the Wayland API just to match X!<div class="HOEnZb"> <div class="h5"><br></div></div></blockquote><div><br><br><br>I am not asking for this, There must be a way to make this wayland to x bridge without any of this. <br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class="HOEnZb"><div class="h5"> ______________________________<u></u>_________________<br> wayland-devel mailing list<br> <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br> </div></div></blockquote></div><br>