Weston : ideas about xdg_sell, and implementation for a taskbar

[Bill Spitzak]

Jasper St. Pierre wrote:

> Hiding windows should not have any influence over the client, as many 
> desktop environments, including Weston, want to show live previews for 
> minimized or hidden windows in alt-tab or Expose-alikes.
> 
> Also, it matches user expectations. If the user clicks minimize on a 
> window, they want it hidden, and they mean it, not get bested with 
> "surprise! You tried to hide me but I resist by mapping my subsurfaces 
> elsewhere!"

The problem is that it makes window management very complicated, or 
limiting. This is why no modern applications use overlapping windows, 
instead doing their own tiled window layout inside one big window. They 
cannot get the window system to overlay windows correctly except for 
trivial temporary popups.

A simple problem is a floating window shared by two main windows. Some 
parts of the compositor want to know that the floating window belongs to 
at least one main window (for instance to not show it in a toolbar). But 
the client does not want it to vanish when that window is closed, yet it 
should vanish when both windows are closed.

This will require the client to tell the compositor that both of the 
main windows are parents, thus giving rise to a Directed Acyclic Graph 
of parents. I believe reliably updating this structure from the client 
is enormously more complex and error-prone than a simple tree. Also I 
suspect there are desirable window manipulations that cannot be 
described by a DAG and thus even more complex api must be provided in 
Wayland.

Kristin has proposed that nothing be sent from the client to the 
compositor, I think he is worried about the api bloat this may cause.

I feel that an intermediate solution that limits the data to a tree, 
since only a "set parent" api is needed to manage it. When a client 
requests that a window be raised or hidden then this tree causes 
children to do the same. But this is only done after a request from the 
client, so the client can first rearrange or delete the tree in order to 
get the behavior it wants. The main reason for this is that I think it 
is necessary so wayland clients can be displayed remotely on non-wayland 
systems that support such trees, otherwise remote display may be very 
blinky when users raise windows.

Both of these however require that all decisions about window 
relationships be left to the client. There is no way around this, no 
matter how much you want to pretend otherwise.

A client that fails to hide the window after the request and a timeout 
can get force-hidden, if you think this is a problem. But you cannot use 
misbehaving clients as a reason for designing an api, since there are a 
billion other ways a client can misbehave and you are not stopping them 
all with this one api.