Batching text input protocol changes

[Johan Helsing]

Same for us in Qt. When we implement a new version of the protocol, we copy it manually from wayland-protocols into qtwayland/src/3rdparty/protocol, that way we can support new versions regardless of which old-as-dirt wayland-protocols version is shipped with the device.

I think that if we'd have both released and non-released versions side by side in the same folder in wayland-protocols, it would be really confusing.

Johan
________________________________
From: wayland-devel <wayland-devel-bounces at lists.freedesktop.org> on behalf of Jonas Ådahl <jadahl at gmail.com>
Sent: Tuesday, February 18, 2020 09:37
To: Pekka Paalanen <ppaalanen at gmail.com>
Cc: Dorota Czaplejewicz <dorota.czaplejewicz at puri.sm>; wayland-devel at lists.freedesktop.org <wayland-devel at lists.freedesktop.org>
Subject: Re: Batching text input protocol changes

On Tue, Feb 18, 2020 at 10:12:11AM +0200, Pekka Paalanen wrote:
> On Mon, 17 Feb 2020 19:58:43 +0100
> Dorota Czaplejewicz <dorota.czaplejewicz at puri.sm> wrote:
>
> > Hi all,
> >
> > over the past month, the zwp_text_input_v3 protocol has moved to real
> > devices and had seen unprecedented usage. Together with that, it also
> > got a reality check, from which it didn't come unscathed. There are
> > some issues identified:
> >
> > - a hint that there's no need for an on-screen keyboard
> > - allow deleting text even when surrounding text is unknown
> > - making it harder for compositors to send uninformed updates
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/16
> > - possibly graceful switching within text inputs
> > https://gitlab.gnome.org/GNOME/gtk/issues/2437
> > - sending control events (submit, next field, undo) to gain
> > independence from a virtual keyboard protocol
> >
> > I might have left something out.
> >
> > Since they are all relatively unrelated, they can thankfully be
> > discussed separately. But merging them in separately would create
> > needlessly many combinations of possible supported versions.
> >
> > A new integration branch on gitlab would keep related merge requests
> > on the wayland-protocols repo, and it could be merged as one large
> > update once it's sufficiently hardened. Or is there another way to do
> > this?
>
> Hi Dorota,
>
> sounds like you have a good reason to have an upstream branch like
> that, so that the work in progress won't stop the master branch from
> releasing. I would be fine with that.
>
> Another way could be to start a new major version XML file, and exclude
> it from install by default. No-one could use it until you make it
> installable, so there would be no need to maintain implementations of
> the intermediate steps.

Note that some users of wayland-protocols don't use the installed
version, but manage wayland-protocols as a git submodule, thus just not
installing would not be good enough for that.

Also, if these additions are going to introduce a version 2 of the
text-input unstable v3, it'd be awkward to keep the changes in a dummy
file until merged back into the actual one.

Thus, I think using a branch until the new version is settled is the
best option here. You could still use merge requests, just that you
target a 'wip/text-input-v3.2' branch we create instead of the master
branch.


Jonas

>
> Mind the wayland-protocols governance rules.
>
>
> Thanks,
> pq



> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200218/ee3dbf33/attachment.htm>