Re: Batching text input protocol changes
On Tue, 18 Feb 2020 16:20:08 +0100 Jonas Ådahl wrote: > On Tue, Feb 18, 2020 at 04:14:50PM +0100, Dorota Czaplejewicz wrote: > > On Tue, 18 Feb 2020 10:12:11 +0200 > > Pekka Paalanen wrote: > > > > > On Mon, 17 Feb 2020 19:58:43 +0100 > > > Dorota Czaplejewicz 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. > > > > > > Mind the wayland-protocols governance rules. > > > > > > > > > Thanks, > > > pq > > > > Hi, > > > > seeing the answers so far, I think starting a new branch is a good idea. In > > case there are major changes, a new major version could be created out of > > the new branch anyway. > > > > Currently, there's only one change that's important and potentially > > backwards-incompatible, but that depends on the future discussion (deleting > > text being broke), so a new version might not be necessary yet. > > > > Could someone with the permissions create such a branch? > > I created a branch called `wip/text-input-next`: > > https://gitlab.freedesktop.org/wayland/wayland-protocols/commits/wip/text-input-next > Thank you! --Dorota > > Jonas > > > > > Thanks, > > Dorota pgpMCCfKY1y2d.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Batching text input protocol changes
On Tue, Feb 18, 2020 at 04:14:50PM +0100, Dorota Czaplejewicz wrote: > On Tue, 18 Feb 2020 10:12:11 +0200 > Pekka Paalanen wrote: > > > On Mon, 17 Feb 2020 19:58:43 +0100 > > Dorota Czaplejewicz 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. > > > > Mind the wayland-protocols governance rules. > > > > > > Thanks, > > pq > > Hi, > > seeing the answers so far, I think starting a new branch is a good idea. In > case there are major changes, a new major version could be created out of the > new branch anyway. > > Currently, there's only one change that's important and potentially > backwards-incompatible, but that depends on the future discussion (deleting > text being broke), so a new version might not be necessary yet. > > Could someone with the permissions create such a branch? I created a branch called `wip/text-input-next`: https://gitlab.freedesktop.org/wayland/wayland-protocols/commits/wip/text-input-next Jonas > > Thanks, > Dorota > ___ > 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
Re: Batching text input protocol changes
On Tue, 18 Feb 2020 10:12:11 +0200 Pekka Paalanen wrote: > On Mon, 17 Feb 2020 19:58:43 +0100 > Dorota Czaplejewicz 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. > > Mind the wayland-protocols governance rules. > > > Thanks, > pq Hi, seeing the answers so far, I think starting a new branch is a good idea. In case there are major changes, a new major version could be created out of the new branch anyway. Currently, there's only one change that's important and potentially backwards-incompatible, but that depends on the future discussion (deleting text being broke), so a new version might not be necessary yet. Could someone with the permissions create such a branch? Thanks, Dorota pgpfuRQ4DHJb0.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Batching text input protocol changes
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 on behalf of Jonas Ådahl Sent: Tuesday, February 18, 2020 09:37 To: Pekka Paalanen Cc: Dorota Czaplejewicz ; 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 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
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 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
Re: Batching text input protocol changes
On Mon, 17 Feb 2020 19:58:43 +0100 Dorota Czaplejewicz 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. Mind the wayland-protocols governance rules. Thanks, pq pgptavtcpUeHz.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
