[E-devel] What is a withdrawn window?

2013-12-09 Thread Eoff, Ullysses A
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?

2013-12-09 Thread Michael Blumenkrantz
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?

2013-12-09 Thread Tom Hacohen
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?

2013-12-09 Thread Rafael Antognolli
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?

2013-12-09 Thread Robert Heller
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?

2013-12-09 Thread Robert Heller
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?

2013-12-09 Thread The Rasterman
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