[Question] Z-order management in Wayland
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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [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? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
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 There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
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. On Thu, Jul 31, 2014 at 10:02 AM, yan.w...@linux.intel.com wrote: 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 There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [Question] Z-order management in Wayland
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-boun...@lists.freedesktop.org] On Behalf Of yan.w...@linux.intel.com Sent: Thursday, July 31, 2014 5:03 PM To: Jasper St. Pierre Cc: yan.w...@linux.intel.com; wayland-devel@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 There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
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 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. On Thu, Jul 31, 2014 at 10:02 AM, yan.w...@linux.intel.com wrote: 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 There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [Question] Z-order management in Wayland
Thanks. I will check it. Yan Wang 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-boun...@lists.freedesktop.org] On Behalf Of yan.w...@linux.intel.com Sent: Thursday, July 31, 2014 5:03 PM To: Jasper St. Pierre Cc: yan.w...@linux.intel.com; wayland-devel@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 There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.w...@linux.intel.com said: 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. 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. Yan Wang There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
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 On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.w...@linux.intel.com said: 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. 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. Yan Wang There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
On Thu, 31 Jul 2014 01:57:44 -0700 (PDT) yan.w...@linux.intel.com said: 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? 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. 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. 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. Yan Wang On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.w...@linux.intel.com said: 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. 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. Yan Wang There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] shell: fix various interactions with the minimized state
This fixes the following :
- if a surface was set fullscreen, and then minimized,
the fullscreen compositor state would stay on and display
a black screen ;
- if a surface was set fullscreen, and we would then
cycle between surfaces (with Mod+Tab e.g.), the fullscreen
compositor state would stay on, and the fullscreen layer
would sometimes hide surfaces positioned behind it ;
- style and functional polishing, remove dead code.
Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
desktop-shell/shell.c | 67 -
1 file changed, 38 insertions(+), 29 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 3c3649c..60639cc 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2510,13 +2510,14 @@ unset_maximized(struct shell_surface *shsurf)
}
static void
-set_minimized(struct weston_surface *surface, uint32_t is_true)
+set_minimized(struct weston_surface *surface)
{
+ struct weston_view *view;
struct shell_surface *shsurf;
- struct workspace *current_ws;
+ struct workspace *ws;
struct weston_seat *seat;
struct weston_surface *focus;
- struct weston_view *view;
+ float x,y;
view = get_default_view(surface);
if (!view)
@@ -2525,34 +2526,31 @@ set_minimized(struct weston_surface *surface, uint32_t
is_true)
assert(weston_surface_get_main_surface(view-surface) == view-surface);
shsurf = get_shell_surface(surface);
- current_ws = get_current_workspace(shsurf-shell);
+ ws = get_current_workspace(shsurf-shell);
- weston_layer_entry_remove(view-layer_link);
-/* hide or show, depending on the state */
- if (is_true) {
-
weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list,
view-layer_link);
-
- drop_focus_state(shsurf-shell, current_ws, view-surface);
- wl_list_for_each(seat, shsurf-shell-compositor-seat_list,
link) {
- if (!seat-keyboard)
- continue;
- focus =
weston_surface_get_main_surface(seat-keyboard-focus);
- if (focus == view-surface)
- weston_keyboard_set_focus(seat-keyboard, NULL);
- }
+ /* if the surface is fullscreen, unset the global fullscreen state,
+* but keep the surface centered on its previous output.
+*/
+ if (shsurf-state.fullscreen) {
+ x = shsurf-view-geometry.x;
+ y = shsurf-view-geometry.y;
+ unset_fullscreen(shsurf);
+ weston_view_set_position(shsurf-view, x, y);
}
- else {
- weston_layer_entry_insert(current_ws-layer.view_list,
view-layer_link);
- wl_list_for_each(seat, shsurf-shell-compositor-seat_list,
link) {
- if (!seat-keyboard)
- continue;
- activate(shsurf-shell, view-surface, seat, true);
- }
+ weston_layer_entry_remove(view-layer_link);
+ weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list,
view-layer_link);
+
+ drop_focus_state(shsurf-shell, ws, view-surface);
+ wl_list_for_each(seat, shsurf-shell-compositor-seat_list, link) {
+ if (!seat-keyboard)
+ continue;
+ focus = weston_surface_get_main_surface(seat-keyboard-focus);
+ if (focus == view-surface)
+ weston_keyboard_set_focus(seat-keyboard, NULL);
}
shell_surface_update_child_surface_layers(shsurf);
-
weston_view_damage_below(view);
}
@@ -3534,8 +3532,7 @@ xdg_surface_set_minimized(struct wl_client *client,
if (shsurf-type != SHELL_SURFACE_TOPLEVEL)
return;
-/* apply compositor's own minimization logic (hide) */
- set_minimized(shsurf-surface, 1);
+ set_minimized(shsurf-surface);
}
static const struct xdg_surface_interface xdg_surface_implementation = {
@@ -5444,12 +5441,24 @@ struct switcher {
static void
switcher_next(struct switcher *switcher)
{
+ struct focus_state *state;
+ struct weston_surface *surface;
struct weston_view *view;
struct weston_surface *first = NULL, *prev = NULL, *next = NULL;
struct shell_surface *shsurf;
struct workspace *ws = get_current_workspace(switcher-shell);
-/* temporary re-display minimized surfaces */
+ /* if the focused surface is fullscreen, minimize it */
+ wl_list_for_each(state, ws-focus_list, link) {
+ if (state-keyboard_focus) {
+ surface =
weston_surface_get_main_surface(state-keyboard_focus);
+ shsurf = get_shell_surface(surface);
+ if (shsurf-state.fullscreen)
+
Re: [Question] Z-order management in Wayland
On 07/31/2014 12:30 AM, Jasper St. Pierre wrote: There is currently no way to influence the stacking order of top-level surfaces. Wait a second, how is click-to-raise being done? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
On 07/31/2014 03:21 PM, Carsten Haitzler (The Rasterman) wrote: 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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
On Thursday, July 31, 2014, Bill Spitzak spit...@gmail.com wrote: 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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
On Thu, 31 Jul 2014 15:44:40 -0700 Bill Spitzak spit...@gmail.com said: On 07/31/2014 03:21 PM, Carsten Haitzler (The Rasterman) wrote: 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. :) 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. 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 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)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
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 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, 2014-07-31 10:57 GMT+02:00 yan.w...@linux.intel.com: 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 On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.w...@linux.intel.com said: 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. 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. Yan Wang There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Regards, *Manuel BACHMANN Tizen Project VANNES-FR* ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Question] Z-order management in Wayland
Need change gles20 - glesv2. please check the following: https://review.tizen.org/gerrit/25247 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 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, 2014-07-31 10:57 GMT+02:00 yan.w...@linux.intel.com: 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 On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.w...@linux.intel.com said: 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. 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. Yan Wang There is currently no way to influence the stacking order of top-level surfaces. Why do you need this? On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Regards, *Manuel BACHMANN Tizen Project VANNES-FR* ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
