Wayland and Weston 0.95.0 released

[Bill Spitzak]

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.