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. On Mon, Apr 3, 2017 at 11:56 AM, Olivier Fourdan <[email protected]> wrote: > Hi Pekka, > >> you cannot ignore a wl_registry.bind request. Did you ever try to see >> what happens? :-) > > Admittedly, I didn't go that far! > >> If you do not create a wl_resource when the protocol spec says "this >> creates a new object", then if the client ever refers to the >> non-created object, it will hopefully be automatically shot dead for >> referencing a bad object id. > > Ah right, makes sense, of course... > >> Furthermore, I think it also violates the object id allocation scheme, >> so if the client tries to create any new object after the ignored bind >> request, that would also explode. >> >> So you might just let the client out of its misery before anything more >> confusing can happen. At least you can then deliver a descriptive error >> message. ;-) > > Yeah, I'll use the global filter API, it's the intended use and really simple > to put in place :) > >> As for the protocol wording, I think it should be enough to say that >> compositors should restrict the interface to Xwayland. How they do that >> is up to them. > > Yeap, agreed > > Thanks > Olivier > _______________________________________________ > wayland-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
