I'm not sure why one of the large patches seems to be attributed to me, it is actually Auke's.
My only contribution was a small patch (number 4) to use the enum/bitfield information in the generated docs. My patch is slightly different that Auke's proposal and he liked it better, I was just holding on to it until the enum patches were applied. I think the necessary enums were added to the xdg_shell and some other protocol files but I don't see those patches listed. On Thu, Oct 1, 2015 at 10:59 AM, Jasper St. Pierre <jstpie...@mecheye.net> wrote: > We have a few constraints. First off, not all enums are closed. Some > are intentionally open, like xdg_shell.state. So we definitely need a > distinction between a closed enum and an open enum. I'm not familiar > enough with Rust to be able to apply something to that. > > Second, I think we need to make a big effort to map out how the XML > converts to a wire format. For the most part, it's obvious, except for > the n -> sun hack we apply when we don't have an interface name. We > should probably specify that somewhere. > > There's also a compatibility issue that has been brought up, but I > never understood that one. Somebody else would be able to talk about > that better. > > On Thu, Oct 1, 2015 at 10:49 AM, Bryce Harrington <br...@osg.samsung.com> > wrote: > > The topic of adding better enum/bitfield support to the protocol has > > come up a few[0] times[1] in the past, and again more recently[2]. We > > also have several proposed patches in patchwork, but I'm not sure they > > reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7]. > > > > From what I gather of the discussions, no one is really against this > > feature conceptually, and impementationally the discussions appear to > > have moved further afield. It feels like we're real close to having > > something that could be landed, but it's not 100% clear to me what > > exactly to land. Since it's a protocol types change I would prefer to > > make sure it has a strong consensus before landing it. > > > > I know that several people have proposed patches on this - Bill, Nils > > and Auke at least. Since there's a definite need for this, and since > > agreement appears to be not far off, I would like to get this landed > > this release. And ideally I'd like to get this landed early in the > > release so we give plenty of time for testing. > > > > Since Auke's patchset proposalis the most recent, let's take that one as > > the candidate for landing. Gentlemen, I'd like to ask you to review > > these three patches [5,6,7] and either give your Reviewed-by's or flag > > specific improvements needed. If you have a more conceptual > > disagreement, and don't think the patchset is landable as implemented, > > please raise that issue asap too. > > > > Bryce > > > > 0: > http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html > > 1: > http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html > > 2: > http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html > > > > 3: http://patchwork.freedesktop.org/patch/47726/ > > 4: http://patchwork.freedesktop.org/patch/47727/ > > 5: http://patchwork.freedesktop.org/patch/53018/ > > 6: http://patchwork.freedesktop.org/patch/53019/ > > 7: http://patchwork.freedesktop.org/patch/53020/ > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > -- > Jasper >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel