Hello,
Digging back on this.
Peter Hutterer, le lun. 08 déc. 2014 16:05:56 +1000, a ecrit:
> Some devices don't rely on keycodes + xkb layout but rather send a specific
> keysym (or multiple) in response to physical button presses. This is the case
> for chorded keyboards for example.
>
> This a
On Sat, Feb 09, 2019 at 12:13:39PM +0100, Samuel Thibault wrote:
> Hello,
>
> Digging back on this.
>
> Peter Hutterer, le lun. 08 déc. 2014 16:05:56 +1000, a ecrit:
> > Some devices don't rely on keycodes + xkb layout but rather send a specific
> > keysym (or multiple) in response to physical bu
You bring this up every single time somebody mentions keyboard input, and
every single time we explain in excruciating detail exactly how you're
wrong, why you're wrong, and why the use cases you cite are broken work
perfectly today.
Please stop bringing it up. This is your second warning.
On Tue
On 12/09/2014 12:48 AM, Hans de Goede wrote:
No this is about input-method like functionality.
Okay, in that case I think the api should be designed such that a text
editor gets the UTF-8 to insert in *exactly* the same way whether the
language is English or Chinese or Russian and whether or
Hi,
On 09-12-14 03:49, Bill Spitzak wrote:
On 12/08/2014 06:37 PM, Peter Hutterer wrote:
On Mon, Dec 08, 2014 at 11:03:58AM -0800, Bill Spitzak wrote:
Shouldn't this use the same api as the input methods, since it is in fact an
input method?
please explain
Never mind, I think this is not
On 12/08/2014 06:59 PM, Peter Hutterer wrote:
On Mon, Dec 08, 2014 at 06:49:37PM -0800, Bill Spitzak wrote:
On 12/08/2014 06:37 PM, Peter Hutterer wrote:
On Mon, Dec 08, 2014 at 11:03:58AM -0800, Bill Spitzak wrote:
Shouldn't this use the same api as the input methods, since it is in fact
On Mon, Dec 08, 2014 at 06:49:37PM -0800, Bill Spitzak wrote:
>
>
> On 12/08/2014 06:37 PM, Peter Hutterer wrote:
> >On Mon, Dec 08, 2014 at 11:03:58AM -0800, Bill Spitzak wrote:
> >>Shouldn't this use the same api as the input methods, since it is in fact an
> >>input method?
> >
> >please expla
On 12/08/2014 06:37 PM, Peter Hutterer wrote:
On Mon, Dec 08, 2014 at 11:03:58AM -0800, Bill Spitzak wrote:
Shouldn't this use the same api as the input methods, since it is in fact an
input method?
please explain
Never mind, I think this is not talking about text input, but about
using U
On Mon, Dec 08, 2014 at 11:03:58AM -0800, Bill Spitzak wrote:
> Shouldn't this use the same api as the input methods, since it is in fact an
> input method?
please explain
> On 12/07/2014 10:05 PM, Peter Hutterer wrote:
> >Some devices don't rely on keycodes + xkb layout but rather send a specif
Shouldn't this use the same api as the input methods, since it is in
fact an input method?
On 12/07/2014 10:05 PM, Peter Hutterer wrote:
Some devices don't rely on keycodes + xkb layout but rather send a specific
keysym (or multiple) in response to physical button presses. This is the case
for
Some devices don't rely on keycodes + xkb layout but rather send a specific
keysym (or multiple) in response to physical button presses. This is the case
for chorded keyboards for example.
This adds a new type of key event that provides UTF8 strings. The
press/release pair applies to this type as
11 matches
Mail list logo
