On Fri, Feb 1, 2013 at 6:36 PM, Yichao Yu <yyc1...@gmail.com> wrote: > On Fri, Feb 1, 2013 at 6:15 PM, Bill Spitzak <spit...@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@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
