Bug in gitk - can post the window off screen

Just a quick heads-up: I was running a dual screen setup with gitk on my 
2nd monitor. When I later started gitk up without the 2nd monitor, the 
gitk window didn't appear. Given the time between the two sessions, it 
didn't occur to me what the problem was.

Gitk should probably validate the "set geometry(main)" variable against 
the current resolution.

Tommy

Tommy Thorn [off-list ref] wrote:

Just a quick heads-up: I was running a dual screen setup with gitk on my 
2nd monitor. When I later started gitk up without the 2nd monitor, the 
gitk window didn't appear. Given the time between the two sessions, it 
didn't occur to me what the problem was.

Gitk should probably validate the "set geometry(main)" variable against 
the current resolution.

Sad to say but this is a known issue with both gitk and git-gui.
Both applications save the prior geometry and restore it during
the next run, but neither validates the new geometry makes sense
with the current available desktop space.  :-\

-- 
Shawn.

torsdagen den 7 februari 2008 skrev Shawn O. Pearce:

Tommy Thorn [off-list ref] wrote:

quoted

Just a quick heads-up: I was running a dual screen setup with gitk on my 
2nd monitor. When I later started gitk up without the 2nd monitor, the 
gitk window didn't appear. Given the time between the two sessions, it 
didn't occur to me what the problem was.

Gitk should probably validate the "set geometry(main)" variable against 
the current resolution.

Sad to say but this is a known issue with both gitk and git-gui.
Both applications save the prior geometry and restore it during
the next run, but neither validates the new geometry makes sense
with the current available desktop space.  :-\

Seems KDE forces it back into visible space, but it is annoying that the 
gitk/git-gui windows do not come up on the same monitor as my cursor is on. 
Could we change it and save just size, just like "all other" apps?

-- robin

On Thu, Feb 07, 2008 at 10:56:19AM +0100, Robin Rosenberg wrote:

torsdagen den 7 februari 2008 skrev Shawn O. Pearce:

quoted

Tommy Thorn [off-list ref] wrote:

quoted

Just a quick heads-up: I was running a dual screen setup with gitk on my 
2nd monitor. When I later started gitk up without the 2nd monitor, the 
gitk window didn't appear. Given the time between the two sessions, it 
didn't occur to me what the problem was.

Gitk should probably validate the "set geometry(main)" variable against 
the current resolution.

Sad to say but this is a known issue with both gitk and git-gui.
Both applications save the prior geometry and restore it during
the next run, but neither validates the new geometry makes sense
with the current available desktop space.  :-\

Seems KDE forces it back into visible space, but it is annoying that the 
gitk/git-gui windows do not come up on the same monitor as my cursor is on. 
Could we change it and save just size, just like "all other" apps?

Not saving the geometry on exit was also suggested through the Debian
BTS, "as window placement and sizing are the task of the window
manager"
 http://bugs.debian.org/442253

Regards, Gerrit.

Saving the geometry can cause several inconveniences, e.g. when using a
temporary dual screen setup, or sharing ~/.gitk between multiple
systems.  Additionally it can be argued that window placement and sizing
are the tasks of the window manager.  So don't do that anymore.

This has been requested by martin f krafft and Josh Triplett through
 http://bugs.debian.org/442253
 http://bugs.debian.org/467121

Signed-off-by: Gerrit Pape <redacted>
---
 gitk-git/gitk |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index f1f21e9..8039d19 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk

@@ -1188,14 +1188,6 @@ proc savestuff {w} {
 	puts $f [list set diffcontext $diffcontext]
 	puts $f [list set selectbgcolor $selectbgcolor]
 
-	puts $f "set geometry(main) [wm geometry .]"
-	puts $f "set geometry(topwidth) [winfo width .tf]"
-	puts $f "set geometry(topheight) [winfo height .tf]"
-        puts $f "set geometry(pwsash0) \"[.tf.histframe.pwclist sash coord 0]\""
-        puts $f "set geometry(pwsash1) \"[.tf.histframe.pwclist sash coord 1]\""
-	puts $f "set geometry(botwidth) [winfo width .bleft]"
-	puts $f "set geometry(botheight) [winfo height .bleft]"
-
 	puts -nonewline $f "set permviews {"
 	for {set v 0} {$v < $nextviewnum} {incr v} {
 	    if {$viewperm($v)} {

-- 
1.5.4.2

lördagen den 23 februari 2008 skrev Gerrit Pape:

Saving the geometry can cause several inconveniences, e.g. when using a
temporary dual screen setup, or sharing ~/.gitk between multiple
systems.  Additionally it can be argued that window placement and sizing
are the tasks of the window manager.  So don't do that anymore.

Shouldn't the restoring code also be dropped then? 

Other than that, I agree. The Gitk current behaviour wrt dual screens 
is really inconvenient.

-- robin

On Sat, Feb 23, 2008 at 12:52 PM, Robin Rosenberg
[off-list ref] wrote:

lördagen den 23 februari 2008 skrev Gerrit Pape:

quoted

Saving the geometry can cause several inconveniences, e.g. when using a

 > temporary dual screen setup, or sharing ~/.gitk between multiple
 > systems.  Additionally it can be argued that window placement and sizing
 > are the tasks of the window manager.  So don't do that anymore.

 Shouldn't the restoring code also be dropped then?

Perhaps, though that would prevent you setting up default width &
height.  You'd always be stuck with the (too small IMO) original
window size

Gerrit Pape writes:

Saving the geometry can cause several inconveniences, e.g. when using a
temporary dual screen setup, or sharing ~/.gitk between multiple
systems.  Additionally it can be argued that window placement and sizing
are the tasks of the window manager.  So don't do that anymore.

I myself find it useful to have gitk remember the size and layout of
the various panes, so I won't be applying this patch.

The saving/restoring of the window position was done by Mark Levedahl
to make gitk work properly on Cygwin.  I agree it can be annoying on X
and I would take a patch to inhibit the restoring of the window
position when running under X.  I'd want an ack from Mark before
making that change more generally.

Paul.

Paul Mackerras wrote:

Gerrit Pape writes:

  

quoted

Saving the geometry can cause several inconveniences, e.g. when using a
temporary dual screen setup, or sharing ~/.gitk between multiple
systems.  Additionally it can be argued that window placement and sizing
are the tasks of the window manager.  So don't do that anymore.
    

I myself find it useful to have gitk remember the size and layout of
the various panes, so I won't be applying this patch.

The saving/restoring of the window position was done by Mark Levedahl
to make gitk work properly on Cygwin.  I agree it can be annoying on X
and I would take a patch to inhibit the restoring of the window
position when running under X.  I'd want an ack from Mark before
making that change more generally.

Paul.

  

I can only offer to test the proposed patch, I am unable to predict what 
will or won't trip up the buggy geometry engine in Cygwin's Tk. I do 
remember I had trouble finding a way to restore the size but not the 
position of the main window on Cygwin: that doesn't mean it can't be 
done (logically, it should be easy), just that I didn't find the right 
spell or incantation that would work. I'll also admit to not having 
tried after I got to a completely working geometry solution, so perhaps 
just restoring the size without position will now work on Cygwin.

Using the saved panel sizes in conjunction with the default window size 
yields an unusable screen: many elements are obscured. The same occurs 
using the defaults altogether: either way the user must resize and 
adjust things to get to a workable layout. So, I am very opposed to 
disabling the memory altogether. Also, I have a number of X apps that 
remember their layout, so gitk's current behavior is not (at least to 
me) an aberration and I would like that behavior to at least remain an 
option.

Mark

Mark Levedahl wrote:

[...] so gitk's current behavior is not (at least to me) an aberration
and I would like that behavior to at least remain an option.

It would be really annoying if I had to resize and reconfigure (the
panes) each time I start gitk.

How about only taking the saved geometry/fonts/etc when the screen
size hasn't changed?

The easiest method (for a Tcl-noob like me) would be to wrap the
"set geometry..." in .gitk with an if-statement which checks the
screen size.

Something like this:

diff --git a/gitk-git/gitk b/gitk-git/gitk
index 5560e4d..1c572c9 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk

@@ -1158,14 +1158,12 @@ proc savestuff {w} {
     global viewname viewfiles viewargs viewperm nextviewnum
     global cmitmode wrapcomment datetimeformat limitdiffs
     global colors bgcolor fgcolor diffcolors diffcontext selectbgcolor
+    global screen_size
 
     if {$stuffsaved} return
     if {![winfo viewable .]} return
     catch {
 	set f [open "~/.gitk-new" w]
-	puts $f [list set mainfont $mainfont]
-	puts $f [list set textfont $textfont]
-	puts $f [list set uifont $uifont]
 	puts $f [list set tabstop $tabstop]
 	puts $f [list set findmergefiles $findmergefiles]
 	puts $f [list set maxgraphpct $maxgraphpct]

@@ -1183,6 +1181,10 @@ proc savestuff {w} {
 	puts $f [list set diffcontext $diffcontext]
 	puts $f [list set selectbgcolor $selectbgcolor]
 
+	puts $f "if {\$screen_size == \"$screen_size\"} {"
+	puts $f [list set mainfont $mainfont]
+	puts $f [list set textfont $textfont]
+	puts $f [list set uifont $uifont]
 	puts $f "set geometry(main) [wm geometry .]"
 	puts $f "set geometry(topwidth) [winfo width .tf]"
 	puts $f "set geometry(topheight) [winfo height .tf]"

@@ -1198,6 +1200,7 @@ proc savestuff {w} {
 	    }
 	}
 	puts $f "}"
+	puts $f "}"
 	close $f
 	file rename -force "~/.gitk-new" "~/.gitk"
     }

@@ -8461,6 +8464,8 @@ set diffcolors {red "#00a000" blue}
 set diffcontext 3
 set selectbgcolor gray85
 
+set screen_size [winfo screenwidth .]x[winfo screenheight .]
+
 ## For msgcat loading, first locate the installation location.
 if { [info exists ::env(GITK_MSGSDIR)] } {
     ## Msgsdir was manually set in the environment.

Saving geometries for multiple screen sizes would be even better
(i.e. geometry_1440x900(main) etc or an additional ".gitk-$screen_size"
for the geometry data) but that is beyond my Tcl-skills.

Ciao, ET.

also sprach Paul Mackerras [off-list ref] [2008.02.23.2349 +0100]:

quoted

Saving the geometry can cause several inconveniences, e.g. when
using a temporary dual screen setup, or sharing ~/.gitk between
multiple systems.  Additionally it can be argued that window
placement and sizing are the tasks of the window manager.  So
don't do that anymore.

I myself find it useful to have gitk remember the size and layout
of the various panes, so I won't be applying this patch.

The saving/restoring of the window position was done by Mark
Levedahl to make gitk work properly on Cygwin.  I agree it can be
annoying on X and I would take a patch to inhibit the restoring of
the window position when running under X.  I'd want an ack from
Mark before making that change more generally.

May I suggest that such a patch actually disables writing of the
config file, so that we won't get conflicts every time you sync
config files via home-in-git?

Of course I offer to look into this once Mark approves.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"if there's anything more important than my ego,
 i want it caught and shot now."
                                                -- zaphod beeblebrox
 
spamtraps: madduck.bogus@madduck.net

martin f krafft writes:

May I suggest that such a patch actually disables writing of the
config file, so that we won't get conflicts every time you sync
config files via home-in-git?

Then various other bits of config won't be persistent, such as font
settings.  So I don't think that's a good idea.

It would be possible to make the config file be per-repository rather
than global, I guess, if that is something people want.  I personally
would find it annoying to have to change the font separately in each
repository, but tastes differ, I guess.

Paul.

also sprach Paul Mackerras [off-list ref] [2008.02.25.1309 +0100]:

Then various other bits of config won't be persistent, such as font
settings.  So I don't think that's a good idea.

Huh? I use the same font on all machines, but the screen resolutions
differ...

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
time wounds all heels.
                                                       -- groucho marx
 
spamtraps: madduck.bogus@madduck.net

On Mon, Feb 25, 2008 at 7:09 AM, Paul Mackerras [off-list ref] wrote:

martin f krafft writes:

 > May I suggest that such a patch actually disables writing of the
 > config file, so that we won't get conflicts every time you sync
 > config files via home-in-git?

 Then various other bits of config won't be persistent, such as font
 settings.  So I don't think that's a good idea.

 It would be possible to make the config file be per-repository rather
 than global, I guess, if that is something people want.  I personally
 would find it annoying to have to change the font separately in each
 repository, but tastes differ, I guess.

 Paul.

Two things we could do:

1) Add a "save config now" button and a "save config on exit"
checkbox/option to the options dialog.
2) Perform a screen geometry check at load time to see if the corners
of the main window would be visible before applying the main window
geometry.

Mark

also sprach Mark Levedahl [off-list ref] [2008.02.25.1435 +0100]:

1) Add a "save config now" button and a "save config on exit"
checkbox/option to the options dialog.

and a checkbox like "disable writing window geometry data to the
configuration file"

2) Perform a screen geometry check at load time to see if the corners
of the main window would be visible before applying the main window
geometry.

I don't see the benefit of this. I really rather believe that window
geometry is the job of the window manager. If Cygwin needs it, then
maybe it could be conditionally compiled on that platform.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
quantum mechanics: the dreams stuff is made of.
 
spamtraps: madduck.bogus@madduck.net

On Tue, Feb 26, 2008 at 2:35 AM, Mark Levedahl [off-list ref] wrote:

 2) Perform a screen geometry check at load time to see if the corners
 of the main window would be visible before applying the main window
 geometry.

As a multi-screen-layouts, multi-machine user, this approach has my
vote. I see a proto-patch from Edgar too. Even if the wm has similar
capabilities, those will be limited to main window geometry, not
inner-panel geometry so this is still useful.

cheers,


m

måndagen den 25 februari 2008 skrev Martin Langhoff:

On Tue, Feb 26, 2008 at 2:35 AM, Mark Levedahl [off-list ref] wrote:

quoted

 2) Perform a screen geometry check at load time to see if the corners
 of the main window would be visible before applying the main window
 geometry.

As a multi-screen-layouts, multi-machine user, this approach has my
vote. I see a proto-patch from Edgar too. Even if the wm has similar
capabilities, those will be limited to main window geometry, not
inner-panel geometry so this is still useful.

The annoying part is that it remembers the position. Remembering siz
I can live with, but I don't want it popping up the wrong screen.

-- robin

Paul Mackerras wrote:

Gerrit Pape writes:

quoted

Saving the geometry can cause several inconveniences, e.g. when using a
temporary dual screen setup, or sharing ~/.gitk between multiple
systems.  Additionally it can be argued that window placement and sizing
are the tasks of the window manager.  So don't do that anymore.

I myself find it useful to have gitk remember the size and layout of
the various panes, so I won't be applying this patch.

The saving/restoring of the window position was done by Mark Levedahl
to make gitk work properly on Cygwin.  I agree it can be annoying on X
and I would take a patch to inhibit the restoring of the window
position when running under X.  I'd want an ack from Mark before
making that change more generally.

I use gitk under X and like the saving/restoring of window 
size/geometry. Please do not remove that feature.

Mark Levedahl writes:

I can only offer to test the proposed patch, I am unable to predict what 
will or won't trip up the buggy geometry engine in Cygwin's Tk. I do 
remember I had trouble finding a way to restore the size but not the 
position of the main window on Cygwin: that doesn't mean it can't be 
done (logically, it should be easy), just that I didn't find the right 
spell or incantation that would work. I'll also admit to not having 
tried after I got to a completely working geometry solution, so perhaps 
just restoring the size without position will now work on Cygwin.

Using the saved panel sizes in conjunction with the default window size 
yields an unusable screen: many elements are obscured. The same occurs 
using the defaults altogether: either way the user must resize and 
adjust things to get to a workable layout. So, I am very opposed to 
disabling the memory altogether. Also, I have a number of X apps that 
remember their layout, so gitk's current behavior is not (at least to 
me) an aberration and I would like that behavior to at least remain an 
option.

Here's a patch for people to test.  It only restores the width and
height, and limits the width and height to be at most the width and
height of the screen.  It seems to work fine under X; I would be
interested to know what happens under macos and windows.

Paul.
---

diff --git a/gitk b/gitk
index f1f21e9..f8f006f 100755
--- a/gitk
+++ b/gitk

@@ -930,9 +930,17 @@ proc makewindow {} {
     .pwbottom add .bright
     .ctop add .pwbottom
 
-    # restore window position if known
+    # restore window width & height if known
     if {[info exists geometry(main)]} {
-        wm geometry . "$geometry(main)"
+	if {[scan $geometry(main) "%dx%d" w h] >= 2} {
+	    if {$w > [winfo screenwidth .]} {
+		set w [winfo screenwidth .]
+	    }
+	    if {$h > [winfo screenheight .]} {
+		set h [winfo screenheight .]
+	    }
+	    wm geometry . "${w}x$h"
+	}
     }
 
     if {[tk windowingsystem] eq {aqua}} {

On Thu, Mar 6, 2008 at 12:17 PM, Paul Mackerras [off-list ref] wrote:

Mark Levedahl writes:

 > I can only offer to test the proposed patch, I am unable to predict what
 > will or won't trip up the buggy geometry engine in Cygwin's Tk. I do
 > remember I had trouble finding a way to restore the size but not the
 > position of the main window on Cygwin: that doesn't mean it can't be
 > done (logically, it should be easy), just that I didn't find the right
 > spell or incantation that would work. I'll also admit to not having
 > tried after I got to a completely working geometry solution, so perhaps
 > just restoring the size without position will now work on Cygwin.
 >
 > Using the saved panel sizes in conjunction with the default window size
 > yields an unusable screen: many elements are obscured. The same occurs
 > using the defaults altogether: either way the user must resize and
 > adjust things to get to a workable layout. So, I am very opposed to
 > disabling the memory altogether. Also, I have a number of X apps that
 > remember their layout, so gitk's current behavior is not (at least to
 > me) an aberration and I would like that behavior to at least remain an
 > option.

 Here's a patch for people to test.  It only restores the width and
 height, and limits the width and height to be at most the width and
 height of the screen.  It seems to work fine under X; I would be
 interested to know what happens under macos and windows.

 Paul.
 ---
 diff --git a/gitk b/gitk
 index f1f21e9..f8f006f 100755
 --- a/gitk
 +++ b/gitk
 @@ -930,9 +930,17 @@ proc makewindow {} {
     .pwbottom add .bright
     .ctop add .pwbottom

 -    # restore window position if known
 +    # restore window width & height if known
     if {[info exists geometry(main)]} {
 -        wm geometry . "$geometry(main)"
 +       if {[scan $geometry(main) "%dx%d" w h] >= 2} {
 +           if {$w > [winfo screenwidth .]} {
 +               set w [winfo screenwidth .]
 +           }
 +           if {$h > [winfo screenheight .]} {
 +               set h [winfo screenheight .]
 +           }
 +           wm geometry . "${w}x$h"
 +       }
     }

     if {[tk windowingsystem] eq {aqua}} {

 --

This almost works on OS X.  The only problem is that it's not taking
into account menubars and windowbars.  eg, if I have a screen
resolution of 640x480, setting the window _content_ to that size will
make the entire window including its titlebar about 500px tall.  Not
only that, but the system-wide menubar at the top of the screen also
reduces the available space, meaning that the maximum window size
ought to be around 640x456.  (If you wanted to get even pickier, that
will changing depending on the interface resolution...)

Presumably your patch does nothing to move gitk back on screen if the
monitor it was on last time has gone away?  Or are we still blaming
the window manager for that?

Jonathan del Strother writes:

This almost works on OS X.  The only problem is that it's not taking
into account menubars and windowbars.  eg, if I have a screen
resolution of 640x480, setting the window _content_ to that size will
make the entire window including its titlebar about 500px tall.  Not
only that, but the system-wide menubar at the top of the screen also
reduces the available space, meaning that the maximum window size
ought to be around 640x456.  (If you wanted to get even pickier, that
will changing depending on the interface resolution...)

Do you know of any way for an application to determine how big it can
be, then?

Presumably your patch does nothing to move gitk back on screen if the
monitor it was on last time has gone away?  Or are we still blaming
the window manager for that?

With the patch it no longer specifies a position, so yes we blame the
window manager now if it doesn't put the window somewhere visible. :)

Paul.

Paul Mackerras wrote:

This works fine on Cygwin: the size restores properly across sessions, 
the window and widgets all behave as expected. So, you can add a  
"Tested-by: Mark Levedahl <mlevedahl@gmail.com" if you wish to this.

Mark

also sprach Paul Mackerras [off-list ref] [2008.03.06.1317 +0100]:

Here's a patch for people to test.  It only restores the width and
height, and limits the width and height to be at most the width and
height of the screen.  It seems to work fine under X; I would be
interested to know what happens under macos and windows.

I can confirm that the behaviour is much better: the window size is
restored, as is the position, but it gives preference to the
Xinerama head. You'd think it restores at the same *relative*
position on the current head, but it actually just restores
somewhere — I cannot figure out the behaviour.

However, I still wonder why we have to do this at all. I understand
that Cygwin has issues and needs this code, but couldn't it then be
made to run only on Cygwin, such that on "proper" Unix systems, the
config file is *not* updated every time I move the window before
closing the application? As I said earlier, this is really the job
of a window manager, *not* a configuration option. If your window
manager cannot restore the window to a size you control, then it's
broken. Let's not hack applications to work around that, please.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
$complex->{'data'}[$structures][$in_perl] = @{$can{'be'}->[$painful]};
 
spamtraps: madduck.bogus@madduck.net

martin f krafft writes:

I can confirm that the behaviour is much better: the window size is
restored, as is the position, but it gives preference to the
Xinerama head. You'd think it restores at the same *relative*
position on the current head, but it actually just restores
somewhere $,1rt(B I cannot figure out the behaviour.

The position is entirely up to your window manager.

However, I still wonder why we have to do this at all.

Well, try it without... :)

Restoring the overall window size and the positions of the sashes of
the panedwindows is the simplest and most reliable method I have found
for making the window come back the way the user last set it.

I understand
that Cygwin has issues and needs this code, but couldn't it then be
made to run only on Cygwin, such that on "proper" Unix systems, the
config file is *not* updated every time I move the window before
closing the application?

What's the issue with updating the config file?

As I said earlier, this is really the job
of a window manager, *not* a configuration option. If your window
manager cannot restore the window to a size you control, then it's
broken. Let's not hack applications to work around that, please.

I disagree.  It's not a window manager's job to tell an application
how big its window should be.

Paul.

also sprach Paul Mackerras [off-list ref] [2008.03.08.1211 +0100]:

quoted

I understand that Cygwin has issues and needs this code, but
couldn't it then be made to run only on Cygwin, such that on
"proper" Unix systems, the config file is *not* updated every
time I move the window before closing the application?

What's the issue with updating the config file?

Conflicts when synchronising the files between different machines,
or the need for a custom merge driver just for .gitkrc files.

quoted

As I said earlier, this is really the job of a window manager,
*not* a configuration option. If your window manager cannot
restore the window to a size you control, then it's broken.
Let's not hack applications to work around that, please.

I disagree.  It's not a window manager's job to tell an
application how big its window should be.

I always assumed it was: position and geometry. However, I am
starting to see your point.

I guess the best way would be a checkbox with which I can disable
the saving of the geometry on application close, possibly paired
with a button "save now".

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
an egg has the shortest sex-life of all: if gets laid once; it gets
eaten once. it also has to come in a box with 11 others, and the
only person who will sit on its face is its mother.
 
spamtraps: madduck.bogus@madduck.net

2008/3/8 Paul Mackerras [off-list ref]:

 > As I said earlier, this is really the job
 > of a window manager, *not* a configuration option. If your window
 > manager cannot restore the window to a size you control, then it's
 > broken. Let's not hack applications to work around that, please.

 I disagree.  It's not a window manager's job to tell an application
 how big its window should be.

There are some modestly popular tiling window managers that attempt to
remove the bother of having to manually move windows around which take
the view that the window manager's decisions should only be overruled
in the very rare cases where it's absolutely necessary, eg,

Ion http://modeemi.fi/~tuomov/ion/
dwm http://www.suckless.org/wiki/dwm

(The major windows that don't resize well are from image based
programs where you want exactly the underlying image on your display.
Text based programs like gitk work great under autoresizing.) However,
the current gitk appears to work fine on those window managers because
the internal dividers get automtatically resized whenever the global
window resizes, and the wm resizes the window so quickly after
creation I don't have time to notice it.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot