On Thu, Oct 31, 2013 at 12:42 AM, Jason Ekstrand <[email protected]> wrote: > Bill, > Because I want to respond to everything in one e-mail, I'm going to try and > address your comments here even though they may not show up. > > On Wed, Oct 30, 2013 at 3:19 PM, Rafael Antognolli <[email protected]> > wrote: >> >> Hi, I'm back to work on this, hopefully this time in a >> non-intermittent way. Some comments below: >> >> On Thu, Oct 24, 2013 at 12:00 AM, Bill Spitzak <[email protected]> wrote: >> > Jason Ekstrand wrote: >> > >> >> 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. >> > >> > >> > How does a client request an activation? And can it refuse an activation >> > from the compositor? Here is the sequence I see: >> > >> > - Compositor sends some kind of "I want you to activate" to client >> > - Client (if it wants to activate) sends an "activate" request. Clients >> > can also do this in response to mouse/key events without an activate >> > from >> > the composiitor. >> > - Compositor sends a "lost activation" to previous active client, and a >> > "gained activation" to the new client. >> > >> > As I see it the only reason the compositor will send the first event is >> > due >> > to global shortcuts like Alt+Tab or some pager application, and >> > destruction >> > of the current active client. If clicks or hovering is going to activate >> > a >> > client, it is the client's responsibility to implement it. >> >> I'm sorry, but I fail to understand how a user could choose between >> click to focus, or sloopy focus, if that's up to the client to >> implement it. Wouldn't this lead to something like: if I use this >> video player A, but it only implements sloopy focus, and I want click >> to focus, I have to change to some other video player B? >> >> Again, sorry for my ignorance, I might have not completely understood >> your point. > > > Yes, in theory they could read the configuration of the compositor. > However, that's even more configuration syncing that we have to do and > anything other than the major 3 toolkits (Qt, GTK, and EFL) probably won't > bother. They'll simply implement whatever focus model is easiest (or liked > by the developer) and they certainly won't go searching for special globals > and looking for config files for every compositor/toolkit. I really don't > want to build this kind of inconsistency into the system and I don't see why > it's justified.
Yes, either implementing the easiest, or the one that they think it makes more sense. Or, if they do want to read configuration and implement everything correctly, it will be a lot complexity. On the other hand, the compositor having the logic of when it should focus a window, and sending such event to the client, simplify things in the client. But that does not prevent the client to request focus at any time, when a mouse movement is detected, or some other kind of event. Which kind of gives flexibility to the client to implement any special behavior. > Also, why is a client, out of the blue, trying to take the focus? The > compositor is going to have focus rules to prevent bad clients from doing > nasty things anyway. Why not have the compositor tell the client when it's > allowed to have active. This could be as simple as an activate request with > a take_active response. Concerning semantics, I expect the activate request > to be sent whenever an event occurs on a non-active client that the > compositor deems activation-worthy. This could include pointer enter, > pointer button, keyboard key, or nothing client-discernible at all > (alt-tab). OK, I wasn't thinking about anything to allow/prevent a client to take focus, but that can be done too. Do you think we can go with a simpler approach (not preventing anything), and add that later, just to finally start things and have something working soon? > I would expect raise to act the same way (but I don't think we're debating > that one as much. > >> >> >> > I still feel it is going to be identical to the keyboard focus for some >> > seat. A seat can have a focus even if it has no keyboard. >> > >> > >> >> 2) A request_raise event to which the client *can* respond with any >> >> number of raise requests. >> > >> > >> > Again exactly the same sequence. The compositor can send a "I want you >> > to >> > raise" to the client, which it *can* respond to with raises. The client >> > can >> > also raise itself in response to events. There probably does not need to >> > be >> > feedback to the client whether the raise worked. > > > I think we agree here. The compositor will have its own rules about when > the client can actually raise. However, it should be able to re-order its > own windows at any time. This looks good to me. >> >> > >> > >> >> 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. >> > >> > >> > Yes. The compositor must be able to tell what event caused the client to >> > make the request. It can then ignore them, and solve race conditions >> > with >> > multiple clients. >> > >> > >> >> 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). >> > >> > >> > Having written some applications, I absolutely want complete control >> > over >> > where transient windows appear!!!! They must appear in correct positions >> > relative to the mouse cursor and to not obscure important information in >> > the >> > main window. Also it is very useful to make fancy transient tooltips >> > that >> > are hovering windows with pointers and that is not going to work if I >> > can't >> > make the pointers point at things! >> >> I agree with you here, we have that exactly same use case in EFL. Not >> being able to set where the transient surface will be is going to >> prevent us to implement that behavior. Unless some other kind of >> surface should be used for this purpose. > > > One thing worth noting here is that the client doesn't know where the window > is, so it can't always properly place these transient windows (in the case > of toolboxes). I know, Bill, that you have advocated many times in the past > that the compositor give the client the full transformation matrix of the > window at all times. However I don't think this is going to happen. It > wasn't my decision. Let's not start that argument again here. If we want > to restore window positions (and I would like that eventually), I think we > can come up with some way of doing so that doesn't make the compositor slave > to the clients. I don't agree with this, but fine, let's do the simplest first. So, what about this: I add only the expected surface types (toplevel, transient, popup), transient should have no way to set its position. Later, if we find it necessary, we can either add a new type, or add an API to set transient's position? It would at least postpone this discussion, or maybe we even move it to another thread, specific to this topic. > Now, concerning other pop-up type things such as tooltips, speech bubbles, > arrows, etc. Perhaps they aren't the same as a standard transient window. > I would want a toolbox to not show up in a task bar (not toplevel) but to > also move independent of its parent. Perhaps there is another category in > here. Maybe we want four types: toplevel, transient (toolboxes etc.), > tooltip (position relative to parent), and popup (tooltip + grab semantics). > It would be good to talk to Giulio Camuffo about this as he spent quite some > time banging his head on menus in Qt. > >> >> >> > If the client tells the compostor to drag a window (due perhaps to a >> > mouse >> > drag started in the window border) it is probably ok that the client >> > does >> > not know where the window ends up (though it is really annoying because >> > it >> > prevents clients from saving their window layouts). >> > >> > Also I see no reason that the client can't tell the compositor to drag a >> > subwindow as well. You are not convincing me that there is any >> > difference, >> > the more I look at it the more I am convinced that these concepts MUST >> > be >> > merged so that they each don't lack useful abilities the other ones >> > have. >> >> I *think* that the reason behind it is that they have >> specific/specialized usage. Subsurfaces are specially for rendering >> things not in the main surface, but still merged in the same "window", >> so that the user would not see a difference, and have no way to know >> that there's another surface in there. > > > Yes! In particular, subsurfaces are a compositor-wide thing, where as > popup/transient/tooltip is entirely a *shell* thing. Perhaps in some > compositor there is no distinction. However, just because they look similar > in the scenegraph does not mean they are the same. > >> >> >> Transient and popup surfaces have another semantic meaning, they are >> more like real windows. > > > Yes, they are real windows. This also tells the compositor that the surface > is not actually part of the window. For instance, it may not want to render > menus/tooltips in an expose mode. However, subsurfaces would have to get > rendered in that mode because they are part of the original surface. > >> >> >> For a subsurface, there's no big reason to grab mouse pointer and so. >> On the other hand, it wouldn't make sense to synchronize the commit of >> a transient window with the one from a toplevel surface. At least from >> our toolkit point of view (EFL) it would make things more complicated >> IMHO. >> >> Of course they could all be merged, but then we would just end up with >> a big generic one surface to rule them all. Not sure if this is >> intended. > > > I really don't think we want one surface to rule them all. There is also a > huge component-separation issue here. I don't want subsurfaces to be 100% a > shell thing and I don't want grab symantics built into subsurfaces (or > window move symantics for that matter). If we couple things too closely, > it's going to make it impossible to implement anything other than a desktop > shell with Wayland. We DO NOT want that! > >> >> >> Though that's only my current understanding, which is quite limited >> about Wayland so far. >> >> >> Given this understanding of transient windows, I'm less convinced that >> >> we >> >> need a window raise tree. >> > >> > >> > I *think* you are saying "there is no reason for the 'raise tree' to be >> > a >> > different tree than the 'parent tree'". This is prehaps why I did not >> > understand what you were getting at. I never wanted more than a single >> > tree, >> > and I thought Kristian was asking whether there should be *one* or >> > *zero* >> > trees. Your email was about whether there should be *two* or *one* tree. >> > I >> > want one, the same as you do, I think. >> > >> > So what I propose I think is the same as you are proposing: there is a >> > single tree (actually a forest), of parent/child surface relationships. >> > The >> > "children" are sometimes called "transient windows", or "popup windows", >> > etc. This both communicates what window is the "parent" and makes map >> > and >> > raise of the parents atomic with the children. >> > >> > If a client really has a reason to make the parenting different than the >> > raising it can temporarily rearrange the tree before doing a raise and >> > then >> > put it back. > > > I'm pretty sure we agree here. I see no reason for 2 trees either. And I > do think we want some sort of a tree. I think it's reasonable to make the > toplevel windows roots (no parent) and make all the other little window > types (popup, transient, tooltip) take a parent parameter which does not > have to be toplevel. However, I would also like there to be some sort of > "commit" operation so it can be don atomically. One idea would be to > simply make that commit operation the same as the raise. That makes sense to me. > Thanks, I hope I addressed everything. I'll try to come up with a protocol spec for that, and we can keep working on fine tuning it if you agree. -- Rafael Antognolli _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
