On Fri, 21 Nov 2014 18:34:32 +
Daniel Stone wrote:
> Hi,
>
> On 21 November 2014 08:57, Pekka Paalanen wrote:
>
> > > > I agree 100%. Again, think of nesting compositors: why should our
> > compositor
> > > > behave completely different if it's nested? The more difficult we make
> > it to
Hi,
On 21 November 2014 21:11, Bill Spitzak > 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 useless.
>>
>
> You are right, it is the "stop repeating key
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,
On 11/21/2014 10:30 AM, Daniel Stone wrote:
As in the first quoted section, I think it's not really reasonable to
guard against the possibility of Mod+S taking a screenshot in the
compositor, but the client having a shortcut for Mod+S+X. So I think we
can take the easy way out of saying:
- fo
On 11/21/2014 10:30 AM, Daniel Stone wrote:
As in the first quoted section, I think it's not really reasonable to
guard against the possibility of Mod+S taking a screenshot in the
compositor, but the client having a shortcut for Mod+S+X. So I think we
can take the easy way out of saying:
- fo
Right.
On 20 November 2014 20:37, Bill Spitzak 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 keyboard
Hi,
On 21 November 2014 08:57, Pekka Paalanen wrote:
> On Thu, 20 Nov 2014 10:31:18 +0200
> Giulio Camuffo wrote:
> > 2014-11-20 10:05 GMT+02:00 Daniel Stone :
> > > On 19 November 2014 21:05, Bill Spitzak wrote:
>
> >> You also mentioned an "enter debug mode" shortcut. That must NOT send a
>
Hi,
On 20 November 2014 08:31, Giulio Camuffo wrote:
> 2014-11-20 10:05 GMT+02:00 Daniel Stone :
> > On 19 November 2014 21:05, Bill Spitzak wrote:
> >> No! Users do NOT want this. Keys take action when you push them.
> Otherwise
> >> the interface looks slow and drives users crazy.
> >
> >
> >
On Thu, 20 Nov 2014 10:31:18 +0200
Giulio Camuffo wrote:
> 2014-11-20 10:05 GMT+02:00 Daniel Stone :
> > Hi,
> >
> > On 19 November 2014 21:05, Bill Spitzak wrote:
> >>
> >> On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
> >
> > Just like Jasper said, it is a mistake to use wl_keyboard fo
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 compos
2014-11-20 10:05 GMT+02:00 Daniel Stone :
> Hi,
>
> On 19 November 2014 21:05, Bill Spitzak 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 f
Hi,
On 20 November 2014 08:05, Daniel Stone wrote:
> On 19 November 2014 21:05, Bill Spitzak 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 foc
Hi,
On 19 November 2014 21:05, Bill Spitzak 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, anyway.
>>
2014-11-19 23:31 GMT+02:00 Giulio Camuffo :
> 2014-11-19 23:05 GMT+02:00 Bill Spitzak :
>> 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
2014-11-19 23:05 GMT+02:00 Bill Spitzak :
> 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 yo
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"
On Wed, 19 Nov 2014 14:31:35 +0200
Giulio Camuffo wrote:
> 2014-11-19 13:42 GMT+02:00 Pekka Paalanen :
> > On Tue, 18 Nov 2014 18:54:04 +0200
> > Giulio Camuffo wrote:
> >
> >> 2014-11-13 13:30 GMT+02:00 Daniel Stone :
> >> > Hi,
> >> >
> >> > On Thursday, November 13, 2014, Giulio Camuffo
> >>
2014-11-19 13:42 GMT+02:00 Pekka Paalanen :
> On Tue, 18 Nov 2014 18:54:04 +0200
> Giulio Camuffo wrote:
>
>> 2014-11-13 13:30 GMT+02:00 Daniel Stone :
>> > Hi,
>> >
>> > On Thursday, November 13, 2014, Giulio Camuffo
>> > wrote:
>> >>
>> >> 2014-11-13 12:06 GMT+02:00 Daniel Stone :
>> >> > But t
On Mon, 17 Nov 2014 17:54:33 +1000
Peter Hutterer wrote:
> On Thu, Nov 13, 2014 at 10:06:27AM +, Daniel Stone wrote:
> > Hi,
> >
> > On Thursday, November 13, 2014, Giulio Camuffo
> > wrote:
> >
> > > 2014-11-13 11:18 GMT+02:00 Daniel Stone > > >:
> > > > Think about the case where pressi
On Tue, 18 Nov 2014 18:54:04 +0200
Giulio Camuffo wrote:
> 2014-11-13 13:30 GMT+02:00 Daniel Stone :
> > Hi,
> >
> > On Thursday, November 13, 2014, Giulio Camuffo
> > wrote:
> >>
> >> 2014-11-13 12:06 GMT+02:00 Daniel Stone :
> >> > But this is just a client issue, and nothing in sending the fu
On Thu, 13 Nov 2014 09:53:56 +
Daniel Stone wrote:
> Hi,
>
> On Thursday, November 13, 2014, Daniel Stone wrote:
> >
> > On 13 November 2014 07:35, Pekka Paalanen > > wrote:
> >
> >> On Wed, 12 Nov 2014 12:06:16 -0800
> >> Bill Spitzak >> > wrote:
> >> > The important point is that in bot
2014-11-13 13:30 GMT+02:00 Daniel Stone :
> Hi,
>
> On Thursday, November 13, 2014, Giulio Camuffo
> wrote:
>>
>> 2014-11-13 12:06 GMT+02:00 Daniel Stone :
>> > But this is just a client issue, and nothing in sending the full keys
>> > array
>> > precludes this working.
>> >
>> > If Alt+X is a mod
On Thu, Nov 13, 2014 at 10:06:27AM +, Daniel Stone wrote:
> Hi,
>
> On Thursday, November 13, 2014, Giulio Camuffo
> wrote:
>
> > 2014-11-13 11:18 GMT+02:00 Daniel Stone > >:
> > > Think about the case where pressing Alt on its own will focus the system
> > > menu, but pressing Alt-F will r
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 whether
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 even
On Thu, Nov 13, 2014 at 3:30 AM, Daniel Stone wrote:
> Hi,
>
> On Thursday, November 13, 2014, Giulio Camuffo
> wrote:
>
>> 2014-11-13 12:06 GMT+02:00 Daniel Stone :
>> > But this is just a client issue, and nothing in sending the full keys
>> array
>> > precludes this working.
>> >
>> > If Alt+
Hi,
On Thursday, November 13, 2014, Giulio Camuffo
wrote:
> 2014-11-13 12:06 GMT+02:00 Daniel Stone >:
> > 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. any time Alt+X is held, pressing Y triggers
>
2014-11-13 12:06 GMT+02:00 Daniel Stone :
> Hi,
>
> On Thursday, November 13, 2014, Giulio Camuffo
> wrote:
>>
>> 2014-11-13 11:18 GMT+02:00 Daniel Stone :
>> > Think about the case where pressing Alt on its own will focus the system
>> > menu, but pressing Alt-F will raise the file menu directly.
Hi,
On Thursday, November 13, 2014, Giulio Camuffo
wrote:
> 2014-11-13 11:18 GMT+02:00 Daniel Stone >:
> > Think about the case where pressing Alt on its own will focus the system
> > menu, but pressing Alt-F will raise the file menu directly. Let's say the
> > compositor has an Alt-F12 hotkey
Hi,
On Thursday, November 13, 2014, Daniel Stone wrote:
>
> On 13 November 2014 07:35, Pekka Paalanen > wrote:
>
>> On Wed, 12 Nov 2014 12:06:16 -0800
>> Bill Spitzak > > wrote:
>> > The important point is that in both your and my case the client that has
>> > just received focus sees the 'd' as
On Wed, 5 Nov 2014 20:51:53 +0200
Giulio Camuffo wrote:
> 2014-11-05 16:23 GMT+02:00 Pekka Paalanen :
> > On Tue, 7 Oct 2014 22:30:25 +0300
> > Giulio Camuffo wrote:
> >
> >> weston key bindings are supposed to eat the key events, and not pass it
> >> on to clients, and indeed the wl_keyboard.k
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 b
2014-11-05 16:23 GMT+02:00 Pekka Paalanen :
> On Tue, 7 Oct 2014 22:30:25 +0300
> Giulio Camuffo 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
On Wed, 5 Nov 2014 16:23:29 +0200
Pekka Paalanen wrote:
> On Tue, 7 Oct 2014 22:30:25 +0300
> Giulio Camuffo 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 th
On Tue, 7 Oct 2014 22:30:25 +0300
Giulio Camuffo 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
> the wl_keyboard.enter
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
2014-10-10 23:11 GMT+03:00 Bill Spitzak :
> 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,
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 thi
Oh, i didn't realize we dropped the ML. adding again.
2014-10-10 21:17 GMT+03:00 Bill Spitzak :
> 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 behaviou
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 betwee
On Wed, Oct 8, 2014 at 3:23 PM, Bill Spitzak 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 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 d
2014-10-08 21:00 GMT+03:00 Bill Spitzak :
>
>
> On 10/08/2014 01:41 AM, Giulio Camuffo wrote:
>>
>> 2014-10-08 0:50 GMT+03:00 Bill Spitzak :
>>>
>>> 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
On 10/08/2014 01:41 AM, Giulio Camuffo wrote:
2014-10-08 0:50 GMT+03:00 Bill Spitzak :
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 tes
2014-10-08 0:50 GMT+03:00 Bill Spitzak :
> 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+ta
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 do
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 k
47 matches
Mail list logo
