[E-devel] What is a withdrawn window?
The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. U. Artie -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
On Mon, 9 Dec 2013 16:53:38 + Eoff, Ullysses A ullysses.a.e...@intel.com wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. U. Artie withdrawn is the same as iconify, except that the application may decide to free/destroy/reduce functionality in order to conserve system resources. it's like how android apps never close but also aren't in the foreground or using noticeable cpu/battery. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
On 09/12/13 16:53, Eoff, Ullysses A wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. As I said on IRC, if I remember correctly withdrawn is the super-hidden. That is hidden + it's safe to release some resources as it'll be hidden for a while/we need the resources. That's just from the top of my head, I guess raster might be able to remember. We also need to sort out (higher level, not in the engine) all of the withdrawn true/false settings on hide and show and decide what can and should be done in many cases. For example, if we switch to show, does the state automatically change? Can we have a withdrawn state even when shown, and then make it actually do something only when the window is hidden? I don't know, it's kind of weird. -- Tom. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
On Mon, Dec 9, 2013 at 3:04 PM, Tom Hacohen tom.haco...@samsung.com wrote: On 09/12/13 16:53, Eoff, Ullysses A wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. As I said on IRC, if I remember correctly withdrawn is the super-hidden. That is hidden + it's safe to release some resources as it'll be hidden for a while/we need the resources. That's just from the top of my head, I guess raster might be able to remember. OK, your answer seems aligned to Mike's one. So, another question: when we iconify a window, it should still appear in the toplevel list of windows, e.g. for ALT+Tab. Does the same happen when we hide/withdrawn a window? Would be good to have a clear difference between iconify, withdrawn and hide. So far, withdrawn and hide are being treated exactly the same in Wayland engines, while iconify will be different (it's a server-side thing, the client won't free any resources at all). We also need to sort out (higher level, not in the engine) all of the withdrawn true/false settings on hide and show and decide what can and should be done in many cases. For example, if we switch to show, does the state automatically change? Can we have a withdrawn state even when shown, and then make it actually do something only when the window is hidden? I don't know, it's kind of weird. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
At Mon, 9 Dec 2013 16:53:38 + Enlightenment developer list enlightenment-devel@lists.sourceforge.net wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? It is a *standard* window manager thing: a withdrawn is a window that has been unmapped (or never mapped). Just about all widget toolkits have this sort of feature, usually there is some 'window manager' interface API for this and other interactions with the window manager (such as size / geometry hints and grabbing access to the 'close/delete' window function, window resizing/moving, and things like window manager decoration and things like transient properties. (Tcl/Tk has a function 'wm' for all of that for example). Usually this is done because: 1) A bunch of complex stuff will be placed in the window and the the programmer does not want to give the user an 'interesting' view of the window being set up (think: keeping the curtian closed while the stage hands set up the scenery). 2) The window is a dialog box (or something) that gets re-used and is withdrawn when not in use. Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. U. Artie -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
At Mon, 9 Dec 2013 15:09:44 -0200 Enlightenment developer list enlightenment-devel@lists.sourceforge.net wrote: On Mon, Dec 9, 2013 at 3:04 PM, Tom Hacohen tom.haco...@samsung.com wrote: On 09/12/13 16:53, Eoff, Ullysses A wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. As I said on IRC, if I remember correctly withdrawn is the super-hidden. That is hidden + it's safe to release some resources as it'll be hidden for a while/we need the resources. That's just from the top of my head, I guess raster might be able to remember. OK, your answer seems aligned to Mike's one. So, another question: when we iconify a window, it should still appear in the toplevel list of windows, e.g. for ALT+Tab. Does the same happen when we hide/withdrawn a window? Would be good to have a clear difference between iconify, withdrawn and hide. Not sure what 'hide' is exactly, but iconify and withdrawn define two states: iconified: window is not visible, but an icon is visible as a 'place holder'. Some (old school?) window managers place the icon on the desktop itself, but most window managers now put the icon in an icon box, icon manager, or a task manager. The user can click on the icon to make the window visible again. withdrawn: the window is not visible, and there is no UI indication that it even exists. The application must do something to make the window visible. This might be in response to some user action or for some other reason, like a background task completing or some other event happening. So far, withdrawn and hide are being treated exactly the same in Wayland engines, while iconify will be different (it's a server-side thing, the client won't free any resources at all). We also need to sort out (higher level, not in the engine) all of the withdrawn true/false settings on hide and show and decide what can and should be done in many cases. For example, if we switch to show, does the state automatically change? Can we have a withdrawn state even when shown, and then make it actually do something only when the window is hidden? I don't know, it's kind of weird. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
On Mon, 9 Dec 2013 12:00:32 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Mon, 9 Dec 2013 16:53:38 + Eoff, Ullysses A ullysses.a.e...@intel.com wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. U. Artie withdrawn is the same as iconify, except that the application may decide to free/destroy/reduce functionality in order to conserve system resources. it's like how android apps never close but also aren't in the foreground or using noticeable cpu/battery. actually no. it's not the same as iconified. its basically a window that is no longer managed at all by the window manager. it has been widthdrawn. it is the same as just hide()ing it. http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
