1 |
578 |
markom |
'\"
|
2 |
|
|
'\" Copyright (c) 1994 The Regents of the University of California.
|
3 |
|
|
'\" Copyright (c) 1994-1996 Sun Microsystems, Inc.
|
4 |
|
|
'\"
|
5 |
|
|
'\" See the file "license.terms" for information on usage and redistribution
|
6 |
|
|
'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
|
7 |
|
|
'\"
|
8 |
|
|
'\" RCS: @(#) $Id: MaintGeom.3,v 1.1.1.1 2002-01-16 10:25:48 markom Exp $
|
9 |
|
|
'\"
|
10 |
|
|
.so man.macros
|
11 |
|
|
.TH Tk_MaintainGeometry 3 4.0 Tk "Tk Library Procedures"
|
12 |
|
|
.BS
|
13 |
|
|
.SH NAME
|
14 |
|
|
Tk_MaintainGeometry, Tk_UnmaintainGeometry \- maintain geometry of one window relative to another
|
15 |
|
|
.SH SYNOPSIS
|
16 |
|
|
.nf
|
17 |
|
|
\fB#include \fR
|
18 |
|
|
.sp
|
19 |
|
|
\fBTk_MaintainGeometry\fR(\fIslave, master, x, y, width, height\fR)
|
20 |
|
|
.sp
|
21 |
|
|
\fBTk_UnmaintainGeometry\fR(\fIslave, master\fR)
|
22 |
|
|
.SH ARGUMENTS
|
23 |
|
|
.AS Tk_Window master
|
24 |
|
|
.AP Tk_Window slave in
|
25 |
|
|
Window whose geometry is to be controlled.
|
26 |
|
|
.AP Tk_Window master in
|
27 |
|
|
Window relative to which \fIslave\fR's geometry will be controlled.
|
28 |
|
|
.AP int x in
|
29 |
|
|
Desired x-coordinate of \fIslave\fR in \fImaster\fR, measured in pixels
|
30 |
|
|
from the inside of \fImaster\fR's left border to the outside of
|
31 |
|
|
\fIslave\fR's left border.
|
32 |
|
|
.AP int y in
|
33 |
|
|
Desired y-coordinate of \fIslave\fR in \fImaster\fR, measured in pixels
|
34 |
|
|
from the inside of \fImaster\fR's top border to the outside of
|
35 |
|
|
\fIslave\fR's top border.
|
36 |
|
|
.AP int width in
|
37 |
|
|
Desired width for \fIslave\fR, in pixels.
|
38 |
|
|
.AP int height in
|
39 |
|
|
Desired height for \fIslave\fR, in pixels.
|
40 |
|
|
.BE
|
41 |
|
|
|
42 |
|
|
.SH DESCRIPTION
|
43 |
|
|
.PP
|
44 |
|
|
\fBTk_MaintainGeometry\fR and \fBTk_UnmaintainGeometry\fR make it
|
45 |
|
|
easier for geometry managers to deal with slaves whose masters are not
|
46 |
|
|
their parents.
|
47 |
|
|
Three problems arise if the master for a slave is not its parent:
|
48 |
|
|
.IP [1]
|
49 |
|
|
The x- and y-position of the slave must be translated from the
|
50 |
|
|
coordinate system of the master to that of the parent before
|
51 |
|
|
positioning the slave.
|
52 |
|
|
.IP [2]
|
53 |
|
|
If the master window, or any of its ancestors up to the slave's
|
54 |
|
|
parent, is moved, then the slave must be repositioned within its
|
55 |
|
|
parent in order to maintain the correct position relative to the
|
56 |
|
|
master.
|
57 |
|
|
.IP [3]
|
58 |
|
|
If the master or one of its ancestors is mapped or unmapped, then
|
59 |
|
|
the slave must be mapped or unmapped to correspond.
|
60 |
|
|
.LP
|
61 |
|
|
None of these problems is an issue if the parent and master are
|
62 |
|
|
the same. For example, if the master or one of its ancestors
|
63 |
|
|
is unmapped, the slave is automatically removed by the screen
|
64 |
|
|
by X.
|
65 |
|
|
.PP
|
66 |
|
|
\fBTk_MaintainGeometry\fR deals with these problems for slaves
|
67 |
|
|
whose masters aren't their parents.
|
68 |
|
|
\fBTk_MaintainGeometry\fR is typically called by a window manager
|
69 |
|
|
once it has decided where a slave should be positioned relative
|
70 |
|
|
to its master.
|
71 |
|
|
\fBTk_MaintainGeometry\fR translates the coordinates to the
|
72 |
|
|
coordinate system of \fIslave\fR's parent and then moves and
|
73 |
|
|
resizes the slave appropriately.
|
74 |
|
|
Furthermore, it remembers the desired position and creates event
|
75 |
|
|
handlers to monitor the master and all of its ancestors up
|
76 |
|
|
to (but not including) the slave's parent.
|
77 |
|
|
If any of these windows is moved, mapped, or unmapped,
|
78 |
|
|
the slave will be adjusted so that it is mapped only when the
|
79 |
|
|
master is mapped and its geometry relative to the master
|
80 |
|
|
remains as specified by \fIx\fR, \fIy\fR, \fIwidth\fR, and
|
81 |
|
|
\fIheight\fR.
|
82 |
|
|
.PP
|
83 |
|
|
When a window manager relinquishes control over a window, or
|
84 |
|
|
if it decides that it does not want the window to appear on the
|
85 |
|
|
screen under any conditions, it calls \fBTk_UnmaintainGeometry\fR.
|
86 |
|
|
\fBTk_UnmaintainGeometry\fR unmaps the window and cancels any
|
87 |
|
|
previous calls to \fBTk_MaintainGeometry\fR for the
|
88 |
|
|
\fImaster\fR\-\fIslave\fR pair, so that the slave's
|
89 |
|
|
geometry and mapped state are no longer maintained
|
90 |
|
|
automatically.
|
91 |
|
|
\fBTk_UnmaintainGeometry\fR need not be called by a geometry
|
92 |
|
|
manager if the slave, the master, or any of the master's ancestors
|
93 |
|
|
is destroyed: Tk will call it automatically.
|
94 |
|
|
.PP
|
95 |
|
|
If \fBTk_MaintainGeometry\fR is called repeatedly for the same
|
96 |
|
|
\fImaster\fR\-\fIslave\fR pair, the information from the most
|
97 |
|
|
recent call supersedes any older information.
|
98 |
|
|
If \fBTk_UnmaintainGeometry\fR is called for a \fImaster\fR\-\fIslave\fR
|
99 |
|
|
pair that is isn't currently managed, the call has no effect.
|
100 |
|
|
|
101 |
|
|
.SH KEYWORDS
|
102 |
|
|
geometry manager, map, master, parent, position, slave, unmap
|