Fwd: [PATCH weston] xdg-shell: Make stable

[Bill Spitzak]

On 07/18/2014 11:41 AM, Jasper St. Pierre wrote:
> On Fri, Jul 18, 2014 at 2:26 PM, Bill Spitzak <spitzak at gmail.com

>     I see no reason this can't be called "show" or "raise".
>
>     The *creation* of a surface does not mean that the compositor must
>     show it. It could add a blinking "attention needed" task bar entry,
>     just like this action. And the Kate editor is actually expecting
>     "the same result as a new window", not "the window becomes visible".
>     Therefore the request that is really wanted is "do something much
>     like what happens when a window is first created".
>
> That's not true. If Kate destroyed and recreated the window, the window
> would suddenly appear on a different workspace. In the existing case,
> Kwin immediately switches to the workspace of the window.

I don't see any reason a compositor could not decide to make both of 
these match. For instance creation of a window could put it on the same 
workspace as the last window the client had. Conversely, this request 
could move the window to the current workspace, rather than switch 
workspaces.

>     I would add an event id to the request, so the compositor knows what
>     event (if any) triggered it. This same request would be used in
>     several situations, and the event and whether the window is visible
>     can be used by the compositor to change the result:
>
> I have no idea what an "event ID" even is. We could add a timestamp or a
> serial, and that's something we've discussed doing.

What I meant was some way for the compositor to know which event it sent 
the client that this is in response to. I think it is called a serial in 
wayland. It is already used this way for the resize requests.

>     2. Clients use it to raise windows on clicks (note: the compositor
>     CANNOT implement "raise on click" itself. If you think it can you
>     are wrong).
> Please stop derailing the thread with unrelated topics.

My point is that this request also absorbs any meaning of "raise" and 
there is no reason to make it be a different request than that. If 
different behavior is wanted between "raise" and "show" the compositor 
can distinguish them by whether there is an event in the request and 
whether the surface is visible.