[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

[Bill Spitzak]

Gregory Merchan wrote:

> As before, I'm just laying it all out there. Brief summary:
> 
> 1. All window management policies set focus without exception in
> certain cases. (E.g. Alt+Tab, viewport changes.)

No. All the compositor can do is send a focus-request-event to the 
client. The client is allowed to ignore it. The compositor has to 
support this anyway because the client may be dead and not responding to 
the focus change.

The reason is so that the client can atomically make changes to it's 
display, window stacking, and visibility of windows to match the current 
focus. This is a Wayland design requirement ("glitch free update") and 
there is no way to do this unless the client has final say.

> 2. The policies may be distinguished first by additional cases in
> which they set focus without exception. (The five I mentioned.)

The compositor is not allowed to "set focus without exception". However 
the "policies" could be distinguished by when the compositor sends 
focus-request-event. It is also possible that the "policy" must be known 
by the client.

>> Windows has an elaborate kludge. Basically it acts like X in that clicks
>> always activate applications. However if the application manages to do the
>> right system calls so that Windows thinks something is being dragged it then
>> undoes the activation. This can botch up if the other active app dies just
>> at this moment.
> 
> Have you found a way to do it one Windows? I searched the API I could
> find and saw nothing, hence I suppose it's a private thing for just
> Explorer. (Or whatever their file manager is called.)

You may be right that it is a hidden API used by Explorer. I never found 
a way. However it is very easy to make *no* clicks raise a window by 
just not calling the "dispatch" function. I have not found any way get a 
working application by calling "dispatch" sometimes (it seems if you 
miss one call it ignores all others). But I felt this was close to a 
working approach.

> As the developer of a cross-platform toolkit, I would think you would
> appreciate as much parity as possible between platforms. I know I've
> seen comments in at least one toolkit's code where a developer
> grumbled about some difference between systems that required extra
> work or weird hacks. (I think it was Gtk, but the comment is not where
> I remember it being.)

What I would like is for Wayland to allow maximum freedom for the client 
to anything it wants. This then reduces the toolkit writers' pain to 
only the *other* platforms, since they can simulate any result they 
achieve there on Wayland.

In particular a client must be in absolute total final control over the 
window stacking and visiblity and must be able to make it look like the 
keyboard focus is on any window as long as the compositor thinks it is 
on some window belonging to the same client.

> Our notions of "entire and 100% in control" are different. For me that
> would mean a client can raise its windows above all others any time
> for whatever reason, or, in a word, chaos.

I mean that a window is not raised (or mapped or unmapped) unless the 
client requests it. This is so that it is impossible for the compositor 
to place windows in a stacking order different than the client wants.

The compositor is allowed to ignore requests. I hope this will be 
designed to be very lenient, with the primary design goal to prevent 
hostile clients, rather than trying to enforce user interface rules. But 
the boundary is pretty vague.

>> No this is absolutely irrelevant. The compositor NEVER NEVER NEVER raises a
>> surface unless the client requests it. Therefore it does not need any
>> knowledge of the areas of the surface!
> 
> I'm inclined to NEVER NEVER NEVER respond to any email that puts
> anything in all caps, especially when the person yelling hasn't
> understood what I've said.

Sorry. However I am very concerned with any proposal that sounds like 
the client does not have final say. This will violate the Wayland design 
criteria of glitch-free update because the client will have to redraw 
and map/unmap/restack windows to "fix" the result after the compositor 
does it.

> Jason has posted patches for frames in Wayland.

I think there will have to be support for compositor-supplied frames, 
but I think the main reason is to support remote display on a legacy 
system where it is impractical to remove the remote display's frames. 
Also the current fullscreen already can tell the client to not draw 
frames so this should be merged. And it may be useful for tiling and 
tabbing and other experimental window management.

The "frame" and "titlebar" should be distinguished. A "maximized" app 
should have a titlebar but no frame (this is currently ignored by 
Wayland and lots of X window managers, I am unclear why people cannot 
see this bug!).

I would limit the api to the compositor being able to tell the client 
whether to draw the frame and titlebar. This may have to be merged with 
the configure request event. And minimal information from the client: a 
UTF-8 window name (null for no frame), an icon surface, and the window 
parenting tree are all you get.

I am not at all happy with KDE's idea to replicate legacy systems 
unnecessarily in a Wayland compositor. To correctly do compositor frames 
an *enormous* amount of crap needs to be communicated from the client to 
the compositor, which like ICCCM and _NET_WM_* will quickly become 
bigger and more bug-ridden than the rest of the Wayland api.

> Lowering below other clients' windows in the space of freely moving
> windows (not desktop, not OSD, not "on the glass" etc.) is probably
> best left to some equally obscure mouse and modifier combination
> handled by the compositor.

I certainly rely on middle-mouse-click on title to lower all the time 
and would not be happy if it is impossible. However it may be acceptable 
if this is done by the compositor move/resize fallback for handling events.

> Rearrange the windows of one's own client
> is shouldn't be a problem. Something like XRestackWindows() comes to
> mind. Of course, that allows the temporary surface trick.

I think a client can get any order it wants by changing the window 
parent tree and then raising the bottommost window that is in the 
"wrong" place. No other api is needed.