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...)
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
