<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">Jason Ekstrand wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Yes, in theory they could read the configuration of the compositor. <br> </blockquote> <br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I really don't want to build this kind of inconsistency into the system and I don't see why it's justified.<br> </blockquote> <br></div> I think I see what you are getting at. I think a scheme that allows simple applications to obey the global setting without thinking, but still allows applications that have a good reason to do tricks with the focus, and also matches the raise proposal, is this:<br> <br> - The compositor sends an "I want you to activate" event, as you propose.<br> - The client can respond to this with an "activate" request. Or it could send an "activate" request at other times if it wants.<br> - The compositor responds to the "activate" request by either ignoring it or actually doing the activation.<br> - The compositor sends an "activated" event that the client can respond to by redrawing to show the fact that they are activated.<br> <br> If a client just echoes the "I want you to activate" event then it will work as you expect. A client could also wait after the event until the mouse enters a correct location or clicks on the right thing. It could also try to generate spurious activates but the compositor may ignore them.<div class="im"> <br></div></blockquote><div><br></div><div>I still don't understand why a client would want to not activate. I can see not wanting to raise, but why not activate?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class="im"> <br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I agree with you here, we have that exactly same use case in EFL. Not<br> being able to set where the transient surface will be is going to<br> prevent us to implement that behavior. Unless some other kind of<br> surface should be used for this purpose.<br> <br> 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).<br> </blockquote> <br></div> The location of transient windows is *relative* to the parent's transform, not absolute.<br> <br> There are already proposed and implemented apis to discover if a rectangle in the parent's space is clipped by output edges and panels, so a client can choose a different rectangle.</blockquote><div><br></div><div>See below for an idea on how to make this happen.<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br> <br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br> </blockquote> <br></div> Yea I give up on this as well, and relative transforms of transient windows avoids this problem for now.<div class="im"><br> <br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br> </blockquote> <br></div> I think this will have to be a bunch of flags or you will end up with 2^N different window types. Flags I can see:<br> <br> - Locked transform (whether the window moves when the parent does)<br> - Show in task bar (I'm not convinced this is ever wanted)<br></blockquote><div><br></div><div>Why not? Maybe we're missing each other on this one. By "show in task bar" I don't mean as a tray icon. I mean that it's toplevel and it shows up as an independently user-activateble window. In windows, this means it has a button in the task bar. In gnome shell, it shows up in the list of windows when you right-click a dock icon. In KDE it shows up in whatever they call their task bar. However, I think this is covered by toplevel (which I think we should keep.)<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> - Show in thumbnail (may be same as locked transform?)<br> - Whether it is a subsurface, or a window, or a window above the panels.<br> - Clipped to parent (this has been requested a bunch and may be necessary if client cannot absolutely control the location).<br> - Grab<br></blockquote><div><br></div><div>You raise a good point here. There is a real possibility that we will end up with too many different window types. It does seem somewhat reasonable to have "toplevel" and "transient" and let grab symantics, parent position locking, etc. be flags. We already have a bunch of flags for toplevel windows such as maximize/fullscreen, etc.<br> <br></div><div>*if* we decide to go with flags, I would recommend a set_relative_position request and an unset_relative_position. Attaching a buffer with a non-zero x and y would change the position but otherwise leave the lock intact. The xdg_shell.move request or anything similar would automatically release the lock. Does this seem reasonable? Another option would be to just set it at (0, 0) relative to the parent and use the next buffer attach to determine the position.<br> <br></div><div>All this being said, I don't think it's a stopper. As I discussed with Rafael on IRC, as long as we remove the position arguments from set_transient, we can always add these flags later. So I don't think this needs to get solved before he starts implementing.<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> The current grab I don't like. It seems that the surface is always unmapped on a click outside it. Also there is an entire somewhat parallel grab mechanism for normal surfaces. I am pretty certain this can and should all be merged. A popup transient would be a normal transient except the client also grabs the pointer. Losing the grab would work like Windows (if press + release are both outside the grab surface then the grab is cancelled after the release is delivered to the client).<div class="im"> <br></div></blockquote><div><br></div><div>I'm not 100% familiar with all the issues here. I'll look into it more.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class="im"> <br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br> </blockquote> <br></div> This sounds identical to what I want.<div class="im"><br> <br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br> </blockquote> <br></div> As I see it, the client can change the tree all they want with no visible effect (even though the current stacking may be "wrong"). The only thing the tree does is that when a raise happens, it also atomically raises all child surfaces along with it. Thus the raise acts as the "commit".<br> </blockquote></div><br></div><div class="gmail_extra">Yup, I think we agree on both of the above two.<br></div></div>