Questions and thoughts about input method protocol

[Yichao Yu]

On Fri, Feb 1, 2013 at 6:36 PM, Yichao Yu <yyc1992 at gmail.com> wrote:
> 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?

And what I am saying here is based on a on-to-on corresponding between
text_model (im-client side context) and input_method_context (input
method side context) like any other input method protocol does.

>
>>
>> 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