On Tue, Apr 4, 2017 at 3:11 AM, Olivier Fourdan <[email protected]> wrote: > > Hi > >> I cannot see why this api cannot be correctly emulated using some >> wayland api that normal wayland clients can also use. Allowing X >> clients to have more rights and abilities than Wayland clients seems >> horrendously wrong. >> >> The X emulation does not have to do 1:1 translation of X11 calls into >> Wayland requests. >> >> In this case I would think an attempt to grab the keyboard would >> instead send an "activate" or "raise" or "needs attention" (that seems >> to be a popular name) request. The X client would then get keystrokes >> (possibly after some more user interaction such as clicking or of >> de-iconizing the client). Because the X11 app may not expect to lose >> the focus until the grab is lost, the X emulator would also re-request >> the focus if it is lost at any time it could, such as on mouse clicks >> or mouse enter events. >> >> I suppose the plan is that this does not actually do something that >> Wayland clients can't do, but in that case you are just moving "how to >> replicate what X does" from the X emulator into the compositor. That >> still seems wrong, since compositors may differ, making it impossible >> for the client to be rewritten to not use the X emulator but still >> have the same behavior. I would much rather see this done by the X >> emulator. > > Again, even though the protocol does not specifically target > override-redirect windows, those are the main problem here, sensible X11 > window managers do not "manage" those, so setting EWMH properties such as > "activate" or "demand attention" will be ignored by most X11 window managers > on O-R windows. > > I have attached a simple code sample to demonstrate this - And this is not an > hypothetical issue, this is > https://bugs.freedesktop.org/show_bug.cgi?id=96547 - This works fine on X11 > thanks to the Xserver issuing the requested grab, it cannot work on Xwayland > because Wayland has no similar mechanism. > > But if you can solve this issue reliably for all X11 window managers/Wayland > compositors in Xwayland alone without the help of any additional protocol, > best would be to send your patches for Xwayland to xorg-devel. > > Cheers, > Olivier
You seem to be thinking I am proposing some change to the client that is using XLib. I mean to change the code that you are currently proposing will construct and send this Wayland request. Obviously you are able to do that since you are modifying it right now to produce that request, and since it is Wayland it is obviously not the Xlib-using client. My best guess is that this is in the X server. The proposal is that it instead sends an "activate" or whatever to Wayland, and if it then receives a deactivate and loses the focus, it makes some concerted attempt (ie send another "activate" on the next mouse click) to get the focus back. I realize the X server is quite a mess and that it may be very difficult to do anything other than 1:1 translation of X requests to Wayland requrests, such as adding spurious extra "activate" requests, and that it is easier to do this mess in the compositor. If that is the reason then this api makes sense, but the documentation should *clearly* specify this reason. And it should say *exactly* what a Wayland client can do to get the same result, and specify that any compositor that produces a different result from this than from the Wayland client is out of spec. My main concern is that X11 clients not get special super powers that normal clients don't have. In a related note I am really scared that X11 apps are allowed to set window xy positions and Wayland clients are not. That needs to be fixed. I know our software will (if we ever stop using X11) be forced to make fudge this somehow, possibly by figuring out how to nest a Wayland window inside an X11 one. We need the ability to save/restore window layouts in text files that are portable across operating systems, so anything other than this is impossible. (in reality I expect *every* compositor will add this as an "extension" but it is pretty stupid to not define this from the start so we don't have to do compositor-specific code). _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
