Re: [gtk-list] Re: Minimizing/iconizing and maximizing/restoring window

[raster redhat com]

On 11 Oct, Tim Janik scribbled:
->  On Fri, 9 Oct 1998, Damon Chaplin wrote:
->  
->  [...]
->  > These do need to be added to GDK, by the way.
->  > (As well as a way of getting a window's real position, including WM
->  > decorations - do you just need to walk up the X window tree with
->  > XQueryTree until you find the root window?)
->  
->  i've recently added a function for this to the development tree:
->  Sat Sep 25 23:33:55 1998  Tim Janik  <timj@gtk.org>
->  
->          * gdk/gdkwindow.c (gdk_window_get_root_origin): new function to get
->          the *real* geometry position of a window, taken possible window
->          manager offsets into account.
->          this has been succesfully tested with fvwm, fvwm-2, bowman, olwm,
->          olvwm, twm, ctwm, mlvwm, windowmaker and enlightenment.

OH ps - forgot - for enlightenment it actually sets a wonderful
property on its "virtual root" windows for desktops > 0 
ENLIGHTENMENT_DESKTOP (CARDINAL) will contain the desktop numebr of
that window (root window will be desktop number 0) :) NB - this is
going to become more fun than ever before when mandrake finished his
container code - basically you can create a managed window wiht
borders, titlebar etc liek a windows MDI thing to put client windows
into in E - like another desktop of E's but this one is resizable,
movable in all ways like any client... :) the fun will go on :)

->          it does fail though for amiwm which adds windows to a pseudo root
->          window, and for icewm by a small offset because it defines the
->          geometry position whithin its border.
->  
->          * gtk/testgtk.c: added "saved position" test to figure how
->          gdk_window_get_root_origin() interacts with window managers (repopup
->          this window to figure ;).
->  
->  i currently consider the extra offset with icewm an icewm bug, because
->  all other window managers define the geometry position at the top- and
->  left-most pixel of their decoration border, and other applications show
->  the same behaviour with icewm.
->  i'm not sure though what to do about amiwm, eventually we can figure if
->  amiwm is currently running and special case the algorithm somehow, this
->  needs further investigation.
->  
->  > 
->  > I think it's also about time GTK's TODO file was updated!
->  > (Delete it and start again!)
->  
->  suprisingly enough, most of the items from Gtk+'s development TODO
->  file still hold, though some of the bugs mentioned there will probably
->  be fixed with the upcoming DnD changes and/or a themes merge.
->  
->  > 
->  > Damon
->  > 
->  
->  ---
->  ciaoTJ
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/