Some questions about Wayland
Juan Zhao
juan.j.zhao at linux.intel.com
Wed Apr 11 01:56:22 PDT 2012
On 04/11/2012 04:45 PM, Pekka Paalanen wrote:
> On Wed, 11 Apr 2012 10:31:53 +0200
> Renaud Hebert<renozyx at gmail.com> wrote:
>
>> Thanks for your answer, see my reply below.
>>
>> Le 11 avril 2012 10:16, Pekka Paalanen<ppaalanen at gmail.com> a écrit :
>>> On Wed, 11 Apr 2012 09:51:22 +0200
>>> Renaud Hebert<renozyx at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> In the comments on an article about "the state of Wayland" at lwn
>>>> (http://lwn.net/Articles/491237/), two interesting questions were
>>>> raised:
>>>> 1- would gridmgr (an application which place the windows into
>>>> predefined grid layouts http://nickbp.com/gridmgr/ ) work on Wayland?
>>>> 2- same question for Gromit
>>>> (http://www.home.unix-ag.org/simon/gromit/) an application which allow
>>>> you to "draw" on your screen.
>>>>
>>>> For (1), I think that this would require an extension specific to the
>>>> compositor used (Weston, KDE's planned compositor, etc).
>>> Yes, because that is a window manager's job and requires knowledge of
>>> all windows on screen. Most likely it would be implemented in the
>>> server and only controlled by a special client.
>>>
>>> In X any application can walk over your window manager and fight with
>>> it, in Wayland such is not possible and clients cannot know about other
>>> clients' windows, and not even about absolute window positions.
>>>
>>>> For (2), I don't know: I think that this would require some form of
>>>> input redirection (there would be a fullscreen transparent windows but
>>>> when not in drawing mode it shouldn't receive the mouse events) and I
>>>> don't think that Wayland has this feature?
>>> That's easy: Wayland surfaces have an input region, and that region can
>>> be empty. Only input region receives input events, regardless of (well,
>>> clipped to, really) the surface size. So you just make your maximised
>>> transparent window and set the input region to empty, and all pointer
>>> and touch events will bypass your window. When you want to draw, make
>>> that input region non-empty. You probably need another window to click
>>> at for that. ;-)
>> This seems to work nicely for the mouse events (either set the input
>> region to empty or to full screen), but what about the keyboard
>> events?
>> From Gromit's description, it use the 'pause' key to implement the
>> modal interface..
> AFAIK, we don't have arbitrary client bindable global hot keys, and I
> don't know of any plans for such. It might be a bad idea, IMHO.
Thinking a phone with camera usage, the phone may support one key to
trigger the camera application directly.
> However, a DE, or more precisely the shell (plugin) implementation in
> the server, could allow the user to bind global keys to running
> commands. Such a command could then kick gromit's Wayland client to
> start drawing. That should be easy enough, not expose any keyboard
> hijacking features, and not require any new protocol. That's how I'd
> start looking at it.
>
Yea... agree, the shell should be better place to add such feature.
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list