[RFC] wl_surface scale and crop protocol extension

[Bill Spitzak]

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.