I'm not clear on why Wayland's design requires adding 2 dummy objects to
the api (in this case the "wl_scalar" factory and the per-surface
"wl_surface_scalar") rather than just adding new methods to the
wl_surface object.
It seems wasteful for clients and servers to track this whole
constellations of id's for the same wl_surface. It also looks too much
like X where I had to keep the window, visual, visual id, screen,
colormap, gc, and I forget what else, because all the X functions
required different arguments types for no discernible reason when they
could all be derived from the window id.
I'm guessing there is a good reason for compatibility but it seems that
just adding more message numbers after the already-used ones would work.
To avoid collisions between multiple extensions the server could instead
send an event saying "the scalar messages to wl_surface start at N" and
this single number, rather than an per-surface extra object id, is all
the client needs to remember.
I'm guessing this is not going to be changed, so perhaps this mechanism
can at least be formalized so the documentation can be fixed to list
"set scaling" under wl_surface where you expect to find it, and then
briefly describes the factory name, and fixed rules determine the rest
of the api. I would define the following:
1. A "factory" (wl_scalar in this case) can only be used to create one
class of sub-object (the wl_surface_scalar in this case) per parent
class. It provides one method to create this object that takes one
argument, the id of the "parent" object (a wl_surface in this case).
2. The name of the subobject class is well-defined by the factory and
parent class names. The proposed "wl_surface_scalar" disagrees with
"wl_shell_surface" here.
3. The name of the method to get the sub-object from the factory is
well-defined. It looks like the standard is "get_<subobjectclass>",
though "get" would be nice in any language with overloading.
4. All factories act the same if an attempt to create more than one
subobject per parent is done. It looks like some throw errors and others
create multiple objects. If they throw errors the error enum should be
shared by all factories.
As I certainly see some similarity in the existing Wayland api's, it
seems there is at least informal standardization. Making it part of the
design spec and deprecating any irregular api would help.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
