It transpires that the behaviour of [[wm geometry ...]] is quite different between the standard Tk platforms. This page is to document those differences (since the wm man page doesn't do so). The main differences are between whether this command manipulates/queries the entire window including borders/titlebar or just the contents, and in what aspects can be set/queried during a window's creation or while it is withdrawn. '''Difference 1: wm geometry . +0+0''' ''Windows'' and ''MacOS X'' -- 'wm geometry . +0+0' will move the main toplevel so that it nestles into the top-left corner of the screen, with the left border and titlebar completely visible. ''X11'' -- 'wm geometry . +0+0' will move the main toplevel so that its contents are nestled into the top-left corner of the screen, but with the left border and titlebar completely ''offscreen and invisible''. In summary ''positioning with wm geometry controls the window contents on X11, but the window structure on Windows/MacOS X''. This is in contrast to ''winfo rooty/rootx $w'' which deals with window contents on all platforms. [JE] This depends on the window manager. Under metacity (Gnome's WM), twm, and others, '''wm geometry . +$x+$y''' places the upper-left corner of the window decoration at $x,$y; under MWM and 4DWM, it places the upper-left corner of the window contents there. I'm pretty sure this is because tkUnixWm.c isn't doing the right thing according to the ICCCM -- it looks like it's ''trying'' to implement the first behaviour (place window decorations), but it does so by attempting to second-guess what the WM is going to do. Under many WMs, it guesses wrong. '''Difference 2: window decoration geometry''' Because of Difference 1, the following proc proc decorationGeometry {{w .}} { set geom [wm geometry $w] regexp -- {([0-9]+)x([0-9]+)\+([0-9]+)\+([0-9]+)} $geom -> \ width height decorationLeft decorationTop set contentsTop [winfo rooty $w] set contentsLeft [winfo rootx $w] # Measure left edge, and assume all edges except top are the # same thickness set decorationThickness [expr {$contentsLeft - $decorationLeft}] # Find titlebar + menubar (if it exists) thickness set titleMenubarThickness [expr {$contentsTop - $decorationTop}] return [list $titleMenubarThickness $decorationThickness] } Is only useful on MacOS X/Windows (where it returns the thickness of the titlebar/menubar and the thickness of the left window border). On X11, it simply returns ''0 0''. '''Difference 3: geometry of withdraw windows''' On immediate creation: toplevel .tt ; wm withdraw .tt ; wm geometry .tt will return 1x1+0+0 on all platforms, but: toplevel .tt ; wm withdraw .tt ; update; wm geometry .tt will return 1x1+0+0 on X11 and 200x200+198+261 (or something similar) on Windows (still need to test OS X). Similarly, ''winfo height .tt'' will return (of course) 1 on x11 and 200 on Windows. A constant here is that ''winfo reqheight .tt'' will return 200 (or equivalent) on all platforms. So there is at least a workaround for this difference in behaviour. [LES] on May 27, 2004: I've been doing experiments and also get '''200''' in [winfo reqheight] consistently. The text above says that [winfo reqheight] '''will''' return '''200'''. What is the use of a variable whose value is always the same? '''Difference 4: ...''' ---- More to be filled in. ... ---- [Category GUI]