staging: add window id protocol

The window id protocol allows clients to set an ID for toplevels, which the compositor can use to identify toplevels even after the application has been restarted. This persistent identification can be used by the compositor to restore properties like position, size, "always on top", and it can also be used for allowing users to create rules that change compositor behavior for specific windows.

Signed-off-by: Xaver Hugl xaver.hugl@gmail.com

!18 kind of tries to do a similar thing, but this is a separate protocol because

• for window rules we want an ID that is not tied to a specific instance of an application
• removing the requirement for the client to store keys and prevent collisions makes it much easier for clients to support the protocol. All the client has to do is to set a single hardcoded string per toplevel
• at least for me personally it is pretty awkward to deal with a second instance having completely separate properties (which happens with !18). If you open a second file browser instance, I would expect it to have the same size and be positioned similar to the first instance, and not to the last time that I used a second instance
• session restoration is a more specific use case, which is different from normal operation of a desktop system

Some things that should be addressed:

• should this global even create the extension object, or should it just be a global with one request for setting the id for a given toplevel?
• should this be in the xdg namespace and specific to toplevels instead of being more generic? I can't think of a different shell that would need a window ID right now
• the protocol should be tied in with wl_surface or xdg toplevel configure; the client should set the id very early