Wayland and Weston 0.95.0 released
spitzak at gmail.com
Wed Jul 25 14:18:55 PDT 2012
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.
More information about the wayland-devel