On Wed, Oct 23, 2013 at 03:20:52PM -0500, Jason Ekstrand wrote: > On Tue, Oct 22, 2013 at 10:46 PM, Bill Spitzak <spit...@gmail.com> wrote: > > > On 10/22/2013 05:59 PM, Jason Ekstrand wrote: > > > > I see what you mean here. However, I think apps doing this will cause > >> more trouble than it's worth. One thing about current sloppy focus > >> implementations is that you can click anywhere in the window to raise > >> it. You want to change this. However, what happens if that window is > >> partially obscured. In your scheme, you would have to move the window > >> so that the magic text box is uncovered in order to raise it. As is, if > >> I want to see said text box, I click the window to raise it so I can get > >> to the text box. > >> > > > > Yes, I agree it would be nice if you could select text without raising > >> the window. However, I'd still like a way to raise it without having to > >> click a particular region. That's an interesting UI problem > >> > > > > I think the clients can raise if the user clicks on a "dead" area where > > the click serves no purpose. The most obvious is the window borders, but > > also gaps between widgets and widgets that don't use click for anything > > could raise the window. > > > > It would still be possible for all the visible area of a surface to be > > covered with buttons so there is nowhere to click to raise it. If this is > > really a problem then perhaps the user holds down some shift key and clicks? > > > > > > Perhaps we could allow for some more flexibility if there was a way for > >> the client to reject an activation. However, I still have the above > >> fears. > >> > > > > Absolutely a client must be able to "reject an activation". This would be > > just like raise and focus: the compositor can only send a request event to > > the client. The client must respond with an activate request if it really > > wants activation. > > > > However I think this may mean there is no difference between activation > > and having a particular seat's keyboard focus. > > > > > At this point, I think I can propose a solution which should allow for > client control while still keeping the compositor in control: > 1) The xdg_surface has a pare of activate/deactivate events. I think we > need more than keyboard focus here because the user may not have a physical > keyboard. > 2) A request_raise event to which the client *can* respond with any number > of raise requests. > 3) Both the request_raise and the activate events have a serial. If the > event corresponded to some user input (such as a mouse press) then the > serial will match that of the input event. Otherwise, it will have its own > serial.
4) Inter-surface-commit for making sure the client can raise a group of windows atomically (?) Jonas > > > > > > Yes, I like this. I don't think it's feasible to try and keep some > >> crazy DAG. As long as a client can atomically raise a bunch of windows > >> we should be ok. A tree, whether or not it persists after the raise, > >> will accomplish this. > >> > > > > I think if the tree does not persist then it is identical to the "client > > does a lot of raises atomically" version. This is however a possible > > solution. > > > > The only reason for the tree is so that other clients can examine it and > > get some ideas about the relationship between surfaces. And also for > > familiarity with other window systems. I think it may also be useful for > > RDP to other window systems which may not have atomic sets of raises. > > > > I believe these child surfaces and "subsurfaces" are > >> EXACTLY the > >> same thing. > >> I still don't think these *should* be the same. I understand that the > >> semantics are similar, particularly for popup windows. That said, > >> Kristian has talked about removing the coordinates from "transient". > >> > > > > Not clear what he is getting at there. If the client can't position a > > popup menu in the correct location it is pretty useless. I suspect he is > > using a different definition of "transient" than I am. > > > > > Ok. I think I may be understanding transient windows better now (or maybe > have come up with a good definition). I think it's best seen in comparison > to toplevel windows. A toplevel window is "primary" in the sense that you > expect it to have a button in the task bar, want it to show in expose, etc. > A transient window, on the other hand, is one that is peripheral such as a > dialogue box or the floating toolboxes in GIMP. You don't want every > transient window show up in expose mode or in the task bar. In fact, you > don't want it to show up except in relation to another toplevel window. > > That said, it is a very different concept to subsurfaces. In particular, > the client should not be able to always know where it is nor should it set > it's location relative to another window directly. (This is different from > popups). > > Given this understanding of transient windows, I'm less convinced that we > need a window raise tree. I don't see a reason why the client would want > to raise more than one toplevel window at any given time. It should be > able to just re-parent the needed transient windows and raise the toplevel > one. (or, for that matter, just raise a transient window). The only issue > here is that it needs a way to "commit" the tree so that it can re-arrange > things atomically. If we simply make re-parenting of transient windows not > apply until a raise, we can get atomic. > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel