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

[Gregory Merchan]

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

I think the API for marking surfaces transient or otherwise secondary
will obviate some potential glitches. For example, I think most
thumbnailing window switchers I've seen just ignore transients.


>> 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 don't think that's a good assumption to make, because I know I won't
be using sloppy focus and I'll then be seeing multiple redraws from
assuming clients responding to crossing events.


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

I think this is a disagreement, but it can be accommodated on Wayland
because I'll just make sure I use a compositor that rejects crossing
event requests. (A similar policy on X would be a mess for me, because
I could not then avoid sloppy 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...)

I think I'll have to just think about this for a while. I personally
don't like sloppy focus because I believe a better system can be built
when it is not allowed, but a system with fine-grained sloppy focus
would be very different from any I've considered. This last request
for a description was more personal curiosity than relevant to
Wayland.