Re: [PATCH weston 00/10] weston wayland-protocols migration
November 6 2015 2:32 AM, "Jonas Ådahl" wrote:
> More or less. The question is whether it would be Ok to break builds,
> and if so how "soon"?
>
are builds have to breaks?
If build systems smarts enought(no needs for so complicated)
and its behaivour known clearly both by you upstream devs and downstream
clients
then it able to handle all cases?
A pseudocode instance:
if(exists("protocol_foo_v1.xml"))
{
do_stuff
}
else if(exists("deprecated/protocol_foo_v1.xml"))
{
do_stuff
}
else
{
do_stuff
}
or something similar. regards.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/10] weston wayland-protocols migration
On Fri, 6 Nov 2015 10:39:12 +0800 Jonas Ådahl wrote: > On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote: > > On Wed, 4 Nov 2015 16:49:49 +0800 > > Jonas Ådahl wrote: > > > > > Hi, > > > > > > This series changes weston to depend on wayland-protocols for the > > > majority of the protocols previously in the protocols/ directory. The > > > protocols moved are also renamed to comply with the unstable naming > > > conventions of wayland-protocols, with the exception of xdg_shell which > > > will use the current name until the next version. > > > > > > I'd appreciate if maintainers of given protocols could at least Ack the > > > patch changing their protocol implementation, as a semi formal stamp of > > > approval of the name change. > > > > Hi Jonas, > > > > I'll give any detailed feedback as replies to the patches, here are some > > overall comments. > > > > > Other than that, the workspaces protocol is removed, mostly because it > > > wasn't a significant enough proof of concept needed for any particular > > > feature. text-cursor-position.xml however I have left intact, because > > > without it the zoom accessibility feature proof of concept becomes > > > a bit too useless. I'd prefer to prefix it with something like toy_ or > > > weston_, but would like to hear input on this one. Given that it is > > > completely undocumented it is quite far from a real attempt, but it > > > seems like something that will be needed sooner or later for > > > accessibility reasons, so not sure what to do with it right now. > > > > > > Things that seemed more weston specific was weston_ prefixed. The > > > screenshooter protocol and the desktop shell protocol fell into this > > > category. > > > > Speaking of prefixes, do we have an idea what protocols should use the > > wl_ prefix and what shouldn't? > > > > I have had the feeling that wl_ is only Wayland core. But what does > > Wayland core mean? And wl_shell is an exception already. > > > > Should we restrict wl_ to only for things in wayland.xml? Probably not, > > as I think wl_ in e.g. wl_scaler is justified since it's a "low-level" > > generic feature, and yet wl_scaler will not be added into wayland.xml. > > > > Perhaps wl_ prefix should be reserved for extensions that are usable > > regardless of a shell or environment. I'm not sure if the input method > > extensions would be eligible for wl_ or not, or what to do with > > fullscreen shell. > > > > xdg_shell is setting a precedent for using xdg_ prefix for all > > desktoppy but still DE-agnostic extensions, and I think that is fine. > > We discussed this last night on IRC and you expressed that you thought > that the wl_ prefix should be limited to only libwayland-client and > libwayland-server and nothing else. Indeed. The rationale I gave in IRC is that if we look at how the wl_ prefix is currently used, unstable protocols notwithstanding, we have it for normal libwayland functions and protocol interfaces in wayland.xml. The common factor here is that they all are in libwayland (which even installs generated C bindings for wayland.xml), so it would be logical to have wl_ mean "Wayland library". The earlier interpretation of wl_ meaning "Wayland core protocol" was encumbered by libwayland having non-protocol functions and types with that prefix and wayland.xml containing wl_shell. We don't really think wl_shell as Wayland core because it is specific to desktops, I think. > The resulting idea after that discussion was to use the wp_ prefix > instead of wl_ prefix for future protocols with the exception of the > rare cases where new interfaces actually have to be added to > wayland.xml. I don't know of any examples or plans where this is needed > yet. > > This means wl_scaler would become wp_scaler, wl_fullscreen would become > wp_fullscreen, wl_presentation wp_presentation, etc. wp_ is just whatever came first to my mind, from "Wayland protocol". I'd like to say "better suggestions welcome", but I don't want to delay this work on bikeshedding on it, so I'll just say: "if there is a good reason to not use wp_, tell us now!" > We also somewhat concluded that generic sounding name (linux_) should > also be prefixed, meaning linux_dmabuf will become wp_linux_dmabuf, but > maybe we should really use some other prefix for non-generic protocols? > I'm not sure. wp_linux_dmabuf works for me, and should address the concerns Daniel Stone had about namespace clashes. I think wp_linux_ is appropriate: it is generic in the sense that it does not have any ties to shells, DEs or other non-generic extensions, and it is specific to linux (until other OSs implement dmabuf support). Whether non-generic extensions use prefix foo_ or wp_foo_, I don't really care per se. If foo_ alone is distinguishing enough, I'm ok either way. However, using wp_ prefix for a non-generic extension without any other prefix is something I'd like to avoid. IOW, I would not like e.g. wp_popup, because popups are inhere
Re: [PATCH weston 00/10] weston wayland-protocols migration
On Thu, Nov 05, 2015 at 09:36:18PM -0800, Bryce Harrington wrote: > On Fri, Nov 06, 2015 at 10:39:12AM +0800, Jonas Ådahl wrote: > > On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote: > > > On Wed, 4 Nov 2015 16:49:49 +0800 > > > Jonas Ådahl wrote: > > > > Things that seemed more weston specific was weston_ prefixed. The > > > > screenshooter protocol and the desktop shell protocol fell into this > > > > category. > > > > > > Speaking of prefixes, do we have an idea what protocols should use the > > > wl_ prefix and what shouldn't? > > > > > > I have had the feeling that wl_ is only Wayland core. But what does > > > Wayland core mean? And wl_shell is an exception already. > > > > > > Should we restrict wl_ to only for things in wayland.xml? Probably not, > > > as I think wl_ in e.g. wl_scaler is justified since it's a "low-level" > > > generic feature, and yet wl_scaler will not be added into wayland.xml. > > > > > > Perhaps wl_ prefix should be reserved for extensions that are usable > > > regardless of a shell or environment. I'm not sure if the input method > > > extensions would be eligible for wl_ or not, or what to do with > > > fullscreen shell. > > > > > > xdg_shell is setting a precedent for using xdg_ prefix for all > > > desktoppy but still DE-agnostic extensions, and I think that is fine. > > > > We discussed this last night on IRC and you expressed that you thought > > that the wl_ prefix should be limited to only libwayland-client and > > libwayland-server and nothing else. > > > > The resulting idea after that discussion was to use the wp_ prefix > > instead of wl_ prefix for future protocols with the exception of the > > rare cases where new interfaces actually have to be added to > > wayland.xml. I don't know of any examples or plans where this is needed > > yet. > > > > This means wl_scaler would become wp_scaler, wl_fullscreen would become > > wp_fullscreen, wl_presentation wp_presentation, etc. > > I can live with that, although I suspect I'll always read it as Word > Perfect rather than Wayland Protocol... Or WordPress... > > > We also somewhat concluded that generic sounding name (linux_) should > > also be prefixed, meaning linux_dmabuf will become wp_linux_dmabuf, but > > maybe we should really use some other prefix for non-generic protocols? > > I'm not sure. > > Agreed on prefixing these. > > > Regarding the xdg_ prefix, nothing in particular was concluded. I'm not > > sure wp_xdg_ is desirable, but maybe its not that bad. We'll have to > > bite this bullet the next time xdg_shell changes, or if some other > > protocol depending on xdg_shell is introduced. Opinions? Stay with xdg_? > > wp_xdg_? wpxdg? wxdg? wp_desktop_shell? Something else? > > This is probably going to require some debate... which is why I > suggested leaving it as a special case so as not to derail the rest of > the effort. But, I do think it too should be renamed, and I feel fairly > strongly that in doing so we should just discard "xdg" from the name. Yea, lets leave any decision to when we need to make it, which is not before the first release of wayland-protocols. > Here's my thinking: > > 1. "xdg" is a prefix used by an actual real open source project which > isn't us. We're not using it inappropriately or anything, but still. > We wouldn't name a protocol kde_foo_thingee to make it more acceptable > to kde folks. I *think* one of the reasons why the prefix is xdg_ was that it was intended to be developed and maintained as part of the xdg project, and in that case it makes sense to use that prefix. However, that is not really how it has worked so far, nor how I assume it will work in the future, making the prefix a bit unfortunate. > > 2. As a corollary to #1, using it might suggest the protocol is > something *external* to wayland and not sanctioned by us. Just as if we > prefixed it kde_ people would reasonably assume it was a KDE thing, not > wayland. > > 3. While there is I guess you could say "marketing" value in including > "XDG" in the name as a way to promote cross-desktop adoption, if it did > have any such value in the past, we're beyond that point now. > > 4. Many people probably won't know what "XDG" stands for anyway. We > would do as well to just call it wp_common_desktop_shell and it'd be > more comprehensible to the average person and no less cross-desktoppy. > > 5. I don't think it's really that important that we especially label a > protocol as cross-desktop. After all, the implication is that all > Wayland protocols are intended to be widely usable. I don't think we'd > push a protocol that is usable by only one desktop environment, so in > that sense xdg_ is kind of redundant with wl_ (or wp_). > > 6. As this is a protocol we want to be standardized, that we want to > actively maintain, and that we want used broadly by Wayland-based > projects, it seems right to give it a simple, prominent name like > wp_desktop_shell. > > Anyway, tha
Re: [PATCH weston 00/10] weston wayland-protocols migration
On Fri, Nov 06, 2015 at 10:39:12AM +0800, Jonas Ådahl wrote: > On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote: > > On Wed, 4 Nov 2015 16:49:49 +0800 > > Jonas Ådahl wrote: > > > Things that seemed more weston specific was weston_ prefixed. The > > > screenshooter protocol and the desktop shell protocol fell into this > > > category. > > > > Speaking of prefixes, do we have an idea what protocols should use the > > wl_ prefix and what shouldn't? > > > > I have had the feeling that wl_ is only Wayland core. But what does > > Wayland core mean? And wl_shell is an exception already. > > > > Should we restrict wl_ to only for things in wayland.xml? Probably not, > > as I think wl_ in e.g. wl_scaler is justified since it's a "low-level" > > generic feature, and yet wl_scaler will not be added into wayland.xml. > > > > Perhaps wl_ prefix should be reserved for extensions that are usable > > regardless of a shell or environment. I'm not sure if the input method > > extensions would be eligible for wl_ or not, or what to do with > > fullscreen shell. > > > > xdg_shell is setting a precedent for using xdg_ prefix for all > > desktoppy but still DE-agnostic extensions, and I think that is fine. > > We discussed this last night on IRC and you expressed that you thought > that the wl_ prefix should be limited to only libwayland-client and > libwayland-server and nothing else. > > The resulting idea after that discussion was to use the wp_ prefix > instead of wl_ prefix for future protocols with the exception of the > rare cases where new interfaces actually have to be added to > wayland.xml. I don't know of any examples or plans where this is needed > yet. > > This means wl_scaler would become wp_scaler, wl_fullscreen would become > wp_fullscreen, wl_presentation wp_presentation, etc. I can live with that, although I suspect I'll always read it as Word Perfect rather than Wayland Protocol... > We also somewhat concluded that generic sounding name (linux_) should > also be prefixed, meaning linux_dmabuf will become wp_linux_dmabuf, but > maybe we should really use some other prefix for non-generic protocols? > I'm not sure. Agreed on prefixing these. > Regarding the xdg_ prefix, nothing in particular was concluded. I'm not > sure wp_xdg_ is desirable, but maybe its not that bad. We'll have to > bite this bullet the next time xdg_shell changes, or if some other > protocol depending on xdg_shell is introduced. Opinions? Stay with xdg_? > wp_xdg_? wpxdg? wxdg? wp_desktop_shell? Something else? This is probably going to require some debate... which is why I suggested leaving it as a special case so as not to derail the rest of the effort. But, I do think it too should be renamed, and I feel fairly strongly that in doing so we should just discard "xdg" from the name. Here's my thinking: 1. "xdg" is a prefix used by an actual real open source project which isn't us. We're not using it inappropriately or anything, but still. We wouldn't name a protocol kde_foo_thingee to make it more acceptable to kde folks. 2. As a corollary to #1, using it might suggest the protocol is something *external* to wayland and not sanctioned by us. Just as if we prefixed it kde_ people would reasonably assume it was a KDE thing, not wayland. 3. While there is I guess you could say "marketing" value in including "XDG" in the name as a way to promote cross-desktop adoption, if it did have any such value in the past, we're beyond that point now. 4. Many people probably won't know what "XDG" stands for anyway. We would do as well to just call it wp_common_desktop_shell and it'd be more comprehensible to the average person and no less cross-desktoppy. 5. I don't think it's really that important that we especially label a protocol as cross-desktop. After all, the implication is that all Wayland protocols are intended to be widely usable. I don't think we'd push a protocol that is usable by only one desktop environment, so in that sense xdg_ is kind of redundant with wl_ (or wp_). 6. As this is a protocol we want to be standardized, that we want to actively maintain, and that we want used broadly by Wayland-based projects, it seems right to give it a simple, prominent name like wp_desktop_shell. Anyway, that's my long-winded +1 vote for renaming xdg-shell to wp_desktop_shell. Bryce ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/10] weston wayland-protocols migration
On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote: > On Wed, 4 Nov 2015 16:49:49 +0800 > Jonas Ådahl wrote: > > > Hi, > > > > This series changes weston to depend on wayland-protocols for the > > majority of the protocols previously in the protocols/ directory. The > > protocols moved are also renamed to comply with the unstable naming > > conventions of wayland-protocols, with the exception of xdg_shell which > > will use the current name until the next version. > > > > I'd appreciate if maintainers of given protocols could at least Ack the > > patch changing their protocol implementation, as a semi formal stamp of > > approval of the name change. > > Hi Jonas, > > I'll give any detailed feedback as replies to the patches, here are some > overall comments. > > > Other than that, the workspaces protocol is removed, mostly because it > > wasn't a significant enough proof of concept needed for any particular > > feature. text-cursor-position.xml however I have left intact, because > > without it the zoom accessibility feature proof of concept becomes > > a bit too useless. I'd prefer to prefix it with something like toy_ or > > weston_, but would like to hear input on this one. Given that it is > > completely undocumented it is quite far from a real attempt, but it > > seems like something that will be needed sooner or later for > > accessibility reasons, so not sure what to do with it right now. > > > > Things that seemed more weston specific was weston_ prefixed. The > > screenshooter protocol and the desktop shell protocol fell into this > > category. > > Speaking of prefixes, do we have an idea what protocols should use the > wl_ prefix and what shouldn't? > > I have had the feeling that wl_ is only Wayland core. But what does > Wayland core mean? And wl_shell is an exception already. > > Should we restrict wl_ to only for things in wayland.xml? Probably not, > as I think wl_ in e.g. wl_scaler is justified since it's a "low-level" > generic feature, and yet wl_scaler will not be added into wayland.xml. > > Perhaps wl_ prefix should be reserved for extensions that are usable > regardless of a shell or environment. I'm not sure if the input method > extensions would be eligible for wl_ or not, or what to do with > fullscreen shell. > > xdg_shell is setting a precedent for using xdg_ prefix for all > desktoppy but still DE-agnostic extensions, and I think that is fine. We discussed this last night on IRC and you expressed that you thought that the wl_ prefix should be limited to only libwayland-client and libwayland-server and nothing else. The resulting idea after that discussion was to use the wp_ prefix instead of wl_ prefix for future protocols with the exception of the rare cases where new interfaces actually have to be added to wayland.xml. I don't know of any examples or plans where this is needed yet. This means wl_scaler would become wp_scaler, wl_fullscreen would become wp_fullscreen, wl_presentation wp_presentation, etc. We also somewhat concluded that generic sounding name (linux_) should also be prefixed, meaning linux_dmabuf will become wp_linux_dmabuf, but maybe we should really use some other prefix for non-generic protocols? I'm not sure. Regarding the xdg_ prefix, nothing in particular was concluded. I'm not sure wp_xdg_ is desirable, but maybe its not that bad. We'll have to bite this bullet the next time xdg_shell changes, or if some other protocol depending on xdg_shell is introduced. Opinions? Stay with xdg_? wp_xdg_? wpxdg? wxdg? wp_desktop_shell? Something else? Anyhow, I will add the concluded parts to the README. > > > Another protocol left to migrate is scalar.xml. I didn't do this yet > > because Pekka had plans on renaming it, and I'll simply wait until he > > has a name for it before migrating anything. > > Yeah, inventing a new name for it is hard, but I'll try to come up with > something. Something that implies both scaling and clipping... > something used to create viewport objects... > > > Other than that, the wayland-protocols have shaped up some, with the > > pointer gestures protocol as well as the protocols of this series > > migrated there. I wouldn't mind if people went and had a look to see if > > there are any opinions of how things should work before we make an > > initial release. The procedures and some details are explained in the > > README file in the toplevel directory. > > The README looks fine to me on the whole, I sent you some trivial typo > fixes for your consideration. > > This puzzles me a bit: > > "Each release of wayland-protocols finalizes the version of the > protocols to their state they had at that time. Between each > release, backward incompatible changes can be made to both > stable and major unstable protocol versions as long as the > requirements are held upon release." > > It says backward-incompatible changes could be made to also stable > protocols as long as stability
Re: [PATCH weston 00/10] weston wayland-protocols migration
On Thu, Nov 05, 2015 at 12:21:21PM +0200, Pekka Paalanen wrote: > On Wed, 4 Nov 2015 16:49:49 +0800 > Jonas Ådahl wrote: > > > Hi, > > > > This series changes weston to depend on wayland-protocols for the > > majority of the protocols previously in the protocols/ directory. The > > protocols moved are also renamed to comply with the unstable naming > > conventions of wayland-protocols, with the exception of xdg_shell which > > will use the current name until the next version. > > > > I'd appreciate if maintainers of given protocols could at least Ack the > > patch changing their protocol implementation, as a semi formal stamp of > > approval of the name change. > > Hi Jonas, > > I'll give any detailed feedback as replies to the patches, here are some > overall comments. > > > Other than that, the workspaces protocol is removed, mostly because it > > wasn't a significant enough proof of concept needed for any particular > > feature. text-cursor-position.xml however I have left intact, because > > without it the zoom accessibility feature proof of concept becomes > > a bit too useless. I'd prefer to prefix it with something like toy_ or > > weston_, but would like to hear input on this one. Given that it is > > completely undocumented it is quite far from a real attempt, but it > > seems like something that will be needed sooner or later for > > accessibility reasons, so not sure what to do with it right now. > > > > Things that seemed more weston specific was weston_ prefixed. The > > screenshooter protocol and the desktop shell protocol fell into this > > category. > > Speaking of prefixes, do we have an idea what protocols should use the > wl_ prefix and what shouldn't? > > I have had the feeling that wl_ is only Wayland core. But what does > Wayland core mean? And wl_shell is an exception already. > > Should we restrict wl_ to only for things in wayland.xml? Probably not, > as I think wl_ in e.g. wl_scaler is justified since it's a "low-level" > generic feature, and yet wl_scaler will not be added into wayland.xml. > > Perhaps wl_ prefix should be reserved for extensions that are usable > regardless of a shell or environment. I'm not sure if the input method > extensions would be eligible for wl_ or not, or what to do with > fullscreen shell. That sounds like a good rule of thumb. I should think it further should be limited to stuff that we (the Wayland project) intend to provide stability guarantees for and to maintain as an official interface for the project. > This puzzles me a bit: > > "Each release of wayland-protocols finalizes the version of the > protocols to their state they had at that time. Between each > release, backward incompatible changes can be made to both > stable and major unstable protocol versions as long as the > requirements are held upon release." > > It says backward-incompatible changes could be made to also stable > protocols as long as stability is maintained from release to release. > Essentially it means that such changes have to be reverted before the > next release. Is that just to account for accidents? > > If wayland-protocols is intended to be released often and as-needed, we > should make sure we don't need such reverts to begin with. Otherwise > the release engineer will have a big review burden. IOW, we should keep > the repo in an always releasable state. > > In short, I wouldn't mention the stable protocols in this paragraph. Agreed. It's also not unlikely people will be using snapshots of the git tree from between releases. Bryce ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 00/10] weston wayland-protocols migration
On Wed, 4 Nov 2015 16:49:49 +0800 Jonas Ådahl wrote: > Hi, > > This series changes weston to depend on wayland-protocols for the > majority of the protocols previously in the protocols/ directory. The > protocols moved are also renamed to comply with the unstable naming > conventions of wayland-protocols, with the exception of xdg_shell which > will use the current name until the next version. > > I'd appreciate if maintainers of given protocols could at least Ack the > patch changing their protocol implementation, as a semi formal stamp of > approval of the name change. Hi Jonas, I'll give any detailed feedback as replies to the patches, here are some overall comments. > Other than that, the workspaces protocol is removed, mostly because it > wasn't a significant enough proof of concept needed for any particular > feature. text-cursor-position.xml however I have left intact, because > without it the zoom accessibility feature proof of concept becomes > a bit too useless. I'd prefer to prefix it with something like toy_ or > weston_, but would like to hear input on this one. Given that it is > completely undocumented it is quite far from a real attempt, but it > seems like something that will be needed sooner or later for > accessibility reasons, so not sure what to do with it right now. > > Things that seemed more weston specific was weston_ prefixed. The > screenshooter protocol and the desktop shell protocol fell into this > category. Speaking of prefixes, do we have an idea what protocols should use the wl_ prefix and what shouldn't? I have had the feeling that wl_ is only Wayland core. But what does Wayland core mean? And wl_shell is an exception already. Should we restrict wl_ to only for things in wayland.xml? Probably not, as I think wl_ in e.g. wl_scaler is justified since it's a "low-level" generic feature, and yet wl_scaler will not be added into wayland.xml. Perhaps wl_ prefix should be reserved for extensions that are usable regardless of a shell or environment. I'm not sure if the input method extensions would be eligible for wl_ or not, or what to do with fullscreen shell. xdg_shell is setting a precedent for using xdg_ prefix for all desktoppy but still DE-agnostic extensions, and I think that is fine. > Another protocol left to migrate is scalar.xml. I didn't do this yet > because Pekka had plans on renaming it, and I'll simply wait until he > has a name for it before migrating anything. Yeah, inventing a new name for it is hard, but I'll try to come up with something. Something that implies both scaling and clipping... something used to create viewport objects... > Other than that, the wayland-protocols have shaped up some, with the > pointer gestures protocol as well as the protocols of this series > migrated there. I wouldn't mind if people went and had a look to see if > there are any opinions of how things should work before we make an > initial release. The procedures and some details are explained in the > README file in the toplevel directory. The README looks fine to me on the whole, I sent you some trivial typo fixes for your consideration. This puzzles me a bit: "Each release of wayland-protocols finalizes the version of the protocols to their state they had at that time. Between each release, backward incompatible changes can be made to both stable and major unstable protocol versions as long as the requirements are held upon release." It says backward-incompatible changes could be made to also stable protocols as long as stability is maintained from release to release. Essentially it means that such changes have to be reverted before the next release. Is that just to account for accidents? If wayland-protocols is intended to be released often and as-needed, we should make sure we don't need such reverts to begin with. Otherwise the release engineer will have a big review burden. IOW, we should keep the repo in an always releasable state. In short, I wouldn't mention the stable protocols in this paragraph. I looked at the Presentation (feedback) extension in wayland-protocols, and I saw that you renamed both global and non-global interfaces. Do we need to rename also non-global interfaces according to the unstable naming convention? I assumed renaming the globals would be enough, because it is enough to bring the runtime discoverability. Renaming also non-global interfaces seems needless churn on one hand, but it does make it painfully clear to a developer upgrading to a new major version which places he needs to review in the code for changes. > One current inconvenience that would be nice with some opinions is what > to do with unstable protocol files after a protocol has been declared > stable. Currently specified to work by having one directory containing > the stable XML file together with a README in the stable/ toplevel > directory, and yet another directory containing the unstable protocol > files toget
Re: [PATCH weston 00/10] weston wayland-protocols migration
On Wed, Nov 04, 2015 at 05:50:00PM +0100, Mariusz Ceier wrote: > Hi, >Weston doesn't compile with this patchset - some source files in clients > directory still use old or removed headers. > I had to replace xdg-shell-server-protocol.h in desktop-shell/shell.c > with xdg-shell-unstable-v5-server-protocol.h and disable clients > compilation in order to be able to compile weston. > If that's not an issue: It is. I had forgotten to remove the old generated files from xdg-shell.xml, but that is now taken care of locally. Thanks for testing and reviewing. Jonas > > Reviewed-by: Mariusz Ceier > > Mariusz Ceier > > On 4 November 2015 at 09:49, Jonas Ådahl wrote: > > > Hi, > > > > This series changes weston to depend on wayland-protocols for the > > majority of the protocols previously in the protocols/ directory. The > > protocols moved are also renamed to comply with the unstable naming > > conventions of wayland-protocols, with the exception of xdg_shell which > > will use the current name until the next version. > > > > I'd appreciate if maintainers of given protocols could at least Ack the > > patch changing their protocol implementation, as a semi formal stamp of > > approval of the name change. > > > > Other than that, the workspaces protocol is removed, mostly because it > > wasn't a significant enough proof of concept needed for any particular > > feature. text-cursor-position.xml however I have left intact, because > > without it the zoom accessibility feature proof of concept becomes > > a bit too useless. I'd prefer to prefix it with something like toy_ or > > weston_, but would like to hear input on this one. Given that it is > > completely undocumented it is quite far from a real attempt, but it > > seems like something that will be needed sooner or later for > > accessibility reasons, so not sure what to do with it right now. > > > > Things that seemed more weston specific was weston_ prefixed. The > > screenshooter protocol and the desktop shell protocol fell into this > > category. > > > > Another protocol left to migrate is scalar.xml. I didn't do this yet > > because Pekka had plans on renaming it, and I'll simply wait until he > > has a name for it before migrating anything. > > > > Other than that, the wayland-protocols have shaped up some, with the > > pointer gestures protocol as well as the protocols of this series > > migrated there. I wouldn't mind if people went and had a look to see if > > there are any opinions of how things should work before we make an > > initial release. The procedures and some details are explained in the > > README file in the toplevel directory. > > > > One current inconvenience that would be nice with some opinions is what > > to do with unstable protocol files after a protocol has been declared > > stable. Currently specified to work by having one directory containing > > the stable XML file together with a README in the stable/ toplevel > > directory, and yet another directory containing the unstable protocol > > files together with a README in the unstable/ directory. This seems a bit > > backward to me. Deprecating a protocol by moving it into deprecated/ > > would still require us to have the protocol in the stable/ and probably > > even in the unstable/ directory. This all is a bit awkward to me. One > > idea is restructure the tree a bit and put protocols in the directory of > > the current state (stable/unstable/obsolete) and then keep the old XML > > files in subdirectories in there, having the Makefile deal with > > installing XML files appropriately in the corresponding > > stable/unstable/obsolete directories. Or we could have all protocols in > > the toplevel directory and always have the corresponding XML files in > > stable/unstable/obsolete subdirectories and just installing that. Any > > opinions about this? > > > > > > Jonas > > > > > > Jonas Ådahl (10): > > Use fullscreen-shell.xml from wayland-protocols > > Use linux-dmabuf protocol from wayland-protocols > > Use presentation timing protocol from wayland-protocols > > Use text input protocol from wayland-protocols > > Use input method protocol from wayland-protocols > > Makefile.am: Make the external xml scanning rule version generic > > Use xdg_shell protocol from wayland-protocols > > desktop-shell: Rename protocol weston_desktop_shell > > Rename screenshooter protocol to weston_screenshooter > > Remove workspaces protocol > > > > Makefile.am | 194 ++-- > > clients/desktop-shell.c | 79 ++--- > > clients/editor.c| 119 +++ > > clients/fullscreen.c| 60 ++-- > > clients/keyboard.c | 186 +-- > > clients/presentation-shm.c | 65 ++-- > > clients/screenshot.c| 21 +- > > clients/simple-damage.c | 18 +- > > clients/simple-dmabuf.c | 74 ++--- > > clients/simple-shm.c| 18 +- > >
Re: [PATCH weston 00/10] weston wayland-protocols migration
Hi, Weston doesn't compile with this patchset - some source files in clients directory still use old or removed headers. I had to replace xdg-shell-server-protocol.h in desktop-shell/shell.c with xdg-shell-unstable-v5-server-protocol.h and disable clients compilation in order to be able to compile weston. If that's not an issue: Reviewed-by: Mariusz Ceier Mariusz Ceier On 4 November 2015 at 09:49, Jonas Ådahl wrote: > Hi, > > This series changes weston to depend on wayland-protocols for the > majority of the protocols previously in the protocols/ directory. The > protocols moved are also renamed to comply with the unstable naming > conventions of wayland-protocols, with the exception of xdg_shell which > will use the current name until the next version. > > I'd appreciate if maintainers of given protocols could at least Ack the > patch changing their protocol implementation, as a semi formal stamp of > approval of the name change. > > Other than that, the workspaces protocol is removed, mostly because it > wasn't a significant enough proof of concept needed for any particular > feature. text-cursor-position.xml however I have left intact, because > without it the zoom accessibility feature proof of concept becomes > a bit too useless. I'd prefer to prefix it with something like toy_ or > weston_, but would like to hear input on this one. Given that it is > completely undocumented it is quite far from a real attempt, but it > seems like something that will be needed sooner or later for > accessibility reasons, so not sure what to do with it right now. > > Things that seemed more weston specific was weston_ prefixed. The > screenshooter protocol and the desktop shell protocol fell into this > category. > > Another protocol left to migrate is scalar.xml. I didn't do this yet > because Pekka had plans on renaming it, and I'll simply wait until he > has a name for it before migrating anything. > > Other than that, the wayland-protocols have shaped up some, with the > pointer gestures protocol as well as the protocols of this series > migrated there. I wouldn't mind if people went and had a look to see if > there are any opinions of how things should work before we make an > initial release. The procedures and some details are explained in the > README file in the toplevel directory. > > One current inconvenience that would be nice with some opinions is what > to do with unstable protocol files after a protocol has been declared > stable. Currently specified to work by having one directory containing > the stable XML file together with a README in the stable/ toplevel > directory, and yet another directory containing the unstable protocol > files together with a README in the unstable/ directory. This seems a bit > backward to me. Deprecating a protocol by moving it into deprecated/ > would still require us to have the protocol in the stable/ and probably > even in the unstable/ directory. This all is a bit awkward to me. One > idea is restructure the tree a bit and put protocols in the directory of > the current state (stable/unstable/obsolete) and then keep the old XML > files in subdirectories in there, having the Makefile deal with > installing XML files appropriately in the corresponding > stable/unstable/obsolete directories. Or we could have all protocols in > the toplevel directory and always have the corresponding XML files in > stable/unstable/obsolete subdirectories and just installing that. Any > opinions about this? > > > Jonas > > > Jonas Ådahl (10): > Use fullscreen-shell.xml from wayland-protocols > Use linux-dmabuf protocol from wayland-protocols > Use presentation timing protocol from wayland-protocols > Use text input protocol from wayland-protocols > Use input method protocol from wayland-protocols > Makefile.am: Make the external xml scanning rule version generic > Use xdg_shell protocol from wayland-protocols > desktop-shell: Rename protocol weston_desktop_shell > Rename screenshooter protocol to weston_screenshooter > Remove workspaces protocol > > Makefile.am | 194 ++-- > clients/desktop-shell.c | 79 ++--- > clients/editor.c| 119 +++ > clients/fullscreen.c| 60 ++-- > clients/keyboard.c | 186 +-- > clients/presentation-shm.c | 65 ++-- > clients/screenshot.c| 21 +- > clients/simple-damage.c | 18 +- > clients/simple-dmabuf.c | 74 ++--- > clients/simple-shm.c| 18 +- > clients/weston-info.c | 19 +- > clients/weston-simple-im.c | 122 +++ > clients/window.c| 57 +--- > configure.ac| 7 + > desktop-shell/input-panel.c | 14 +- > desktop-shell/shell.c | 183 +++ > desktop-shell/shell.h | 4 +- > fullscreen-shell/fullscreen-shell.c | 54 ++-- > ivi-shell/inpu
