[PATCH wayland-protocols v7] text: Create second version of text input protocol

[Bryce Harrington]

On Wed, Jul 06, 2016 at 12:26:28AM +0200, Jan Arne Petersen wrote:
> On Thu, Jun 9, 2016 at 1:01 PM Carlos Garnacho <carlosg at gnome.org> wrote:
> 
> Hi Carlos,
> 
> Thanks for the feedback.
> 
> >
> > Chiming in, and kinda late at that... hopefully we'll get this moving :).
> 
> I do not think we want to change text_input_unstable_v2 version 1 anymore
> (since it already got shipped in Qt 5.7.0 and Plasma 5.7.0). Sorry for that.
> But I already started to  work on text_input_unstable_v2 version 2 and also
> text_input_unstable_v3 where I like to include the feedback.
>
> > First of all, I'm aware that some of my comments are directed towards
> > stuff that's unchanged between v1 and v2, so please bear with me, I
> > hope the feedback is useful.
> 
> Sure that is perfectly fine, I think that is the idea of the unstable protocols
> anyways that we can still change everything and adapt them with real
> world experience.

> > On Mon, May 30, 2016 at 11:41 AM, Jan Arne Petersen <janarne at gmail.com> wrote:
> > > There were some shortcomings in the first version of the protocol which
> > > makes it not really useful in real world applications. It is not really
> > > possible to fix them in a compatible way so introduce a new v2 of the
> > > protocol.
> > >
> > > Fixes some shortcomings of the first version:
> > >
> > > * Use only one wp_text_input per wl_seat (client side should be
> > >   handled by client toolkit)
> > > * Allow focus tracking without wl_keyboard present
> > > * Improve update state handling and better define state handling

I'd love to see a re-rev of this patch.  Looking at a diff between v1
and v2, those three changes seem quite suitable, although I'd like to
see an exact minimal diff of the changes so holding off on detailed
review.  But worth an acked by at least:

Acked-by: Bryce Harrington <bryce at osg.samsung.com>


The input-method and text-input protocols both deal with similar
functionality (text input).  I'm not sure if we already have a high
level description somewhere that describes their relationship, but at a
minimum I think the protocols ought to cross-reference each other.  (For
instance, something like, "See also the input-method protocol, which
provides ...")  When I first looked at the two protocols, just reading
their descriptions it wasn't obvious at all how they related; it only
clicked after studying the weston code.

Bryce