On 29 July 2014 19:30, Bill Spitzak wrote:
> I would like to see character composition removed from xkb so that western
> programmers are forced to use the input method
>
XKB doesn't do multi-key composition. This is already input method only.
___
wayl
On 07/28/2014 05:14 PM, Daniel Stone wrote:
the fact that our original design for the keyboard
interface started off with keysym events _only_ (not on mailing lists, I
don't think - was an in-person meeting a couple of years ago) but we
couldn't figure out a way to make it work, I'm pretty confi
On Mon, 28 Jul 2014 16:40:31 -0700
Bill Spitzak wrote:
> On 07/28/2014 02:49 PM, Jasper St. Pierre wrote:
>
> > Try looking at the code next time. It creates a temporary file, unlinks
> > the file, writes the XKB description to it using xkb_map_get_as_string,
> > and sends it over.
>
> Okay I t
On 29 July 2014 00:40, Bill Spitzak wrote:
> I am unconvinced that any real clients will actually do this
>
They do. They all do.
> It seems like this should be implemented by having "Alt+V" translate to
> the "Paste" keysym.
>
No, this falls apart because ... well, no, I'm not going to repea
On 07/28/2014 02:49 PM, Jasper St. Pierre wrote:
Try looking at the code next time. It creates a temporary file, unlinks
the file, writes the XKB description to it using xkb_map_get_as_string,
and sends it over.
Okay I think I see this now. I'm not sure why there is a cutoff between
sizes sen
On Mon, Jul 28, 2014 at 11:36 PM, Bill Spitzak wrote:
> Yes I saw that, but it is a file descriptor. My reading was that a client
> machine must have somewhere in it's file system every possible keyboard
> that could be on a remote machine. That is actually what led to my question.
>
Try looking
Yes I saw that, but it is a file descriptor. My reading was that a
client machine must have somewhere in it's file system every possible
keyboard that could be on a remote machine. That is actually what led to
my question.
I suppose the xkb description can be sent: the local compositor would
On Mon, Jul 28, 2014 at 7:44 PM, Bill Spitzak wrote:
> I am just going to have to study this further, because I am still
> completely stumped as to why so many people think this is an acceptable
> solution.
>
> This sounds to me like either the ability to transmit an entire xkb
> description acro
I am just going to have to study this further, because I am still
completely stumped as to why so many people think this is an acceptable
solution.
This sounds to me like either the ability to transmit an entire xkb
description across the wire is added to the wayland protocol, or that
there i
Le 25/07/2014 22:08, Bill Spitzak a écrit :
> On 07/25/2014 11:59 AM, Daniel Stone wrote:
>> Since you're just repeating yourself without taking on anything that's
>> been said, so will I: that won't work.
>
> This I am finding hard to believe.
>
> My proposal is that the compositor maintain a xk
On 07/25/2014 11:59 AM, Daniel Stone wrote:
Since you're just repeating yourself without taking on anything that's
been said, so will I: that won't work.
This I am finding hard to believe.
My proposal is that the compositor maintain a xkb_state, and keystroke
events have the result of xkb_sta
nt.' If I understand correctly then
>>> the whole point of this request/event pair is to fake a key press from
>>> the input method. If so, shouldn't it make more sense to intercept the
>>> keysym request at the compositor and send a key press event to the te
e point of this request/event pair is to fake a key press from
the input method. If so, shouldn't it make more sense to intercept the
keysym request at the compositor and send a key press event to the text
application instead of passing the keysym event to the text application
(no more keysym ev
event to the text application
> (no more keysym event in the text protocol)?
>
> In the current design, the text application has to listen to the keysym
> event (for fake keys) and implement the key handler (for 'normal' keys)
> at the same time, potentially duplicating
press from
the input method. If so, shouldn't it make more sense to intercept the
keysym request at the compositor and send a key press event to the text
application instead of passing the keysym event to the text application
(no more keysym event in the text protocol)?
In the current d
15 matches
Mail list logo
