[PATCH 00/13] Clean up text protocol and move to wayland

Yichao Yu yyc1992 at gmail.com
Tue Feb 19 12:38:08 PST 2013


On Tue, Feb 19, 2013 at 3:11 PM, Jan Arne Petersen
<jpetersen at openismus.com> wrote:
> On 19.02.2013 20:01, Yichao Yu wrote:
>> On Tue, Feb 19, 2013 at 1:26 PM, Jan Arne Petersen
>> <jpetersen at openismus.com> wrote:
>>> From: Jan Arne Petersen <jpetersen at openismus.com>
>>>
>>> This series finalizes the first version of the text protocol and
>>> moves it from Weston to Wayland, so that it can be implemented in
>>> toolkits.
>>
>> Well, the only problem is that this protocol is totally not usable yet
>> and it lacks every single feature a non-layout input method needs.
>> Apart from what I have already mentioned ((more important ones first)
>> tracking input context, cursor following, getting information about
>> im-clients (pid, appname, context), and not really sure about having
>> multiple processes drawing the user interface) there is one more
>> feature that is missing. Is it possible for the im-client to send a
>> key event that is not previously handled by the input method back to
>> text_model (or is wl_text_input the new name...)? At least I haven't
>> found a request on the im-client to send this out... This is really
>> useful when the text model only get input focus after certain key
>> event (see pidgin input window as an example).
>
> With this series we try to get the text protocol into Wayland (so it can
> be supported by toolkits). The input-method protocol for input methods
> is not ready yet and will be included into Wayland later (when it will
> be ready).

I c. Yes, the im-client side api indeed looks fine. (just lack a way
to provide additional information, and may be generalized/reused..,
which is ok to add later...)

>
> * tracking input context
>   - No changes on text_input side needed. Can be all implemented in
> compositor/input-method protocol.
> * cursor following
>   - text_input::set_cursor_rectangle is there. Missing implementation is
> all in compositor/input-method protocol side.
> * getting information about im-clients (pid, appname, context)
>   - Can be easily added later to text_input (maybe there is even a
> better interface to provide application information, which could be
> reused by compositor)
> * multiple processes drawing the user interface)
>   - Already supported (and on compositor/input-method protocol side anyways)
> * im-client to send a key event
>   - Already supported (input_method::keysym/input_method::key)

Not really sure about this one, aren't these input_method::* requests
used to send key event from input method to the im-client? What I am
saying is to send a key event that is not handled by the input method
before back to the input method.

>
> So the only thing missing from the text_input interface is a request for
> context information, which can be easily added as soon as we know how it
> should look exactly.
>
> Regards,
> Jan Arne Petersen
>
> --
> Jan Arne Petersen
> Openismus GmbH
> http://www.openismus.com
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel


More information about the wayland-devel mailing list