head	1.13;
access;
symbols
	core-8-5-9:1.11
	core-8-5-8:1.11
	macosx-cocoa-merge:1.13
	macosx-cocoa-premerge:1.13
	macosx-carbon-freeze:1.13
	core-8-5-7:1.11
	core-8-5-6:1.11
	core-8-6-b1:1.13
	core-8-6-a3:1.13
	core-8-5-5:1.11
	core-8-6-a2:1.12
	core-8-5-4:1.11
	core-8-5-3:1.11
	core-8-6-a1:1.11
	core-8-4-19:1.3.8.1
	core-8-5-branch:1.11.0.2
	core-8-5-2:1.11
	core-8-4-18:1.3.8.1
	core-8-5-1:1.11
	core-8-4-17:1.3.8.1
	core-8-5-0:1.11
	core-8-5-b3:1.10
	core-8-5-b2:1.9
	core-8-4-16:1.3.8.1
	core-8-5-b1:1.7
	core-stablilizer-merge:1.7
	core-stabilizer-branch:1.7.0.2
	core-stabilizer-merge:1.11
	core-8-4-15:1.3.8.1
	core-8-5-a6:1.7
	core-8-5-a5:1.7
	core-8-4-14:1.3.8.1
	core-8-5-a4:1.7
	core-8-4-13:1.3.8.1
	core-8-4-12:1.3.8.1
	core-8-4-11:1.3.8.1
	core-8-5-a3:1.7
	core-8-4-10:1.3.8.1
	core-8-4-9-branch:1.3.8.1.0.2
	core-8-5-a2:1.7
	core-8-4-9:1.3.8.1
	core-8-4-8:1.3.8.1
	core-8-4-7:1.3
	core-8-5-a1:1.3
	core-8-4-6:1.3
	core-8-4-5:1.3
	mistachkin-dev-branch:1.3.0.10
	core-8-4-4:1.3
	core-8-4-3:1.3
	core-8-4-branch:1.3.0.8
	core-8-4-2:1.3
	core-8-4-1:1.3
	core-8-3-5:1.2
	core-8-4-0:1.3
	macosx-8-4-merge-2002-08-31-trunk:1.3
	macosx-8-4-premerge-2002-08-31-branch:1.3
	macosx-8-4-premerge-2002-08-31-trunk:1.3
	macosx-8-4-merge-2002-08-30-branch:1.3
	macosx-8-4-merge-2002-08-30-trunk:1.3
	macosx-8-4-merge-2002-08-20-branch:1.3
	macosx-8-4-merge-2002-08-20-trunk:1.3
	core-8-4-b2:1.3
	core-8-4-b1:1.3
	macosx-premerge-6-9-02:1.3
	core-8-4-a4:1.3
	core-8-3-4:1.2
	macosx-8-4-branch:1.3.0.6
	macosx-8-4-branchpoint:1.3
	core-8-4-a3:1.3
	core-8-3-3:1.2
	dgp-privates-into-namespace:1.3.0.4
	tclpro-1-5-0:1.2
	core-8-4-win-speedup:1.3.0.2
	core-8-4-a2:1.3
	tclpro-1-4-1:1.2
	tclpro-1-4-0:1.2
	core-8-3-2:1.2
	ajuba-ajuba2-2-1-base:1.2
	ajuba-ajuba2-2-0:1.2
	core-8-4-a1:1.2
	core-8-3-1-branch:1.2.0.18
	core-8-3-1:1.2
	scriptics-sc-2-0-b5:1.2
	scriptics-sc-2-0-fixed:1.2
	scriptics-sc-2-0-b2:1.2
	scriptics-sc-2-0-b1:1.2
	core-8-3-0:1.2
	core-8-3-b2:1.2
	core-8-3-b1:1.2
	scriptics-sc-1-1:1.2
	scriptics-sc-1-1-b1:1.2
	core-8-2-3:1.2
	scriptics-sc-1-1-branch:1.2.0.16
	scriptics-sc-1-1-base:1.2
	scriptics-sc-1-0:1.2
	scriptics-sc-1-0-branch:1.2.0.14
	scriptics-sc-1-0-base:1.2
	core-8-2-2:1.2
	core-8-2-1:1.2
	scriptics-bc-1-0-b1:1.2
	core-8-2-1-branch:1.2.0.12
	scriptics-tclpro-1-3-0:1.2
	core-8-2-0:1.2
	core-8-2-b3-branch:1.2.0.10
	core-8-2-b3-base:1.2
	scriptics-tclpro-1-3-b4:1.2
	core-8-2-b2:1.2
	scriptics-tclpro-1-3-b3:1.2
	core-8-2-b1:1.2
	scriptics-tclpro-1-3-b2:1.2
	merge-to-mainline-5/21/99:1.2
	scriptics-tclpro-1-3-b2-branch:1.2.0.8
	core-8-1-1:1.2
	scriptics-tclpro-1-3-b1:1.2
	core-8-1-1-base:1.2
	core-8-1-0:1.2
	merge-to-mainline-4-29-99:1.2
	merge-to-mainline-4-23-99:1.2
	core-8-1-branch-old:1.1.0.4
	core-8-0-6-branch:1.2.0.6
	core-8-0-6-base:1.2
	core-8-0-5:1.2
	core-8-1-b3:1.1.4.1
	core-8-1-b2:1.1.4.1
	dev-8-1-stubs-branch:1.1.4.1.0.2
	dev-stubs-branch:1.2.0.4
	scriptics-tclpro-1-2:1.2
	scriptics-tclpro-1-2-b2:1.2
	core-8-1-merge-2/10/99:1.2
	core-8-0-5-branch:1.2.0.2
	core-8-0-5-base:1.2
	scriptics-tclpro-1-2-b1:1.2
	scriptics-tclpro-1-2-a1:1.2
	core-8-1-b1:1.1.4.1
	core-8-0-4:1.2
	core-8-1-a2:1.1
	core-8-0-2:1.1
	core-8-0-3:1.2;
locks; strict;
comment	@# @;


1.13
date	2008.09.23.13.36.46;	author dkf;	state Exp;
branches;
next	1.12;

1.12
date	2008.06.30.22.57.03;	author dkf;	state Exp;
branches;
next	1.11;

1.11
date	2007.12.13.15.23.43;	author dgp;	state Exp;
branches;
next	1.10;

1.10
date	2007.10.29.16.04.14;	author dkf;	state Exp;
branches;
next	1.9;

1.9
date	2007.10.26.20.13.23;	author dgp;	state Exp;
branches;
next	1.8;

1.8
date	2007.10.24.14.32.58;	author dkf;	state Exp;
branches;
next	1.7;

1.7
date	2004.08.20.10.56.36;	author dkf;	state Exp;
branches
	1.7.2.1;
next	1.6;

1.6
date	2004.07.01.08.06.15;	author dkf;	state Exp;
branches;
next	1.5;

1.5
date	2004.06.21.20.42.21;	author dkf;	state Exp;
branches;
next	1.4;

1.4
date	2004.06.21.15.21.24;	author dkf;	state Exp;
branches;
next	1.3;

1.3
date	2000.08.10.00.21.06;	author ericm;	state Exp;
branches
	1.3.8.1;
next	1.2;

1.2
date	98.09.14.18.22.59;	author stanton;	state Exp;
branches;
next	1.1;

1.1
date	98.04.01.09.39.55;	author rjohnson;	state Exp;
branches
	1.1.4.1;
next	;

1.1.4.1
date	98.09.30.02.16.26;	author stanton;	state Exp;
branches;
next	;

1.3.8.1
date	2004.10.28.12.25.22;	author dkf;	state Exp;
branches;
next	;

1.7.2.1
date	2007.11.01.16.37.15;	author dgp;	state Exp;
branches;
next	;


desc
@@


1.13
log
@Fix [Bug 2118116]
@
text
@'\"
'\" Copyright (c) 1992 The Regents of the University of California.
'\" Copyright (c) 1994-1996 Sun Microsystems, Inc.
'\"
'\" See the file "license.terms" for information on usage and redistribution
'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
'\" 
'\" RCS: @@(#) $Id: place.n,v 1.12 2008/06/30 22:57:03 dkf Exp $
'\" 
.so man.macros
.TH place n "" Tk "Tk Built-In Commands"
.BS
'\" Note:  do not modify the .SH NAME line immediately below!
.SH NAME
place \- Geometry manager for fixed or rubber-sheet placement
.SH SYNOPSIS
\fBplace \fIoption arg \fR?\fIarg ...\fR?
.BE
.SH DESCRIPTION
.PP
The placer is a geometry manager for Tk.
It provides simple fixed placement of windows, where you specify
the exact size and location of one window, called the \fIslave\fR,
within another window, called the \fImaster\fR.
The placer also provides rubber-sheet placement, where you specify the
size and location of the slave in terms of the dimensions of
the master, so that the slave changes size and location
in response to changes in the size of the master.
Lastly, the placer allows you to mix these styles of placement so
that, for example, the slave has a fixed width and height but is
centered inside the master.
.PP
.TP
\fBplace \fIwindow option value \fR?\fIoption value ...\fR?
Arrange for the placer to manage the geometry of a slave whose
pathName is \fIwindow\fR.  The remaining arguments consist of one or
more \fIoption\-value\fR pairs that specify the way in which
\fIwindow\fR's geometry is managed.  \fIOption\fR may have any of the
values accepted by the \fBplace configure\fR command.
.TP
\fBplace configure \fIwindow \fR?\fIoption\fR? ?\fIvalue option value ...\fR?
Query or modify the geometry options of the slave given by
\fIwindow\fR.  If no \fIoption\fR is specified, this command returns a
list describing the available options (see \fBTk_ConfigureInfo\fR for
information on the format of this list).  If \fIoption\fR is specified
with no \fIvalue\fR, then the command returns a list describing the
one named option (this list will be identical to the corresponding
sublist of the value returned if no \fIoption\fR is specified).  If
one or more \fIoption\-value\fR pairs are specified, then the command
modifies the given option(s) to have the given value(s); in this case
the command returns an empty string.
.RS
.PP
The following \fIoption\-value\fR pairs are supported:
.TP
\fB\-anchor \fIwhere\fR
\fIWhere\fR specifies which point of \fIwindow\fR is to be positioned
at the (x,y) location selected by the \fB\-x\fR, \fB\-y\fR,
\fB\-relx\fR, and \fB\-rely\fR options.
The anchor point is in terms of the outer area of \fIwindow\fR
including its border, if any.
Thus if \fIwhere\fR is \fBse\fR then the lower-right corner of
\fIwindow\fR's border will appear at the given (x,y) location
in the master.
The anchor position defaults to \fBnw\fR.
.TP
\fB\-bordermode \fImode\fR
\fIMode\fR determines the degree to which borders within the
master are used in determining the placement of the slave.
The default and most common value is \fBinside\fR.
In this case the placer considers the area of the master to
be the innermost area of the master, inside any border:
an option of \fB\-x 0\fR corresponds to an x-coordinate just
inside the border and an option of \fB\-relwidth 1.0\fR
means \fIwindow\fR will fill the area inside the master's
border.
.RS
.PP
If \fImode\fR is \fBoutside\fR then the placer considers
the area of the master to include its border;
this mode is typically used when placing \fIwindow\fR
outside its master, as with the options \fB\-x 0 \-y 0 \-anchor ne\fR.
Lastly, \fImode\fR may be specified as \fBignore\fR, in which
case borders are ignored:  the area of the master is considered
to be its official X area, which includes any internal border but
no external border.  A bordermode of \fBignore\fR is probably
not very useful.
.RE
.TP
\fB\-height \fIsize\fR
\fISize\fR specifies the height for \fIwindow\fR in screen units
(i.e. any of the forms accepted by \fBTk_GetPixels\fR).
The height will be the outer dimension of \fIwindow\fR including its
border, if any.
If \fIsize\fR is an empty string, or if no \fB\-height\fR or
\fB\-relheight\fR option is specified, then the height requested
internally by the window will be used.
.TP
\fB\-in \fImaster\fR
\fIMaster\fR specifies the path name of the window relative
to which \fIwindow\fR is to be placed.
\fIMaster\fR must either be \fIwindow\fR's parent or a descendant
of \fIwindow\fR's parent.
In addition, \fImaster\fR and \fIwindow\fR must both be descendants
of the same top-level window.
These restrictions are necessary to guarantee
that \fIwindow\fR is visible whenever \fImaster\fR is visible.
If this option is not specified then the master defaults to
\fIwindow\fR's parent.
.TP
\fB\-relheight \fIsize\fR
\fISize\fR specifies the height for \fIwindow\fR.
In this case the height is specified as a floating-point number
relative to the height of the master: 0.5 means \fIwindow\fR will
be half as high as the master, 1.0 means \fIwindow\fR will have
the same height as the master, and so on.
If both \fB\-height\fR and \fB\-relheight\fR are specified for a slave,
their values are summed.  For example, \fB\-relheight 1.0 \-height \-2\fR
makes the slave 2 pixels shorter than the master.
.TP
\fB\-relwidth \fIsize\fR
\fISize\fR specifies the width for \fIwindow\fR.
In this case the width is specified as a floating-point number
relative to the width of the master: 0.5 means \fIwindow\fR will
be half as wide as the master, 1.0 means \fIwindow\fR will have
the same width as the master, and so on.
If both \fB\-width\fR and \fB\-relwidth\fR are specified for a slave,
their values are summed.  For example, \fB\-relwidth 1.0 \-width 5\fR
makes the slave 5 pixels wider than the master.
.TP
\fB\-relx \fIlocation\fR
\fILocation\fR specifies the x-coordinate within the master window
of the anchor point for \fIwindow\fR.
In this case the location is specified in a relative fashion
as a floating-point number:  0.0 corresponds to the left edge
of the master and 1.0 corresponds to the right edge of the master.
\fILocation\fR need not be in the range 0.0\-1.0.
If both \fB\-x\fR and \fB\-relx\fR are specified for a slave
then their values are summed.  For example, \fB\-relx 0.5 \-x \-2\fR
positions the left edge of the slave 2 pixels to the left of the
center of its master.
.TP
\fB\-rely \fIlocation\fR
\fILocation\fR specifies the y-coordinate within the master window
of the anchor point for \fIwindow\fR.
In this case the value is specified in a relative fashion
as a floating-point number:  0.0 corresponds to the top edge
of the master and 1.0 corresponds to the bottom edge of the master.
\fILocation\fR need not be in the range 0.0\-1.0.
If both \fB\-y\fR and \fB\-rely\fR are specified for a slave
then their values are summed.  For example, \fB\-rely 0.5 \-x 3\fR
positions the top edge of the slave 3 pixels below the
center of its master.
.TP
\fB\-width \fIsize\fR
\fISize\fR specifies the width for \fIwindow\fR in screen units
(i.e. any of the forms accepted by \fBTk_GetPixels\fR).
The width will be the outer width of \fIwindow\fR including its
border, if any.
If \fIsize\fR is an empty string, or if no \fB\-width\fR
or \fB\-relwidth\fR option is specified, then the width requested
internally by the window will be used.
.TP
\fB\-x \fIlocation\fR
\fILocation\fR specifies the x-coordinate within the master window
of the anchor point for \fIwindow\fR.
The location is specified in screen units (i.e. any of the forms
accepted by \fBTk_GetPixels\fR) and need not lie within the bounds
of the master window.
.TP
\fB\-y \fIlocation\fR
\fILocation\fR specifies the y-coordinate within the master window
of the anchor point for \fIwindow\fR.
The location is specified in screen units (i.e. any of the forms
accepted by \fBTk_GetPixels\fR) and need not lie within the bounds
of the master window.
.PP
If the same value is specified separately with
two different options, such as \fB\-x\fR and \fB\-relx\fR, then
the most recent option is used and the older one is ignored.
.RE
.TP
\fBplace forget \fIwindow\fR
Causes the placer to stop managing the geometry of \fIwindow\fR.  As a
side effect of this command \fIwindow\fR will be unmapped so that it
does not appear on the screen.  If \fIwindow\fR is not currently managed
by the placer then the command has no effect.  This command returns an
empty string.
.TP
\fBplace info \fIwindow\fR
Returns a list giving the current configuration of \fIwindow\fR.
The list consists of \fIoption\-value\fR pairs in exactly the
same form as might be specified to the \fBplace configure\fR
command.
.TP
\fBplace slaves \fIwindow\fR
Returns a list of all the slave windows for which \fIwindow\fR is the master.
If there are no slaves for \fIwindow\fR then an empty string is returned.
.PP
If the configuration of a window has been retrieved with
\fBplace info\fR, that configuration can be restored later by
first using \fBplace forget\fR to erase any existing information
for the window and then invoking \fBplace configure\fR with
the saved information.
.SH "FINE POINTS"
.PP
It is not necessary for the master window to be the parent
of the slave window.
This feature is useful in at least two situations.
First, for complex window layouts it means you can create a
hierarchy of subwindows whose only purpose
is to assist in the layout of the parent.
The
.QW "real children"
of the parent (i.e. the windows that
are significant for the application's user interface) can be
children of the parent yet be placed inside the windows
of the geometry-management hierarchy.
This means that the path names of the
.QW "real children"
do not reflect the geometry-management hierarchy and users
can specify options for the real children
without being aware of the structure of the geometry-management
hierarchy.
.PP
A second reason for having a master different than the slave's
parent is to tie two siblings together.
For example, the placer can be used to force a window always to
be positioned centered just below one of its
siblings by specifying the configuration
.CS
\fB\-in \fIsibling\fB \-relx 0.5 \-rely 1.0 \-anchor n \-bordermode outside\fR
.CE
Whenever the sibling is repositioned in the future, the slave
will be repositioned as well.
.PP
Unlike many other geometry managers (such as the packer)
the placer does not make any attempt to manipulate the geometry of
the master windows or the parents of slave windows (i.e. it does not
set their requested sizes).
To control the sizes of these windows, make them windows like
frames and canvases that provide configuration options for this purpose.
.SH EXAMPLE
.PP
Make the label occupy the middle bit of the toplevel, no matter how it
is resized:
.CS
label .l \-text "In the\enMiddle!" \-bg black \-fg white
\fBplace\fR .l \-relwidth .3 \-relx .35 \-relheight .3 \-rely .35
.CE
.SH "SEE ALSO"
grid(n), pack(n)
.SH KEYWORDS
geometry manager, height, location, master, place, rubber sheet, slave, width
'\" Local Variables:
'\" mode: nroff
'\" End:
@


1.12
log
@Minor doc updates (removing out of date changebars, improving typedef formatting,
 etc.)
@
text
@a0 1
'\" -*- nroff -*-
d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.11 2007/12/13 15:23:43 dgp Exp $
d255 3
@


1.11
log
@merge stable branch onto HEAD
@
text
@d1 1
d9 1
a9 1
'\" RCS: @@(#) $Id: place.n,v 1.7.2.1 2007/11/01 16:37:15 dgp Exp $
a19 1

d53 2
a54 1

a55 1
.RS
d78 2
a79 1

d89 1
d245 1
a251 1

a253 1

@


1.10
log
@Lots more GOOBE stuff. Now works with 'make html'!
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.9 2007/10/26 20:13:23 dgp Exp $
@


1.9
log
@        * doc/*.1:              Revert doc changes that broke
        * doc/*.3:              `make html` so we can get the release
        * doc/*.n:              out the door.
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.7 2004/08/20 10:56:36 dkf Exp $
d107 1
a107 1
If this option isn't specified then the master defaults to
d185 1
a185 1
doesn't appear on the screen.  If \fIwindow\fR isn't currently managed
d212 3
a214 1
The ``real children'' of the parent (i.e. the windows that
d218 3
a220 2
This means that the path names of the ``real children''
don't reflect the geometry-management hierarchy and users
d238 1
a238 1
the master windows or the parents of slave windows (i.e. it doesn't
d246 1
a246 1
label .l \-text "In the\\nMiddle!" \-bg black \-fg white
@


1.8
log
@Lots of improvements to look and feel of manual pages
@
text
@d212 1
a212 3
The
.QW "real children"
of the parent (i.e. the windows that
d216 1
a216 2
This means that the path names of the
.QW "real children"
@


1.7
log
@Spelling and grammar fixes from Mikhail Kolesnitchenko. [Patch 1012083]
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.6 2004/07/01 08:06:15 dkf Exp $
d212 3
a214 1
The ``real children'' of the parent (i.e. the windows that
d218 2
a219 1
This means that the path names of the ``real children''
@


1.7.2.1
log
@merge updates from HEAD
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.7 2004/08/20 10:56:36 dkf Exp $
d107 1
a107 1
If this option is not specified then the master defaults to
d185 1
a185 1
does not appear on the screen.  If \fIwindow\fR is not currently managed
d212 1
a212 3
The
.QW "real children"
of the parent (i.e. the windows that
d216 2
a217 3
This means that the path names of the
.QW "real children"
do not reflect the geometry-management hierarchy and users
d235 1
a235 1
the master windows or the parents of slave windows (i.e. it does not
d243 1
a243 1
label .l \-text "In the\enMiddle!" \-bg black \-fg white
@


1.6
log
@Doc fixes. [Tcl Bug 983146]
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.5 2004/06/21 20:42:21 dkf Exp $
d99 1
a99 1
\fIMaster\fR specifes the path name of the window relative
@


1.5
log
@Forgot the example section header label!
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.4 2004/06/21 15:21:24 dkf Exp $
d243 1
a243 1
label .l \-text "In the\nMiddle!" \-bg black \-fg white
@


1.4
log
@Added example
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.3 2000/08/10 00:21:06 ericm Exp $
d239 1
a239 1
.SH
d244 1
a244 1
place .l \-relwidth .3 \-relx .35 \-relheight .3 \-rely .35
@


1.3
log
@* doc/SetOptions.3: Updated documentation to reflect support for
TK_OPTION_NULL_OK for TK_OPTION_DOUBLE and TK_OPTION_PIXELS.

* generic/tkConfig.c: Added for TK_OPTION_NULL_OK support for
TK_OPTION_DOUBLE and TK_OPTION_PIXELS.

* doc/place.n: Updated, reformatted manual entry.

* tests/place.test: Added many tests.

* generic/tkPlace.c (Tk_PlaceObjCmd): Updated to use Tk
widget-option management facilities to manage place options (-x,
-y, etc.), which simplifies the placer code.  Added support for
[place configure pathName] and [place configure pathName -option],
similar to the behavior of the configure subcommand supported by
widgets.
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.2 1998/09/14 18:22:59 stanton Exp $
d17 1
a17 9
\fBplace \fIwindow option value \fR?\fIoption value ...\fR?
.sp
\fBplace configure \fIwindow \fR?\fIoption\fR? ?\fIvalue option value ...\fR?
.sp
\fBplace forget \fIwindow\fR
.sp
\fBplace info \fIwindow\fR
.sp
\fBplace slaves \fIwindow\fR
d198 1
a198 1

a203 1

d239 10
@


1.3.8.1
log
@More backporting of doc fixes
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.3 2000/08/10 00:21:06 ericm Exp $
d17 9
a25 1
\fBplace \fIoption arg \fR?\fIarg ...\fR?
d107 1
a107 1
\fIMaster\fR specifies the path name of the window relative
d206 1
a206 1
.PP
d212 1
a247 10
.SH EXAMPLE
Make the label occupy the middle bit of the toplevel, no matter how it
is resized:
.CS
label .l \-text "In the\\nMiddle!" \-bg black \-fg white
\fBplace\fR .l \-relwidth .3 \-relx .35 \-relheight .3 \-rely .35
.CE

.SH "SEE ALSO"
grid(n), pack(n)
@


1.2
log
@Replaced SCCS strings, fixed binary files
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id$
d19 1
a19 1
\fBplace configure \fIwindow option value \fR?\fIoption value ...\fR?
d42 20
a61 9
If the first argument to the \fBplace\fR command is a window path
name or \fBconfigure\fR then the command arranges for the placer
to manage the geometry of a slave whose path name is \fIwindow\fR.
The remaining arguments consist of one or more \fIoption\-value\fR
pairs that specify the way in which \fIwindow\fR's
geometry is managed.
If the placer is already managing \fIwindow\fR, then the
\fIoption\-value\fR pairs modify the configuration for \fIwindow\fR.
In this form the \fBplace\fR command returns an empty string as result.
d63 42
d118 19
a136 6
\fB\-x \fIlocation\fR
\fILocation\fR specifies the x-coordinate within the master window
of the anchor point for \fIwindow\fR.
The location is specified in screen units (i.e. any of the forms
accepted by \fBTk_GetPixels\fR) and need not lie within the bounds
of the master window.
a149 7
\fB\-y \fIlocation\fR
\fILocation\fR specifies the y-coordinate within the master window
of the anchor point for \fIwindow\fR.
The location is specified in screen units (i.e. any of the forms
accepted by \fBTk_GetPixels\fR) and need not lie within the bounds
of the master window.
.TP
a161 11
\fB\-anchor \fIwhere\fR
\fIWhere\fR specifies which point of \fIwindow\fR is to be positioned
at the (x,y) location selected by the \fB\-x\fR, \fB\-y\fR,
\fB\-relx\fR, and \fB\-rely\fR options.
The anchor point is in terms of the outer area of \fIwindow\fR
including its border, if any.
Thus if \fIwhere\fR is \fBse\fR then the lower-right corner of
\fIwindow\fR's border will appear at the given (x,y) location
in the master.
The anchor position defaults to \fBnw\fR.
.TP
d171 6
a176 9
\fB\-relwidth \fIsize\fR
\fISize\fR specifies the width for \fIwindow\fR.
In this case the width is specified as a floating-point number
relative to the width of the master: 0.5 means \fIwindow\fR will
be half as wide as the master, 1.0 means \fIwindow\fR will have
the same width as the master, and so on.
If both \fB\-width\fR and \fB\-relwidth\fR are specified for a slave,
their values are summed.  For example, \fB\-relwidth 1.0 \-width 5\fR
makes the slave 5 pixels wider than the master.
d178 6
a183 38
\fB\-height \fIsize\fR
\fISize\fR specifies the height for \fIwindow\fR in screen units
(i.e. any of the forms accepted by \fBTk_GetPixels\fR).
The height will be the outer dimension of \fIwindow\fR including its
border, if any.
If \fIsize\fR is an empty string, or if no \fB\-height\fR or
\fB\-relheight\fR option is specified, then the height requested
internally by the window will be used.
.TP
\fB\-relheight \fIsize\fR
\fISize\fR specifies the height for \fIwindow\fR.
In this case the height is specified as a floating-point number
relative to the height of the master: 0.5 means \fIwindow\fR will
be half as high as the master, 1.0 means \fIwindow\fR will have
the same height as the master, and so on.
If both \fB\-height\fR and \fB\-relheight\fR are specified for a slave,
their values are summed.  For example, \fB\-relheight 1.0 \-height \-2\fR
makes the slave 2 pixels shorter than the master.
.TP
\fB\-bordermode \fImode\fR
\fIMode\fR determines the degree to which borders within the
master are used in determining the placement of the slave.
The default and most common value is \fBinside\fR.
In this case the placer considers the area of the master to
be the innermost area of the master, inside any border:
an option of \fB\-x 0\fR corresponds to an x-coordinate just
inside the border and an option of \fB\-relwidth 1.0\fR
means \fIwindow\fR will fill the area inside the master's
border.
If \fImode\fR is \fBoutside\fR then the placer considers
the area of the master to include its border;
this mode is typically used when placing \fIwindow\fR
outside its master, as with the options \fB\-x 0 \-y 0 \-anchor ne\fR.
Lastly, \fImode\fR may be specified as \fBignore\fR, in which
case borders are ignored:  the area of the master is considered
to be its official X area, which includes any internal border but
no external border.  A bordermode of \fBignore\fR is probably
not very useful.
d188 11
a198 16
.PP
The \fBplace slaves\fR command returns a list of all the slave
windows for which \fIwindow\fR is the master.
If there are no slaves for \fIwindow\fR then an empty string is
returned.
.PP
The \fBplace forget\fR command causes the placer to stop managing
the geometry of \fIwindow\fR.  As a side effect of this command
\fIwindow\fR will be unmapped so that it doesn't appear on the
screen.
If \fIwindow\fR isn't currently managed by the placer then the
command has no effect.
\fBPlace forget\fR returns an empty string as result.
.PP
The \fBplace info\fR command returns a list giving the current
configuration of \fIwindow\fR.
d202 5
@


1.1
log
@Initial revision
@
text
@d8 1
a8 1
'\" SCCS: @@(#) place.n 1.13 96/08/27 13:21:49
@


1.1.4.1
log
@Merged 8.0.3 changes into 8.1
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: place.n,v 1.2 1998/09/14 18:22:59 stanton Exp $
@


