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

[Rafael Antognolli]

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 <spitzak at gmail.com> 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.

> 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.
>
>
>>  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.

> 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.

Transient and popup surfaces have another semantic meaning, they are
more like real windows.

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.

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



-- 
Rafael Antognolli