Enums, bitfields and wl_arrays

[Bill Spitzak]

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 <jstpierre at 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 <bryce at 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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
> --
>   Jasper
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151001/db2a72e4/attachment-0001.html>