On Mon, Nov 4, 2013 at 4:44 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>> The only difference I understand between the active state and having
>> the keyboard focus is that a keyboard grab may take away the focus but
>> should not deactivate the window.
>
>
> Grabs don't change the keyboar
On Mon, Nov 4, 2013 at 3:41 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>> As Bill mentioned in a follow-up, drag sources would want to not activate.
>
>
>> This can be handled more simply than described above, without a
>> special "activate" system. I assume "activation" applies to a windo
Gregory Merchan wrote:
The only difference I understand between the active state and having
the keyboard focus is that a keyboard grab may take away the focus but
should not deactivate the window.
Grabs don't change the keyboard focus. Instead the client that did the
grab knows it has the key
Gregory Merchan wrote:
The beginning of a drag is not the only event which a client may deem
inappropriate for activation. A client, such as a drawing program,
with a free-floating palette would want for its primary window to
remain active when toggle buttons on the palette are clicked. A more
c
Jason Ekstrand wrote:
Here is the problem. Say you have two pointers P and Q and two and two
windows A and B. P clicks on A and A a is now active. Q clicks on B
and now B is active. Then P goes and clicks on B. However, B is
already active so it doesn't request an activation and A stays a
Jasper St. Pierre wrote:
But serials are seat-specific, so we need the "activate" request to
relay the seat back for the purposes of validating the timestamp. I
don't think it makes sense to expose the active window on wl_seat, though.
That is annoying. Is there any reason this is a requireme
Jason Ekstrand wrote:
1) Will we ever need a deactivate request? Under the given scheme, no
need comes immediately to mind.
I'm thinking this may be what clients want to do instead of "lower" when
a middle-mouse button in clicked on a window border (if you wish to act
like a lot of X window
Gregory Merchan wrote:
As Bill mentioned in a follow-up, drag sources would want to not activate.
This can be handled more simply than described above, without a
special "activate" system. I assume "activation" applies to a window,
not a client.
I believe you are describing the system I was
Hi Axel,
I agree with the clock comments, in that we need to know which clock to
use, and 32 bits may be too short. If we follow struct timespec,
uint32_t seconds + uint32_t nanoseconds should be fine. We don't have
64-bit integers in the protocol.
How about adding an event which tells the client
I know that people have been compiling both Wayland libraries and
Chromium for different architectures, which gives a closer idea whether
Ozone-Wayland would work or not:
https://code.google.com/p/chromium/wiki/LinuxChromiumArm
http://qt-project.org/wiki/RaspberryPi
http://lists.freede
Otherwise the outputs are removed when they have already
been freed. However don't clean up the debug listeners in gl_renderer
as these would be cleaned up by the compositor previously.
---
src/compositor-drm.c | 4 ++--
src/compositor-rdp.c | 2 +-
src/compositor-rpi.c | 4 ++--
src/c
11 matches
Mail list logo
