On 19.03.2013 22:13, Bill Spitzak wrote:
Yichao Yu wrote:
I am just wondering if those clients also don't want auto-repeat for
text input. If there is a way to turn off auto-repeat for a client,
should that also turn off the auto-repeat when the input method grab
the keyboard from the client?
Yichao Yu wrote:
I am just wondering if those clients also don't want auto-repeat for
text input. If there is a way to turn off auto-repeat for a client,
should that also turn off the auto-repeat when the input method grab
the keyboard from the client?
That is a good point, the input method ap
On 19 March 2013 16:58, Scott Moreau wrote:
> This is a good point. I think the plan here as discussed before is
> that, eventually we'll have a way for clients to request 'raw events'
> which means the compositor will hand events to the client with minimal
> or no processing (including key repeat
Hi Brenden,
On Tue, Mar 19, 2013 at 9:01 AM, Friar wrote:
> Please also consider the case of video games that are running in
> non-full-screen mode that don't WANT key auto-repeat. They should have a
> way to turn off repeated notifications. Having to wade through a ton of
> auto-repeated keybo
On Tue, Mar 19, 2013 at 11:01 AM, Friar wrote:
> Please also consider the case of video games that are running in
> non-full-screen mode that don't WANT key auto-repeat. They should have a
> way to turn off repeated notifications. Having to wade through a ton of
> auto-repeated keyboard events t
Please also consider the case of video games that are running in
non-full-screen mode that don't WANT key auto-repeat. They should have a
way to turn off repeated notifications. Having to wade through a ton of
auto-repeated keyboard events to find the actual up/down signals is likely
to cause som
On Mon, Mar 18, 2013 at 4:59 PM, Bill Spitzak wrote:
> For text, I would expect the input method is going to do the key-repeat. I
Not really, there may not be an input method, in which case the client
will get key events directly from the compositor, so the auto
repeating shouldn't depending on i
For text, I would expect the input method is going to do the key-repeat.
I can't see any way around that. So for the most common use of key
repeat it is going to be handled outside the client, and users will see
a held-down letter repeatedly insert at the same rate in all clients (or
at least a
Hi,
On 18 March 2013 01:47, Yichao Yu wrote:
> On Sun, Mar 17, 2013 at 8:51 PM, Scott Moreau wrote:>
> by wayland developers that each toolkit should implement this feature
> > if they would like to have it. My position is that the key repeat
>
> And the decision was all toolkits/programs writt
On Sun, Mar 17, 2013 at 7:47 PM, Yichao Yu wrote:
> Hi Scott,
>
> On Sun, Mar 17, 2013 at 8:51 PM, Scott Moreau wrote:
>> On Sun, Mar 17, 2013 at 5:36 PM, Yichao Yu wrote:
>>> Hi,
>>>
>>> Seems that weston uses a client side keyboard auto-repeat that is
>>> HARD-CODED in `window.c` and I haven't
Hi Scott,
On Sun, Mar 17, 2013 at 8:51 PM, Scott Moreau wrote:
> On Sun, Mar 17, 2013 at 5:36 PM, Yichao Yu wrote:
>> Hi,
>>
>> Seems that weston uses a client side keyboard auto-repeat that is
>> HARD-CODED in `window.c` and I haven't seen anywhere in wayland's
>> mentioning how this should be
On Sun, Mar 17, 2013 at 5:36 PM, Yichao Yu wrote:
> Hi,
>
> Seems that weston uses a client side keyboard auto-repeat that is
> HARD-CODED in `window.c` and I haven't seen anywhere in wayland's
> mentioning how this should be done in wayland. There doesn't seem to
> be a place where the client can
Hi,
Seems that weston uses a client side keyboard auto-repeat that is
HARD-CODED in `window.c` and I haven't seen anywhere in wayland's
mentioning how this should be done in wayland. There doesn't seem to
be a place where the client can get a recommended repeat delay and
frequency from the server
13 matches
Mail list logo
