[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

[Jonas Ådahl]

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
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel