[Question] Z-order management in Wayland

There is currently no way to influence the stacking order of top-level
surfaces. Why do you need this?

Post by yan.wang
Hi, All,
I found X provides raise/lower APIs to manger window Z-order. But there
isn't related APIs in Wayland/Weston.
May it should be one design idea of Wayland in fact or I could achieve
this by current Wayland protocol?
Thanks.
Yan Wang
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140731/aaf67906/attachment.html>

yan.wang

2014-07-31 08:02:33 UTC

E.g. When we start a new application on mobile platform, previous running
application could be hidden and paused to reduce power consuming
and improve response speed. If we could adjust and get z-order status, we
could callback application to sleep. And when user restart this
application, we could just make this slept app waked up.

Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of top-level
surfaces. Why do you need this?

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Jasper St. Pierre

2014-07-31 08:14:26 UTC

Sure. You can do this from your compositor. Weston has internal APIs known
as "layers", and these control stacking order. To pause the previous
application, you can stop calling the callback used from "frame". This
might require some extra work in compositor.c to not send the callbacks if
they're in a special "paused" layer, but it can be done.

Post by yan.wang
E.g. When we start a new application on mobile platform, previous running
application could be hidden and paused to reduce power consuming
and improve response speed. If we could adjust and get z-order status, we
could callback application to sleep. And when user restart this
application, we could just make this slept app waked up.
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of top-level
surfaces. Why do you need this?

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140731/a5db9a27/attachment-0001.html>

yan.wang

2014-07-31 08:20:32 UTC

Yes. I also think so. But we may need the comments of Wayland maintainer
about this design because it need change the compositor logic.

Yan Wang

Post by Jasper St. Pierre
Sure. You can do this from your compositor. Weston has internal APIs known
as "layers", and these control stacking order. To pause the previous
application, you can stop calling the callback used from "frame". This
might require some extra work in compositor.c to not send the callbacks if
they're in a special "paused" layer, but it can be done.

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of top-level
surfaces. Why do you need this?

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
Jasper
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Pekka Paalanen

2014-08-01 07:20:18 UTC

On Thu, 31 Jul 2014 01:20:32 -0700 (PDT)

Post by yan.wang
Yes. I also think so. But we may need the comments of Wayland maintainer
about this design because it need change the compositor logic.

Already if a surface is not part of any output's repaint (i.e. is not
on any layer that is part of repaint), the frame callbacks will not be
sent.

So if you can put the surface on a layer that is not going for repaint,
it should already work. No changes in Weston core needed.

Then the apps need to realize they are not getting frame callbacks, and
do the necessary clean-ups, if simply stopping repaint is not enough.

Thanks,
pq

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of top-level
surfaces. Why do you need this?

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
Jasper
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Tanibata, Nobuhiko (ADITJ/SWG)

2014-07-31 08:19:27 UTC

Yan,

No way to change order of top-level surfaces in current Wayland
protocol.
If you want to do it, you can extend protocol by yourself and implement
own shell loaded on Weston.

One example is http://projects.genivi.org/wayland-ivi-extension/.
There is a similar use case in In-vehicle Infotainment system regarding
consumption of power.

-----Original Message-----
From: wayland-devel
[mailto:wayland-devel-bounces at lists.freedesktop.org] On Behalf Of
yan.wang at linux.intel.com
Sent: Thursday, July 31, 2014 5:03 PM
To: Jasper St. Pierre
Cc: yan.wang at linux.intel.com; wayland-devel at lists.freedesktop.org
Subject: Re: [Question] Z-order management in Wayland
E.g. When we start a new application on mobile platform, previous running
application could be hidden and paused to reduce power consuming and
improve response speed. If we could adjust and get z-order status, we
could callback application to sleep. And when user restart this
application, we could just make this slept app waked up.
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of

top-level

Post by Jasper St. Pierre
surfaces. Why do you need this?

Post by yan.wang
Hi, All,
I found X provides raise/lower APIs to manger window Z-order.

But

Post by yan.wang
there isn't related APIs in Wayland/Weston.
May it should be one design idea of Wayland in fact or I could
achieve this by current Wayland protocol?
Thanks.
Yan Wang
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

yan.wang

2014-07-31 08:29:22 UTC

Thanks. I will check it.

Yan Wang

Post by Tanibata, Nobuhiko (ADITJ/SWG)
Yan,
No way to change order of top-level surfaces in current Wayland
protocol.
If you want to do it, you can extend protocol by yourself and implement
own shell loaded on Weston.
One example is http://projects.genivi.org/wayland-ivi-extension/.
There is a similar use case in In-vehicle Infotainment system regarding
consumption of power.

running

application could be hidden and paused to reduce power consuming and
improve response speed. If we could adjust and get z-order status, we
could callback application to sleep. And when user restart this
application, we could just make this slept app waked up.
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of

top-level

Post by Jasper St. Pierre
surfaces. Why do you need this?

Post by yan.wang
Hi, All,
I found X provides raise/lower APIs to manger window Z-order.

But

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Carsten Haitzler (The Rasterman)

2014-07-31 08:21:15 UTC

you do NOT want to do this by raise/lower. even doing this in x11 is just
WRONG. in fact a good mobile wm setup would refuse to allow this. there is a
netwm request "netwm activate". this requests the window is activated. this MAY
raise the window. it may switch desktop. it may de-iconify a window. it may
also place focus on the window... unless the wm decides that this is a bad idea
right now.

you do NOT want a raise/lower etc. in wayland. you want xdg shell and an
activate request. the compositor after that decides what is best to do.

Post by yan.wang
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of top-level
surfaces. Why do you need this?

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com

yan.wang

2014-07-31 08:57:44 UTC

Hi, Carsten,
Thanks for your comments.
I check efl code and I found
_ecore_wl_window_cb_xdg_surface_active/deactivate is empty.
As your comments, we should add code into them and pop related Ecore
event out. Is it right?
I could also find ecore_wl_window_raise() in ecore_wl_window.c. It
shouldn't be used?
And I am not sure whether USE_XDG_SHELL macro is enabled in current
Tizen upstream.

Yan Wang

Post by yan.wang
E.g. When we start a new application on mobile platform, previous running
application could be hidden and paused to reduce power consuming and

improve response speed. If we could adjust and get z-order status, we

Post by yan.wang
could callback application to sleep. And when user restart this

application, we could just make this slept app waked up.

Post by Carsten Haitzler (The Rasterman)
you do NOT want to do this by raise/lower. even doing this in x11 is just
WRONG. in fact a good mobile wm setup would refuse to allow this. there

Post by Carsten Haitzler (The Rasterman)
a
netwm request "netwm activate". this requests the window is activated. this MAY
raise the window. it may switch desktop. it may de-iconify a window. it may
also place focus on the window... unless the wm decides that this is a

bad

Post by Carsten Haitzler (The Rasterman)
idea
right now.
you do NOT want a raise/lower etc. in wayland. you want xdg shell and an

activate request. the compositor after that decides what is best to do.

Post by yan.wang
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of top-level
surfaces. Why do you need this?

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
------------- Codito, ergo sum - "I code, therefore I am" --------------

The Rasterman (Carsten Haitzler) raster at rasterman.com

Carsten Haitzler (The Rasterman)

2014-07-31 09:32:58 UTC

yes - i don't know if the xdg shell protocol does this request at the moment -
but ultimateley it should as this is part of xdg standards to begin with and is
the "right way". it's what apps etc. really want. not a raise or layer change.

Post by yan.wang
I could also find ecore_wl_window_raise() in ecore_wl_window.c. It
shouldn't be used?

it'll only end up having an effect between subsurfaces. it won't do what you
want.

Post by yan.wang
And I am not sure whether USE_XDG_SHELL macro is enabled in current
Tizen upstream.

i think not. i am not even sure about upstream atm - busy with lots of other
stuff and wayland work is understaffed.

Post by yan.wang
Yan Wang

Post by yan.wang
E.g. When we start a new application on mobile platform, previous running
application could be hidden and paused to reduce power consuming and

improve response speed. If we could adjust and get z-order status, we

Post by yan.wang
could callback application to sleep. And when user restart this

application, we could just make this slept app waked up.

Post by Carsten Haitzler (The Rasterman)
you do NOT want to do this by raise/lower. even doing this in x11 is

just

Post by Carsten Haitzler (The Rasterman)
WRONG. in fact a good mobile wm setup would refuse to allow this. there

Post by Carsten Haitzler (The Rasterman)
a
netwm request "netwm activate". this requests the window is activated.

this MAY

Post by Carsten Haitzler (The Rasterman)
raise the window. it may switch desktop. it may de-iconify a window. it may
also place focus on the window... unless the wm decides that this is a

bad

Post by Carsten Haitzler (The Rasterman)
idea
right now.
you do NOT want a raise/lower etc. in wayland. you want xdg shell and an

activate request. the compositor after that decides what is best to do.

Post by yan.wang
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of

top-level

Post by Jasper St. Pierre
surfaces. Why do you need this?

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
------------- Codito, ergo sum - "I code, therefore I am" --------------

The Rasterman (Carsten Haitzler) raster at rasterman.com
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com

Manuel Bachmann

2014-07-31 20:06:09 UTC

Hi Yan,

"And I am not sure whether USE_XDG_SHELL macro is enabled in current
Tizen upstream."

It is enabled by default. If you download a sufficiently recent snapshot of
Tizen Common or IVI (I recommend from 2014/06/20 so you can have Weston
1.5.0), and click on the "Minimize" button of a random EFL application, it
will in fact minimize the window with "xdg_surface_set_minimized()". It is
a good way to check if this macro was enabled.

Regards,

Post by yan.wang
Hi, Carsten,
Thanks for your comments.
I check efl code and I found
_ecore_wl_window_cb_xdg_surface_active/deactivate is empty.
As your comments, we should add code into them and pop related Ecore
event out. Is it right?
I could also find ecore_wl_window_raise() in ecore_wl_window.c. It
shouldn't be used?
And I am not sure whether USE_XDG_SHELL macro is enabled in current
Tizen upstream.
Yan Wang

Post by yan.wang
E.g. When we start a new application on mobile platform, previous

running

Post by yan.wang
application could be hidden and paused to reduce power consuming and

improve response speed. If we could adjust and get z-order status, we

Post by yan.wang
could callback application to sleep. And when user restart this

application, we could just make this slept app waked up.

Post by Carsten Haitzler (The Rasterman)
you do NOT want to do this by raise/lower. even doing this in x11 is

just

Post by Carsten Haitzler (The Rasterman)
WRONG. in fact a good mobile wm setup would refuse to allow this. there

Post by Carsten Haitzler (The Rasterman)
a
netwm request "netwm activate". this requests the window is activated.

this MAY

Post by Carsten Haitzler (The Rasterman)
raise the window. it may switch desktop. it may de-iconify a window. it

may

Post by Carsten Haitzler (The Rasterman)
also place focus on the window... unless the wm decides that this is a

bad

Post by Carsten Haitzler (The Rasterman)
idea
right now.
you do NOT want a raise/lower etc. in wayland. you want xdg shell and an

activate request. the compositor after that decides what is best to do.

Post by yan.wang
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of

top-level

Post by Jasper St. Pierre
surfaces. Why do you need this?

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
------------- Codito, ergo sum - "I code, therefore I am" --------------

--
Regards,

*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140731/0b8cc4fe/attachment.html>

yan.wang

2014-08-01 02:59:21 UTC

Sure. We Tizen IVI tried 20140704.2 image and found this macro is enabled.
But when we tried to build efl by GBS, we get the following error:

efl:
nothing provides pkgconfig(gl)

We are looking for the cause.

Yan Wang

Post by Manuel Bachmann
Hi Yan,
"And I am not sure whether USE_XDG_SHELL macro is enabled in current
Tizen upstream."
It is enabled by default. If you download a sufficiently recent snapshot of
Tizen Common or IVI (I recommend from 2014/06/20 so you can have Weston
1.5.0), and click on the "Minimize" button of a random EFL application, it
will in fact minimize the window with "xdg_surface_set_minimized()". It is
a good way to check if this macro was enabled.
Regards,

On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.wang at linux.intel.com

Post by yan.wang
E.g. When we start a new application on mobile platform, previous

running

Post by yan.wang
application could be hidden and paused to reduce power consuming and

improve response speed. If we could adjust and get z-order status, we

Post by yan.wang
could callback application to sleep. And when user restart this

application, we could just make this slept app waked up.

you do NOT want to do this by raise/lower. even doing this in x11 is

just

WRONG. in fact a good mobile wm setup would refuse to allow this.

there
is

a
netwm request "netwm activate". this requests the window is activated.

this MAY

raise the window. it may switch desktop. it may de-iconify a window.

it
may

also place focus on the window... unless the wm decides that this is a

bad

idea
right now.
you do NOT want a raise/lower etc. in wayland. you want xdg shell and

an
activate request. the compositor after that decides what is best to do.

Post by yan.wang
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of

top-level

Post by Jasper St. Pierre
surfaces. Why do you need this?

Post by yan.wang
Hi, All,
I found X provides raise/lower APIs to manger window Z-order.

But

Post by yan.wang
there
isn't related APIs in Wayland/Weston.
May it should be one design idea of Wayland in fact or I could achieve
this by current Wayland protocol?
Thanks.
Yan Wang
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
------------- Codito, ergo sum - "I code, therefore I am"

--------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
Regards,
*Manuel BACHMANN Tizen Project VANNES-FR*

yan.wang

2014-08-01 03:30:27 UTC

Need change gles20 -> glesv2.
please check the following:
https://review.tizen.org/gerrit/25247

Post by yan.wang
Sure. We Tizen IVI tried 20140704.2 image and found this macro is enabled.
nothing provides pkgconfig(gl)
We are looking for the cause.
Yan Wang

Post by Manuel Bachmann
Hi Yan,
"And I am not sure whether USE_XDG_SHELL macro is enabled in current

Tizen upstream."

Post by Manuel Bachmann
It is enabled by default. If you download a sufficiently recent

snapshot

Post by Manuel Bachmann
of
Tizen Common or IVI (I recommend from 2014/06/20 so you can have Weston

1.5.0), and click on the "Minimize" button of a random EFL application,
it

Post by Manuel Bachmann
will in fact minimize the window with "xdg_surface_set_minimized()". It is
a good way to check if this macro was enabled.
Regards,

On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.wang at linux.intel.com

Post by yan.wang
E.g. When we start a new application on mobile platform, previous

running

Post by yan.wang
application could be hidden and paused to reduce power consuming and

improve response speed. If we could adjust and get z-order status, we

Post by yan.wang
could callback application to sleep. And when user restart this

application, we could just make this slept app waked up.

you do NOT want to do this by raise/lower. even doing this in x11 is

just

WRONG. in fact a good mobile wm setup would refuse to allow this.

there
is

a
netwm request "netwm activate". this requests the window is

activated.
this MAY

raise the window. it may switch desktop. it may de-iconify a window.

it
may

also place focus on the window... unless the wm decides that this is

a
bad

idea
right now.
you do NOT want a raise/lower etc. in wayland. you want xdg shell and

an
activate request. the compositor after that decides what is best to do.

Post by yan.wang
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of

top-level

Post by Jasper St. Pierre
surfaces. Why do you need this?

Post by yan.wang
Hi, All,
I found X provides raise/lower APIs to manger window Z-order.

But

Post by yan.wang
there
isn't related APIs in Wayland/Weston.
May it should be one design idea of Wayland in fact or I

could

Post by Manuel Bachmann

Post by yan.wang
achieve
this by current Wayland protocol?
Thanks.
Yan Wang
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
------------- Codito, ergo sum - "I code, therefore I am"

--
Regards,
*Manuel BACHMANN Tizen Project VANNES-FR*

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Manuel Bachmann

2014-08-01 08:13:27 UTC

Yan,

"gl" comes from the mesa package, but has been disabled in the pure wayland
profile ("libGL.so" pulls "libX11.so"). My guess is that your gbs'
build.conf is not correct or up-to-date, as "gl" only appears if the "%with
x" macro is defined, while it is not in recent config files. So you likely
have the good repo but a bad config file.

As this discussion is more Tizen-specific than Wayland-specific, would you
mind that we go further with private email, or -better- in the Tizen-IVI
maling list (ivi at lists.tizen.org) ?

Regards,

Post by yan.wang
Sure. We Tizen IVI tried 20140704.2 image and found this macro is enabled.
nothing provides pkgconfig(gl)
We are looking for the cause.
Yan Wang

Post by Manuel Bachmann
will in fact minimize the window with "xdg_surface_set_minimized()". It

Post by Manuel Bachmann
a good way to check if this macro was enabled.
Regards,

On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.wang at linux.intel.com

Post by yan.wang
E.g. When we start a new application on mobile platform, previous

running

Post by yan.wang
application could be hidden and paused to reduce power consuming and

improve response speed. If we could adjust and get z-order status, we

Post by yan.wang
could callback application to sleep. And when user restart this

application, we could just make this slept app waked up.

you do NOT want to do this by raise/lower. even doing this in x11 is

just

WRONG. in fact a good mobile wm setup would refuse to allow this.

there
is

a
netwm request "netwm activate". this requests the window is activated.

this MAY

raise the window. it may switch desktop. it may de-iconify a window.

it
may

also place focus on the window... unless the wm decides that this is a

bad

idea
right now.
you do NOT want a raise/lower etc. in wayland. you want xdg shell and

an
activate request. the compositor after that decides what is best to do.

Post by yan.wang
Yan Wang

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of

top-level

Post by Jasper St. Pierre
surfaces. Why do you need this?

Post by yan.wang
Hi, All,
I found X provides raise/lower APIs to manger window Z-order.

But

Post by yan.wang
there
isn't related APIs in Wayland/Weston.
May it should be one design idea of Wayland in fact or I could achieve
this by current Wayland protocol?
Thanks.
Yan Wang
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

--
------------- Codito, ergo sum - "I code, therefore I am"

--
Regards,
*Manuel BACHMANN Tizen Project VANNES-FR*

Pekka Paalanen

2014-08-01 07:30:02 UTC

On Thu, 31 Jul 2014 17:21:15 +0900

you do NOT want to do this by raise/lower. even doing this in x11 is just
WRONG. in fact a good mobile wm setup would refuse to allow this. there is a
netwm request "netwm activate". this requests the window is activated. this MAY
raise the window. it may switch desktop. it may de-iconify a window. it may
also place focus on the window... unless the wm decides that this is a bad idea
right now.
you do NOT want a raise/lower etc. in wayland. you want xdg shell and an
activate request. the compositor after that decides what is best to do.

Actually, for a mobile platform, you do not even want to use xdg_shell,
but a replacement that is designed specifically for mobile. Xdg_shell
is for desktops, and likely contains some useful features for mobile,
but also features that do not make sense on mobile. Mobile also may
want features that are never going to be in xdg_shell.

I know there is come controversy in this, as it means you need to patch
all toolkits/apps to use the replacement protocol, but it also means
those toolkits/apps get tailored so that they actually behave nicely on
mobile UIs.

Just to keep this in mind, if you find xdg_shell not ideal for your
non-desktop-like environment. Of course, nothing prevents you from
sticking to xdg_shell, if its semantics work well; less work for
everyone.

Thanks,
pq

Bill Spitzak

2014-07-31 18:17:46 UTC

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of top-level
surfaces.

Wait a second, how is click-to-raise being done?

Carsten Haitzler (The Rasterman)

2014-07-31 22:21:21 UTC

Post by Bill Spitzak

Post by Jasper St. Pierre
There is currently no way to influence the stacking order of top-level
surfaces.

Wait a second, how is click-to-raise being done?

not by the client - by the compositor. the client has no control over that.

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com

Bill Spitzak

2014-07-31 22:44:40 UTC

Post by Bill Spitzak
Wait a second, how is click-to-raise being done?

not by the client - by the compositor. the client has no control over that.

That does not work. The client has to be able to decide whether a mouse
click will raise the window.

The most obvious thing that does not work is drag & drop.

It makes it impossible for a click to both raise the window and create a
floating window without blinking.

And unless something MUCH more complicated than the current parent in
xdg_shell is used, it makes multiple-window software impossible. At
least a full Directed Acyclic Graph of multiple parents for every
surface is needed, though I really suspect an entire interpreted
language is needed to describe window stacking.

This has to be fixed or you are violating the "every frame is perfect"
design criteria for Wayland.

Daniel Stone

2014-07-31 23:33:02 UTC

Post by Bill Spitzak
That does not work. The client has to be able to decide whether a mouse
click will raise the window.

You really don't need to tell us this every two weeks. We get the point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140801/27ee7320/attachment.html>

Carsten Haitzler (The Rasterman)

2014-08-01 02:27:11 UTC

Post by Bill Spitzak

Post by Bill Spitzak
Wait a second, how is click-to-raise being done?

not by the client - by the compositor. the client has no control over that.

That does not work. The client has to be able to decide whether a mouse
click will raise the window.

no it doesn't. it doesn't work like that in x11 and things work just fine. i've
been doing wm's and toolkits for a long time. wayland is well designed, if
perhaps a little spartan. :)

Post by Bill Spitzak
The most obvious thing that does not work is drag & drop.

what has that got to do with a click raising or not? dnd is a separate protocol
element with its own semantics.

Post by Bill Spitzak
It makes it impossible for a click to both raise the window and create a
floating window without blinking.

not so. :) as dnd is triggered on a DRAG = the mouse has MOVED beyond a
certain threshold beyond the place that the click happened - the creation of a
dnd icon is long after the click and the raise. this is precisely how it works
in x11 today - the click is intercepted by the wm with a passive grab and an
allow events to hand it on. that click may cause the wm to raise the window.
even the override-redirect window the client makes for dnd is fine...

in wayland dnd is a special thing and the compositor is directly involved

Post by Bill Spitzak
And unless something MUCH more complicated than the current parent in
xdg_shell is used, it makes multiple-window software impossible. At
least a full Directed Acyclic Graph of multiple parents for every
surface is needed, though I really suspect an entire interpreted
language is needed to describe window stacking.
This has to be fixed or you are violating the "every frame is perfect"
design criteria for Wayland.

nope. when a drag starts an icon surface (to be dragged about) it given to the
compositor. the compositor can happily ensure that that surface is at the
correct x/y AND always above everything - like the mouse pointer. lok at the
start_drag protocol request. :)

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com

Bill Spitzak

2014-08-01 20:10:38 UTC

Post by Bill Spitzak
The most obvious thing that does not work is drag & drop.

what has that got to do with a click raising or not? dnd is a separate protocol
element with its own semantics.

You want to be able to drag out of a window without raising it.
Otherwise it could raise and obscure the location you wish to drop at.
Probably more important right now is that this is how Windows and OS/X
work for drag & drop.

This is not possible if sending the mouse-down (the one that will start
the drag) raises the source window. It has nothing to do with the dnd
protocol itself as all this happens before the first dnd request or event.

Windows kludges around this by relying on synchronous operation, since
the window manager is (in effect) running in a library in the same
process. If no calls to start drag happen before the event handler for
the mouse-down returns, it raises the window. This cannot be done on
Wayland as it does not want to rely on synchronous behavior.

In any case this is going to have to be fixed in xdg_shell. I did not
realize until I did some more investigation of it how little has been
done on developing xdg_shell. I suppose clients that use wl_shell can
have unavoidable raise-on-click.

Jasper St. Pierre

2014-08-01 23:54:01 UTC