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

[Jason Ekstrand]

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.


>
>  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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131023/a4b483eb/attachment-0001.html>