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-boun...@lists.freedesktop.org> on behalf of Jonas Ådahl <jad...@gmail.com> Sent: Tuesday, February 18, 2020 09:37 To: Pekka Paalanen <ppaala...@gmail.com> Cc: Dorota Czaplejewicz <dorota.czaplejew...@puri.sm>; wayland-devel@lists.freedesktop.org <wayland-devel@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.czaplejew...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel