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
Batching text input protocol changes
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? Thanks, Dorota Czaplejewicz pgps4bzpQyeb6.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
