[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
spitzak at gmail.com
Tue Nov 5 23:31:56 CET 2013
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
> 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...)
More information about the wayland-devel