Tk Source Code

Check-in [7a32076a]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Minor documentation improvements
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 7a32076a08024b4b4bffeae0cdf83af7a5e4ef3d
User & Date: dkf 2011-07-17 14:53:45
Context
2011-07-18
03:40
Fix issue with shift key firing twice if bound to different procedure check-in: 40df0abf user: kevin_walzer tags: trunk
2011-07-17
14:53
Minor documentation improvements check-in: 7a32076a user: dkf tags: trunk
2011-06-29
21:35
3341056 Correct segfault due to flaw in the 2011-06-17 commit. check-in: 88ddbd6b user: dgp tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to doc/GetPixels.3.

80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
\fBTk_GetPixelsFromObj\fR caches information about the return
value in \fIobjPtr\fR, which speeds up future calls to
\fBTk_GetPixelsFromObj\fR with the same \fIobjPtr\fR.
.PP
\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
\fBTk_GetPixelsFromObj\fR.
.PP
\fBTk_GetMMFromObj\fR and \fBTk_GetScreenMM\fR are similar to
\fBTk_GetPixelsFromObj\fR and \fBTk_GetPixels\fR (respectively) except
that they convert the screen distance to millimeters and
store a double-precision floating-point result at \fI*doublePtr\fR.
.SH KEYWORDS







|







80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
\fBTk_GetPixelsFromObj\fR caches information about the return
value in \fIobjPtr\fR, which speeds up future calls to
\fBTk_GetPixelsFromObj\fR with the same \fIobjPtr\fR.
.PP
\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_GetPixels\fR is less efficient than
\fBTk_GetPixelsFromObj\fR.
.PP
\fBTk_GetMMFromObj\fR and \fBTk_GetScreenMM\fR are similar to
\fBTk_GetPixelsFromObj\fR and \fBTk_GetPixels\fR (respectively) except
that they convert the screen distance to millimeters and
store a double-precision floating-point result at \fI*doublePtr\fR.
.SH KEYWORDS

Changes to doc/lower.n.

23
24
25
26
27
28
29




30
31
32
33
34
35
36
If \fIbelowThis\fR is specified then it must be the path name of
a window that is either a sibling of \fIwindow\fR or the descendant
of a sibling of \fIwindow\fR.
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.




.SH "SEE ALSO"
raise
.SH KEYWORDS
lower, obscure, stacking order
'\" Local Variables:
'\" mode: nroff
'\" End:







>
>
>
>







23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
If \fIbelowThis\fR is specified then it must be the path name of
a window that is either a sibling of \fIwindow\fR or the descendant
of a sibling of \fIwindow\fR.
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
lower, obscure, stacking order
'\" Local Variables:
'\" mode: nroff
'\" End:

Changes to doc/raise.n.

23
24
25
26
27
28
29




30
31
32
33
34
35
36
If \fIaboveThis\fR is specified then it must be the path name of
a window that is either a sibling of \fIwindow\fR or the descendant
of a sibling of \fIwindow\fR.
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.




.SH EXAMPLE
.PP
Make a button appear to be in a sibling frame that was created after
it. This is is often necessary when building GUIs in the style where
you create your activity widgets first before laying them out on the
display:
.CS







>
>
>
>







23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
If \fIaboveThis\fR is specified then it must be the path name of
a window that is either a sibling of \fIwindow\fR or the descendant
of a sibling of \fIwindow\fR.
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
it. This is is often necessary when building GUIs in the style where
you create your activity widgets first before laying them out on the
display:
.CS