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

[Bill Spitzak]

Gregory Merchan wrote:

>> - The compositor can send a "activate request event" saying that it would
>> like the client to activate.
> 
> That is not what I described, mostly because I kept the new things to
> a minimum. It seems I hinted at but failed to explicitly mention what
> serves much the same purpose: the activation event could provide the
> signature for client activation requests. The hint was in my
> description of the convention for valid timestamps [ 4) a window
> manager message ]  on X11, but I failed to mention an analog when I
> spoke of signatures in terms of Wayland events. This allows a client
> with a compositor-activated surface to instead activate another
> surface, but does not allow a refusal of activation except to make the
> surface incapable of activation, for example by destroying it.

Okay I think I understand now. Your scheme there is only 
activate/deactivate events and an activate request from the client. I 
think it will work and getting rid of 1/3 of the api (the activate 
request event) is a huge win.

Since the client is entirely in control of the appearance of it's 
surfaces, it can make it look like any surface is activated, without 
glitches. It can then correct the compositor's pov by telling it with an 
activation request of the correct surface. If the compositor has some 
kind of pager/thumbnail display with some highlighting showing the 
active surface it might be momentarily wrong but maybe those glitches 
are ok.

> It is perhaps insufficient to have the compositor request that the
> client make a request without providing a reason for the compositor's
> request. The client would need to know if it being asked to activate
> itself because of Alt+Tab-like switch, viewport changes, or any of the
> other reasons a compositor might make the request of a client. This
> probably means another enumeration needs to be defined, and how might
> that enumeration grow?

I think/hope it is not necessary to distinguish these. My concern about 
compositors sending activate request events on mouse enter and clicks 
and the clients needing to distinguish these from alt+tab. But these are 
not sent under what you are proposing.

> I don't know about "atomically combining", but I did describe an
> activation request.

It may not be necessary to atomically combine under what you propose.

> A "deactivate event" is not what I described; sending such an event is
> negating, not ignoring. What I have described leaves the client
> unaware that its request has been declined.

I would like a client sending an activate request to be able to assume 
it is going to get the activation and update all it's surfaces as though 
it had them, this will avoid one redraw and remove one round trip before 
the screen is updated. But this will require that it get some indication 
of failure so it can fix the display when this does not work.

> I think it's overstating to say I've put forth such a proposal. I
> indicated some possibilities and my preference, but I was trying to
> avoid putting forth a complete proposal. I was hoping to avoid what
> you describe as my proposal for parity with X, on which conventional
> clients do not use crossing events to request focus.

I think we are in agreement about what we want, just misunderstanding 
each other. Clients *will* use the crossing events to request focus.

The fact that the client gets to decide whether it is click-to-type or 
point-to-type is not a problem IMHO. It may even be a feature. There was 
some resistance to that which got my discussion here very confused by 
trying to come up with a scheme where the compositor decides.

> What you've described regarding sloppy focus--specifically, clients
> that might activate only when the pointer is in a particular
> control--is something I've never even seen suggested before. I think
> it might be helpful if you provided a description of how a system with
> such fine-grained sloppy focus would work and what the benefits would
> be over other systems.

If the "desktop" is a normal client then it has to have a way to say 
that the mouse pointing at it does not take focus. If there is a text 
field displayed (like if you started to rename an icon on a typical 
Windows-style desktop) then it may make sense for the area of this icon 
to take focus.

Also a rooted nested window manager could itself do sloppy focus where 
the cursor has to point at one of it's windows, rather than the desktop, 
to take focus away from one of the outside windows.

Some clients uninterested in text input (like a video player) may want 
to require click-to-type (this then gets into how the video transport 
keys are managed...)