On Fri, 21 Nov 2014 18:34:32 +
Daniel Stone dan...@fooishbar.org wrote:
Hi,
On 21 November 2014 08:57, Pekka Paalanen ppaala...@gmail.com wrote:
I agree 100%. Again, think of nesting compositors: why should our
compositor
behave completely different if it's nested? The more
On Thu, 20 Nov 2014 10:31:18 +0200
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-11-20 10:05 GMT+02:00 Daniel Stone dan...@fooishbar.org:
Hi,
On 19 November 2014 21:05, Bill Spitzak spit...@gmail.com wrote:
On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
Just like Jasper said,
Hi,
On 20 November 2014 08:31, Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-11-20 10:05 GMT+02:00 Daniel Stone dan...@fooishbar.org:
On 19 November 2014 21:05, Bill Spitzak spit...@gmail.com wrote:
No! Users do NOT want this. Keys take action when you push them.
Otherwise
the
Hi,
On 21 November 2014 08:57, Pekka Paalanen ppaala...@gmail.com wrote:
On Thu, 20 Nov 2014 10:31:18 +0200
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-11-20 10:05 GMT+02:00 Daniel Stone dan...@fooishbar.org:
On 19 November 2014 21:05, Bill Spitzak spit...@gmail.com wrote:
You
Right.
On 20 November 2014 20:37, Bill Spitzak spit...@gmail.com wrote:
On 11/20/2014 12:05 AM, Daniel Stone wrote:
As far as I can tell from what the others are saying - which I'd totally
agree with - is that wl_keyboard's focus would be much more transient
than it is now, reflecting where
On 11/21/2014 10:59 AM, Daniel Stone wrote:
And the other is a useless event that must be sent before the key
map changed event.
Which you respond to by ceasing _all_ actions related to your current
keyboard state, such as cancelling key repeat. So, also not useless.
You are right,
Hi,
On 21 November 2014 21:11, Bill Spitzak spit...@gmail.com
javascript:_e(%7B%7D,'cvml','spit...@gmail.com'); wrote:
On 11/21/2014 10:59 AM, Daniel Stone wrote:
Which you respond to by ceasing _all_ actions related to your current
keyboard state, such as cancelling key repeat. So, also not
Hi,
On 19 November 2014 21:05, Bill Spitzak spit...@gmail.com wrote:
On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
Just like Jasper said, it is a mistake to use wl_keyboard focus for
window focus, xdg_shell has a separate mechanism for window focus.
Window focus is a shell concept IMO,
Hi,
On 20 November 2014 08:05, Daniel Stone dan...@fooishbar.org wrote:
On 19 November 2014 21:05, Bill Spitzak spit...@gmail.com wrote:
On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
Just like Jasper said, it is a mistake to use wl_keyboard focus for
window focus, xdg_shell has a separate
2014-11-20 10:05 GMT+02:00 Daniel Stone dan...@fooishbar.org:
Hi,
On 19 November 2014 21:05, Bill Spitzak spit...@gmail.com wrote:
On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
Just like Jasper said, it is a mistake to use wl_keyboard focus for
window focus, xdg_shell has a separate
On 11/20/2014 12:05 AM, Daniel Stone wrote:
As far as I can tell from what the others are saying - which I'd totally
agree with - is that wl_keyboard's focus would be much more transient
than it is now, reflecting where keyboard events are _actually_ being
delivered _right now_. So if the
On Thu, 13 Nov 2014 09:53:56 +
Daniel Stone dan...@fooishbar.org wrote:
Hi,
On Thursday, November 13, 2014, Daniel Stone dan...@fooishbar.org wrote:
On 13 November 2014 07:35, Pekka Paalanen ppaala...@gmail.com
javascript:_e(%7B%7D,'cvml','ppaala...@gmail.com'); wrote:
On Wed,
On Tue, 18 Nov 2014 18:54:04 +0200
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-11-13 13:30 GMT+02:00 Daniel Stone dan...@fooishbar.org:
Hi,
On Thursday, November 13, 2014, Giulio Camuffo giuliocamu...@gmail.com
wrote:
2014-11-13 12:06 GMT+02:00 Daniel Stone
On Mon, 17 Nov 2014 17:54:33 +1000
Peter Hutterer peter.hutte...@who-t.net wrote:
On Thu, Nov 13, 2014 at 10:06:27AM +, Daniel Stone wrote:
Hi,
On Thursday, November 13, 2014, Giulio Camuffo giuliocamu...@gmail.com
wrote:
2014-11-13 11:18 GMT+02:00 Daniel Stone
2014-11-19 13:42 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
On Tue, 18 Nov 2014 18:54:04 +0200
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-11-13 13:30 GMT+02:00 Daniel Stone dan...@fooishbar.org:
Hi,
On Thursday, November 13, 2014, Giulio Camuffo giuliocamu...@gmail.com
On Wed, 19 Nov 2014 14:31:35 +0200
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-11-19 13:42 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
On Tue, 18 Nov 2014 18:54:04 +0200
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-11-13 13:30 GMT+02:00 Daniel Stone dan...@fooishbar.org:
On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
Just like Jasper said, it is a mistake to use wl_keyboard focus for
window focus, xdg_shell has a separate mechanism for window focus.
Window focus is a shell concept IMO, anyway.
Can you explain when (except to fix this bug) then xdg_shell focus
2014-11-19 23:05 GMT+02:00 Bill Spitzak spit...@gmail.com:
On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
Just like Jasper said, it is a mistake to use wl_keyboard focus for
window focus, xdg_shell has a separate mechanism for window focus.
Window focus is a shell concept IMO, anyway.
Can
2014-11-19 23:31 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com:
2014-11-19 23:05 GMT+02:00 Bill Spitzak spit...@gmail.com:
On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
Just like Jasper said, it is a mistake to use wl_keyboard focus for
window focus, xdg_shell has a separate mechanism for
2014-11-13 13:30 GMT+02:00 Daniel Stone dan...@fooishbar.org:
Hi,
On Thursday, November 13, 2014, Giulio Camuffo giuliocamu...@gmail.com
wrote:
2014-11-13 12:06 GMT+02:00 Daniel Stone dan...@fooishbar.org:
But this is just a client issue, and nothing in sending the full keys
array
On Thu, Nov 13, 2014 at 10:06:27AM +, Daniel Stone wrote:
Hi,
On Thursday, November 13, 2014, Giulio Camuffo giuliocamu...@gmail.com
wrote:
2014-11-13 11:18 GMT+02:00 Daniel Stone dan...@fooishbar.org
javascript:;:
Think about the case where pressing Alt on its own will focus the
Hi,
On Thursday, November 13, 2014, Daniel Stone dan...@fooishbar.org wrote:
On 13 November 2014 07:35, Pekka Paalanen ppaala...@gmail.com
javascript:_e(%7B%7D,'cvml','ppaala...@gmail.com'); wrote:
On Wed, 12 Nov 2014 12:06:16 -0800
Bill Spitzak spit...@gmail.com
2014-11-13 12:06 GMT+02:00 Daniel Stone dan...@fooishbar.org:
Hi,
On Thursday, November 13, 2014, Giulio Camuffo giuliocamu...@gmail.com
wrote:
2014-11-13 11:18 GMT+02:00 Daniel Stone dan...@fooishbar.org:
Think about the case where pressing Alt on its own will focus the system
menu, but
Hi,
On Thursday, November 13, 2014, Giulio Camuffo giuliocamu...@gmail.com
wrote:
2014-11-13 12:06 GMT+02:00 Daniel Stone dan...@fooishbar.org
javascript:;:
But this is just a client issue, and nothing in sending the full keys
array
precludes this working.
If Alt+X is a modifier (i.e.
On Thu, Nov 13, 2014 at 3:30 AM, Daniel Stone dan...@fooishbar.org wrote:
Hi,
On Thursday, November 13, 2014, Giulio Camuffo giuliocamu...@gmail.com
wrote:
2014-11-13 12:06 GMT+02:00 Daniel Stone dan...@fooishbar.org:
But this is just a client issue, and nothing in sending the full keys
On 11/13/2014 01:53 AM, Daniel Stone wrote:
wl_keyboard::enter sends the list of currently-depressed keys to the
client. If we make it a partial list, depending on context, we make it
useless. We'll send releases for keys the client never knew were down -
which is _exactly_ the problem this
On 11/13/2014 03:30 AM, Daniel Stone wrote:
But no, because, when the focus isn't switched, there is no enter
event and no keys array. The client has no idea X was pressed, so it
can't possibly trigger the binding.
So without the patch this is not consistent. Depending on
On Wed, 5 Nov 2014 20:51:53 +0200
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-11-05 16:23 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
On Tue, 7 Oct 2014 22:30:25 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
weston key bindings are supposed to eat the key events, and not
On Tue, 7 Oct 2014 22:30:25 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
weston key bindings are supposed to eat the key events, and not pass it
on to clients, and indeed the wl_keyboard.key event is not sent. But
we must also not put the key in the keys array to pass to client with
On Wed, 5 Nov 2014 16:23:29 +0200
Pekka Paalanen ppaala...@gmail.com wrote:
On Tue, 7 Oct 2014 22:30:25 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
weston key bindings are supposed to eat the key events, and not pass it
on to clients, and indeed the wl_keyboard.key event is not
2014-11-05 16:23 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
On Tue, 7 Oct 2014 22:30:25 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
weston key bindings are supposed to eat the key events, and not pass it
on to clients, and indeed the wl_keyboard.key event is not sent. But
we must
It seems like it would be easy for the client to not repeat the key if
it did not see the key-down event. I find it pretty amazing that you
duplicated about the only bug that having clients do the repeat rather
than the compositor solves.
Any patch that removes the fact that the key is still
Oh, i didn't realize we dropped the ML. adding again.
2014-10-10 21:17 GMT+03:00 Bill Spitzak spit...@gmail.com:
On 10/09/2014 11:42 PM, giuliocamu...@gmail.com wrote:
Are you proposing something else?
IsSpaceKeyDown() should always return false.
What I'm looking for here is consistent
On 10/10/2014 11:41 AM, Giulio Camuffo wrote:
Ok, so let's change the example. Space doesn't switch the active
window, but toggles the speaker mute. So hitting space will not send a
key event to the client, which will not know space is pressed, so your
nice space+x shortcut won't work.
Yes
2014-10-10 23:11 GMT+03:00 Bill Spitzak spit...@gmail.com:
On 10/10/2014 11:41 AM, Giulio Camuffo wrote:
Ok, so let's change the example. Space doesn't switch the active
window, but toggles the speaker mute. So hitting space will not send a
key event to the client, which will not know space
The client will do some kind of check to see if the space key is down. This
should resemble as much as possible a round trip to actually see if the key
is pressed on the hardware. I figured this involved peeking into the xkb
structure to see what keys are held down.
some kind of check. Making a
2014-10-08 0:50 GMT+03:00 Bill Spitzak spit...@gmail.com:
I really can't imagine this is a problem, and clients may even expect the
current behavior. It certainly is expected for shift keys: if I alt+tab to a
program it acts like alt is still held down. A quick test on Ubuntu shows
that a
On 10/08/2014 01:41 AM, Giulio Camuffo wrote:
2014-10-08 0:50 GMT+03:00 Bill Spitzak spit...@gmail.com:
I really can't imagine this is a problem, and clients may even expect the
current behavior. It certainly is expected for shift keys: if I alt+tab to a
program it acts like alt is still held
2014-10-08 21:00 GMT+03:00 Bill Spitzak spit...@gmail.com:
On 10/08/2014 01:41 AM, Giulio Camuffo wrote:
2014-10-08 0:50 GMT+03:00 Bill Spitzak spit...@gmail.com:
I really can't imagine this is a problem, and clients may even expect the
current behavior. It certainly is expected for shift
On 10/08/2014 11:58 AM, Giulio Camuffo wrote:
A key being held down on focus-in will not produce a press event, so I
don't see what the problem is.
It produces a KeyPress in xwayland.
Okay that may be a problem. So you are saying the client cannot
distinguish between keys that were held
On Wed, Oct 8, 2014 at 3:23 PM, Bill Spitzak spit...@gmail.com wrote:
On 10/08/2014 11:58 AM, Giulio Camuffo wrote:
A key being held down on focus-in will not produce a press event, so I
don't see what the problem is.
It produces a KeyPress in xwayland.
Okay that may be a problem. So
On 10/08/2014 03:25 PM, Jasper St. Pierre wrote:
I was under the impression that what the client got was an xkb state
that showed that the keys were held down. Actual events caused by
pressing keys were different and distinguishable by the client.
X clients cannot distinguish
weston key bindings are supposed to eat the key events, and not pass it
on to clients, and indeed the wl_keyboard.key event is not sent. But
we must also not put the key in the keys array to pass to client with
the wl_keyboard.enter event, or else we may send the 'eaten' one too.
In the case of a
I really can't imagine this is a problem, and clients may even expect
the current behavior. It certainly is expected for shift keys: if I
alt+tab to a program it acts like alt is still held down. A quick test
on Ubuntu shows that a program you alt+tab to gets a map with both alt
and tab held
44 matches
Mail list logo
