Questions and thoughts about input method protocol

[Yichao Yu]

On Fri, Feb 1, 2013 at 6:15 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Will simple input methods that have no state have to do anything about this,
> or is it trivial to support?
>
> What I am wondering is if an input method that does not use the context id
> for anything will still need to keep track of what context id's were
> allocated and freed? Or can it just throw them away and answer "ok" to all
> attempts to create and destroy them?
>
> Alternative is that it says it can't create them, but then the burden is on
> the clients to handle this.

I suppose with a destroy event (which we have now). A simple input
method that don't want to worry about keeping track of context's
(which I personally don't really want to call it a full function input
method) can just bind the object and leave it there until the destroy
event comes and then destroy the context. No?

>
> Yichao Yu wrote:
>>
>> If I understand what you mean is the request/event added is a way to
>> make im-client and input method collaborate better by sharing some
>> basic info (like language in use). However, the problem we are having
>> is it is impossible to keep track of the same input context whenever a
>> im-client lost focus with the current protocol, therefore, the input
>> method cannot keep a internal state anywhere. I think Jan already
>> agrees to add support for it (thx Jan) and we will get what we need
>> from there.
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel