Kristian Høgsberg wrote:
I had the same feeling here. And we should change wl_shell to wl_desktop_shell for once.
Wouldn't that mean clients need to know what kind of shell they are talking to? I would make wl_shell be the common api and all types of shells are expected to implement it as well as possible. There can be subclasses but for now I would put any api into the base class unless it is absolutely positively obvious that the api can only be used by a particular class. None of the window management anybody has proposed falls into that catagory imho.
No, it's all frozen now. We can add to it, but we're done protocol breaks and whimsical renames. We'll probably want to revise it later on, and it may in fact be nice to reserver wl_desktop_shell for the new interface. But we're not introducing a new interface now, we're just going to pile on wl_shell (in a backwards compatible way) until it breaks. There's a lot of functionality in wl_shell that toolkits depend on for basic functionality and we can't just keep changing that every week.
Is there a way for a shell to decide itself to maximize a window? This is the only thing that I feel might be impossible in the current scheme, because it is information that must be transmitted along with the configure request, since the drawing that the client does changes in that it removes the window borders and shadows.
Everything else I am thinking of can be done with additional requests and events, and some clarification of the current behavior.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
