On Tue, Nov 5, 2013 at 4:31 PM, Bill Spitzak <[email protected]> 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. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
