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

[Gregory Merchan]

On Tue, Nov 5, 2013 at 1:47 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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.

Now I understand what you meant by "atomically" in a previous message.

I don't know near well enough how Wayland actually works, so let me
see if I can elaborate the differences between what we've described.
I'm going to assume that somehow the client knows that it should not
reject the compositor's request; for example, the user has changed the
viewport and the client is the one the compositor believes should be
activated. I'll call the compositor 'W' and the client to be activated
'A', the client to be deactivated 'Z'

Viewport change as described by Bill:
W to A: Request activation.
A to W: Activate me and do these things, or don't activate me at all.
W to Z: (1) You are deactivated; (2) Nothing.
W to A: (1) You are activated (and by other events or by implication
everything is done.); (2) You are not activated (and by implication
those things are not done.)

If A was not activated, the compositor does the same with B, C, D, . .
.. Z only receives the deactivation event when another client has
accepted.

Do I describe what happens to Z correctly?

Viewport change as described by Greg:
W to Z: You are deactivated.
W to A: You are activated.
A to W: Do these things.
(By events or by convention everything is done.)


I believe the compositor to client request must include a reason for
the request if the client is allowed to completely refuse, so that it
does not refuse in reasonable events like viewport changes. I think
this makes things needlessly complicated.

On the other hand, if the client must make the request, it doesn't get
complicated. The request and other changes can still happen
atomically. (This, incidentally, is how I believe globally active
clients on X11 should be treated. The WM_TAKE_FOCUS message should
only be sent when the client should not refuse focus because it would
mess up normal operations. Window managers should not grab buttons in
the client area, because the client knows best how to handle button
presses and it should interpret the WM_TAKE_FOCUS message as being
from events it knows nothing about.)


>> 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.

Here we're just describing different systems, as explained above.


>>> 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.

I suspect the cost of the freedom to reject activation is too high,
but the cost of letting the client specify how to be activated is not
too high. (Basically, what I said above.) This is just an impression;
I haven't tried to lay it all out enough to even say it's my opinion,
much less than to assert it is so.


>> 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.
>
>
>
>