[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
jadahl at gmail.com
Wed Oct 23 23:03:30 CEST 2013
On Wed, Oct 23, 2013 at 03:20:52PM -0500, Jason Ekstrand wrote:
> On Tue, Oct 22, 2013 at 10:46 PM, Bill Spitzak <spitzak at 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
> 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
4) Inter-surface-commit for making sure the client can raise a
group of windows atomically (?)
> > 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
> 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 at lists.freedesktop.org
More information about the wayland-devel