Enums, bitfields and wl_arrays
Jasper St. Pierre
jstpierre at mecheye.net
Thu Oct 1 10:59:49 PDT 2015
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
More information about the wayland-devel
mailing list