summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authordkf <donal.k.fellows@manchester.ac.uk>2011-07-17 14:53:45 (GMT)
committerdkf <donal.k.fellows@manchester.ac.uk>2011-07-17 14:53:45 (GMT)
commit97936b2be7f8229e4bba82c31bf4c5cca36ec874 (patch)
tree718c7eabacd8c46f4ac0ee25dae2f5a162810968
parent597fa538d80c82d2abf3ca76cb39e58b1ff52d63 (diff)
downloadtk-97936b2be7f8229e4bba82c31bf4c5cca36ec874.zip
tk-97936b2be7f8229e4bba82c31bf4c5cca36ec874.tar.gz
tk-97936b2be7f8229e4bba82c31bf4c5cca36ec874.tar.bz2
Minor documentation improvements
-rw-r--r--doc/GetPixels.32
-rw-r--r--doc/lower.n4
-rw-r--r--doc/raise.n4
3 files changed, 9 insertions, 1 deletions
diff --git a/doc/GetPixels.3 b/doc/GetPixels.3
index 05fe902..287e734 100644
--- a/doc/GetPixels.3
+++ b/doc/GetPixels.3
@@ -84,7 +84,7 @@ value in \fIobjPtr\fR, which speeds up future calls to
\fBTk_GetPixels\fR is identical to \fBTk_GetPixelsFromObj\fR except
that the screen distance is specified with a string instead
of an object. This prevents \fBTk_GetPixels\fR from caching the
-return value, so \fBTk_GetAnchor\fR is less efficient than
+return value, so \fBTk_GetPixels\fR is less efficient than
\fBTk_GetPixelsFromObj\fR.
.PP
\fBTk_GetMMFromObj\fR and \fBTk_GetScreenMM\fR are similar to
diff --git a/doc/lower.n b/doc/lower.n
index d3b232d..0d8f252 100644
--- a/doc/lower.n
+++ b/doc/lower.n
@@ -27,6 +27,10 @@ In this case the \fBlower\fR command will insert
\fIwindow\fR into the stacking order just below \fIbelowThis\fR
(or the ancestor of \fIbelowThis\fR that is a sibling of \fIwindow\fR);
this could end up either raising or lowering \fIwindow\fR.
+.PP
+All \fBtoplevel\fR windows may be restacked with respect to each
+other, whatever their relative path names, but the window manager is
+not obligated to strictly honor requests to restack.
.SH "SEE ALSO"
raise
.SH KEYWORDS
diff --git a/doc/raise.n b/doc/raise.n
index d2a48ba..b2856c1 100644
--- a/doc/raise.n
+++ b/doc/raise.n
@@ -27,6 +27,10 @@ In this case the \fBraise\fR command will insert
\fIwindow\fR into the stacking order just above \fIaboveThis\fR
(or the ancestor of \fIaboveThis\fR that is a sibling of \fIwindow\fR);
this could end up either raising or lowering \fIwindow\fR.
+.PP
+All \fBtoplevel\fR windows may be restacked with respect to each
+other, whatever their relative path names, but the window manager is
+not obligated to strictly honor requests to restack.
.SH EXAMPLE
.PP
Make a button appear to be in a sibling frame that was created after