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

[Gregory Merchan]

On Mon, Nov 4, 2013 at 3:41 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Gregory Merchan wrote:
>
>> As Bill mentioned in a follow-up, drag sources would want to not activate.
>
>
>> This can be handled more simply than described above, without a
>> special "activate" system. I assume "activation" applies to a window,
>> not a client.
>
>
> I believe you are describing the system I was thinking of, where Alt+Tab,
> etc, are done by the compositor directly activating clients, while
> point-to-type and click-to-type is entirely the client's responsibility, in
> that they activate themselves (and thus can decide that a click or mouse
> movement should *not* cause an activation).
>
> Jason Ekstrand's complaint about this is that it takes whether the system is
> set to "point to type" or "click to type" out of the compositor's control.
> Therefore he would like some kind of communication from compositor to client
> saying "you probably should activate now". I think this might also be an
> indication of "the compositor will not ignore an activate from you now".
> Point-to-type would do this on mouse enter, click-to-type on mouse clicks.
>
>
>> 1. PointerRoot: Activates a window when the pointer enters it and
>> deactivates it when the pointer leaves.
>
>
> I think this can be ignored and only sloppy implemented. There is no
> difference if the entire screen is filled with non-desktop clients.
>
>
>> 2. Sloppy: Activates a window when the pointer enters it.
>
>
> This is equivalent to "the desktop does not activate when the pointer enters
> it". I would like all clients to have this ability, not just the desktop.
>
>
>> 5. Windows/MacOS-style: Does not activate a window, except as it does
>> for all policies.
>
>
> Not sure what you mean here. Windows is pretty much the same as X
> click-to-focus. OS/X "eats" the click that activates the application, but I
> believe this is entirely done by the client, and a client could in fact
> respond to the click if it wanted.

Bill, I think you misunderstood what I was trying to do here. I was
describing the various systems that have existed in the way I
understand them which I believes frames the issues so all can be
satisfied. Yes, you and I have reached the same conclusions about some
of this, but I think it's important to lay everything out there,
including the rare PointerRoot policy, so everyone can see what's
going on; I believe the similar issues on X have languished because no
one has been willing to step back far enough to get a good look at
things.

Regarding number 5, I should have been more specific in naming the
style. It is, judging from the Cocoa APIs, the policy of MacOS, but
not of MS Windows. I forget Windows does not do this because (it
seems) they made a special case for Explorer, so that it does not
raise a folder window when a drag may begin; I've never known any
other Windows application to not raise a window on mousedown which may
begin a drag.


>> For each of these policies, another distinction may be made according
>> to signature required to honor an activation request.
>
>
> The compositor is totally allowed to ignore any activation request. The most
> common reason is because another client has activated itself based on a
> later event.

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.)
2. The policies may be distinguished first by additional cases in
which they set focus without exception. (The five I mentioned.)
3. Second they may be further distinguished by how they allow clients
to set focus. (Client request filtering based on a signature.)

The order of the last two could be flipped, but I think the taxonomy
is tidier this way. I would personally prefer the 5th policy, but a
lot of people think we must have one of the first 4; the 5th policy
could have been implemented on X, but in almost 20 years no one has
done it.


>> For example, this allows an
>> active program to activate a dialog, but prevents other programs from
>> activating any windows.
>
>
> This is not a problem. In Wayland it is *clients* that are activated, not
> "windows". The client is free to draw highlights and blinking cursors and
> anything else so that the user thinks some particular transient window has
> the keyboard focus, but the compositor is unaware of this (though info may
> leak due to the input method text cursor position?).
>
> It may be useful for a client to tell the compositor which surface it thinks
> is active, so that pagers can perhaps highlight this info. This should be
> allowed if the client is already active, but has zero effect on the behavior
> or events delivered by the compositor.

It was my impression from this discussion that "active" does not yet
have a meaning.


>>  To my knowledge, both Windows and MacOS already require
>> applications to request activation in this way
>
>
> 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.)


> I don't know about OS/X.
>
> In any case what you want is the way Wayland should work, no matter what
> Windows and OS/X really do.

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


>> I have said nothing about stacking. Handling activation as I have
>> described allows for every kind of stacking behavior I've seen, except
>> for one: raise on frame clicks, but not on clicks within the frame.
>
>
> The client must be entirely and 100% in control of stacking. No window
> should ever raise unless the client has explicitly sent a raise request.
> This must be true otherwise you will have to add the nightmare of a
> continuously updating directed acyclic graph of surface relationships, which
> would probably double the size of the Wayland api.
>
> Therefore raising on frame clicks only (or any other subset of the surface)
> is trivial and the client's responsibility.

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 left stacking out because it is more complicated, and my message was
already long enough. Before compositors, it was really simple because
things like menus and tooltips could just be ignored. Now we expect
menus to have shadows and I don't know what for tooltips, so more
information has to be conveyed between programs.

I believe that the easiest and maybe best stacking policy is that the
compositor only raises windows in response to requests from the active
client. (Which, I think is what you meant, Bill.) But I think this can
be decided separately from the question of how windows are activated
and receive keyboard focus.


>> This exception exists when the compositor is not responsible for
>> drawing the window frame, because nothing I have described allows the
>> compositor to distinguish between parts of the client window.
>
>
> 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.

Let me see if I can put it another way:

"Handling activation as I described it allows for every kind of
stacking behavior except those kinds in which the compositor must be
aware of the contents of the client windows."

Got that? I'm bolstering your case. Stop yelling.


> Remote display on servers that require the server to add borders will just
> not do the raising correctly. Hopefully it can be simulated reasonably well
> since it will at least have the window tree and it won't change too often,
> and the user can find and raise windows by clicking on the borders for the
> few cases where it screws up. I would not waste development time on trying
> to improve this.

Jason has posted patches for frames in Wayland. I don't know what's
going on there because there's no public discussion I can find, and I
thought one reason for Wayland was to get away from that. In any case,
I'm at least aware of something going on, so I give it a passing
mention.


>> I believe a simple stacking policy would be to allow a client with an
>> active window to do anything it wants with its windows within the
>> bounds set by other features; basically it can do anything as long as
>> it doesn't put windows below stay-on-bottom features, like the
>> desktop, or above stay-on-top features, like task bars and menus.

Oh. I guess I'm repeating myself and didn't leave out as much as I
thought I did.


> IMHO the only actions the client needs are to be able to "raise" a surface.
> The compositor will choose exactly what this means, though it probably means
> to put it at the top of all similar surfaces. The client must also be able
> to set the window tree, and this means that the compositor should treat a
> raise of a parent as being immediately followed by a raise of each child
> surface, and perform all this atomically.
>
> I suppose there is a need to "lower" a surface which is what clients might
> do in response to a middle mouse click on a window border to match many X
> window managers. Though this might be the "deactivate request" that was
> suggested. I don't think users use this except as an equivalent to alt+tab.

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