Developing a core shell protocol

[Bill Spitzak]

Kristian Høgsberg wrote:

> As I mentioned briefly in IRC, I don't think there really is a core
> subset.  Almost everything in wl_shell is desktop specific.

I really feel clients should be able to call any of the shell api, but 
be prepared for only a minimal amount of results to happen. If a shell 
can't move a window it just means the move-window request is ignored. 
This can happen with a desktop shell as well (imagine one that does not 
want windows to move outside the output region). Any client that cares 
whether it can move windows or not will also have to understand a 
desktop that refuses to move a window, so this must be solved for both 
of them anyway.

>> 4) What about decorations? Right now, wayland always assumes
>> client-side decorations and the client simply decorates top-level
>> windows. However, this leads to a number of problems.  Tiling WM's for
>> instance don't decorate the same way others do, and a touch-based WM
>> might not decorate at all.

I'm going to repeat exactly what I said dozens of times before. Go ahead 
and ignore me if you want.

1. The shell sends a "no decorations" bit to the client, indicating that 
anything considered "decorations" and "titlebar" should be removed. This 
is used for fullscreen in some present-day designs for desktop shells, 
it is required for tiled window management, and it may be necessary to 
remote Wayland clients onto other machines runnning X11, Windows, and 
OS/X. It can also be used for embedding one client into another (yes I 
know the current idea is that such parent clients present their own 
Wayland server api but I feel with all the work done in the compositor 
for efficient compositing that it will be much more efficient and easier 
for the clients to talk to the server). This bit should be different 
from "full screen" for all these reasons.

2. If no-decorations is not set then the "titlebar" is part of the 
contents as far as everybody is concerned (I think titlebars are going 
to gradually vanish over the next years as the client's ui invades that 
useful screen area). However there are "edges", best described as "the 
part that is removed when you maximize a window on current desktops". 
Look carefully and you will see that there are pixels that are removed, 
obvious examples are the shadows, but also the shaded edge that is often 
used to make a window 3D, or a black border. The client tells the shell 
how thick these edges are, likely by sending a region similar to the 
input and opaque regions (it looks like it will have to be different 
than either of these, so a new api is needed).

3. The shell is able to tell the client "resize the window to be as 
though it was this size, including all the decorations, but I will clip 
the result to this area", and the client is able to set a buffer and say 
it represents this sub-rectangle of the surface, so it can skip 
allocating memory for and/or drawing the clipped parts. This is required 
for other forms of maximization that are being ignored right now, such 
as maximizing against less than 4 edges of the output, or "docking" 
against other windows, panels, and output edges.

> but I now think we're better of just living with
> that and add to wl_shell.

Yes!

> One of the things I'd like to do was to split wl_shell_surface into
> wl_shell_toplevel, wl_shell_popup, maybe wl_shell_transient.

No!!!!!

I should not have to destroy a window and recreate it just because it's 
parent window is to be removed (this would I believe change a transient 
into a normal window in this scheme). This will cause the window to 
blink unless you make "commit" even more complicated than it is now, and 
is also a pain in the *** for toolkits.

I would like to see the surface have a parent surface. "Null" means the 
surface is top-level. "non-null" means it is a transient/popup/whatever. 
Destruction of a surface changes any parents referring to it to it's 
parent. Surface parent can be changed at any time, except any attempt to 
make a loop is ignored. I believe this parent can be reused for stacking 
order and to inherit transforms but I admit is is possible that several 
parents may be needed, even if most clients set them all equal.

> This
> would avoid some "illegal" transitions, like making a popup fullscreen

Why is that "illegal"??? There is no reason anything should be illegal 
unless it violates the laws of physics. This obviously does not, because 
I can destroy the popup, create a normal window with the exact same 
contents, and show it fullscreen.

Rules like this are why it is so annoying to program ICCCM and Windows.

> Also, making a toplevel fullscreen or
> maximized would be a state change, not setting a new type of surface.

Isn't this true already?

>>  * configure
> 
> The configure event is only useful when you have to negotiate a size.
> For a fullscreen-only UI there's only one size.

Isn't configure the only way that a shell can tell a client to make a 
surface a particular size? The current fullscreen api uses this to tell 
a client how large to make the fullscreen surface, for instance.