Code review comment for lp:~vanvugt/mir/parenting-client-api

> A more visual explanation:
>
> sometoolkit_create_menu(conn, window, x, y):
> surf = mir_connection_create_surface_sync(conn, parms);
> mir_surface_set_type(surf, mir_surface_type_popover);
> mir_surface_set_parent(surf, window);
> mir_surface_place_relative(surf, x, y);
> return surf;
>
> So you see there are two important benefits:
> 1. The Mir API is minimal in size (in fact intentionally normalized [1])
> 2. The Mir API is maximally flexible; Mir doesn't need to know what a "menu"
> is. The toolkit is free to define whatever it likes.
> [1] http://en.wikipedia.org/wiki/Database_normalization

The above also means that menus do not exist. Instead there will only be a combination of flags that might yield a related outcome. But the client/toolkit never states that intent. If a shell plans to implement a specific behavior or look for menues it will end up searching for those combinations of flags. Additionally menues and other popovers might not even be distinguishable based on the flags provided by the client/toolkit.

On the other hand of course I do like the idea of defining a menu as a set of behavioral flags that will be independently interpreted by different components in the shell. But thats an implementation detail on the server.

Still in a distant future we might decide to expose such things - a soon as they are or can be relatively well defined - to the client api, but I do think that we then still need a client API to declare the semantics or intent of a surface. Both things may coexist but I think the latter has a higher priority and is already in a well defined state (modulo permanent changes).