[Bug 3538401]: Better description of the key difference between [wm geometry]

and [winfo geometry]

2 files changed, 15 insertions, 0 deletions

diff --git a/ChangeLog b/ChangeLog
index d10e8f8..78cdf6e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-07-05  Donal K. Fellows  <dkf@users.sf.net>
+
+	* doc/wm.n (geometry): [Bug 3538401]: Better description of the key
+	difference between [wm geometry] and [winfo geometry]; the former
+	represents the window manager's understanding, not Tk's.
+
 2012-07-04  Donal K. Fellows  <dkf@users.sf.net>
 
 	* win/tkWinDialog.c (GetFileNameW): [Bug 3540127]: Clean up the tables
diff --git a/doc/wm.n b/doc/wm.n
index 93858ef..799057a 100644
--- a/doc/wm.n
+++ b/doc/wm.n
@@ -260,6 +260,15 @@ If \fInewGeometry\fR is specified as an empty string then any
 existing user-specified geometry for \fIwindow\fR is cancelled, and
 the window will revert to the size requested internally by its
 widgets.
+.PP
+Note that this is related to \fBwinfo geometry\fR, but not the same. That can
+only query the geometry, and always reflects Tk's current understanding of the
+actual size and location of \fIwindow\fR, whereas \fBwm geometry\fR allows
+both setting and querying of the \fIwindow manager\fR's understanding of the
+size and location of the window. This can vary significantly, for example to
+reflect the addition of decorative elements to \fIwindow\fR such as title
+bars, and window managers are not required to precisely follow the requests
+made through this command.
 .RE
 .TP
 \fBwm grid \fIwindow\fR ?\fIbaseWidth baseHeight widthInc heightInc\fR?