Initial commit of OpenSPARC T2 design and verification files.
[OpenSPARC-T2-DV] / tools / perl-5.8.0 / lib / site_perl / 5.8.0 / sun4-solaris / Tk / place.pod
CommitLineData
86530b38
AT
1# Copyright (c) 1992 The Regents of the University of California.
2# Copyright (c) 1994-1996 Sun Microsystems, Inc.
3# See the file "license.terms" for information on usage and redistribution
4# of this file, and for a DISCLAIMER OF ALL WARRANTIES.
5#
6#
7
8=head1 NAME
9
10Tk::place - Geometry manager for fixed or rubber-sheet placement
11
12=for category Tk Geometry Management
13
14=head1 SYNOPSIS
15
16S< >I<$widget>->B<place>?(I<-option>=>I<value>?, I<-option>=>I<value>, ...)?
17
18S< >I<$widget>->B<placeForget>
19
20S< >I<$widget>->B<placeInfo>
21
22S< >I<$master>->B<placeSlaves>
23
24=head1 DESCRIPTION
25
26The placer is a geometry manager for Tk.
27It provides simple fixed placement of windows, where you specify
28the exact size and location of one window, called the I<slave>,
29within another window, called the I<$master>.
30The placer also provides rubber-sheet placement, where you specify the
31size and location of the slave in terms of the dimensions of
32the master, so that the slave changes size and location
33in response to changes in the size of the master.
34Lastly, the placer allows you to mix these styles of placement so
35that, for example, the slave has a fixed width and height but is
36centered inside the master.
37
38=over 4
39
40=item I<$slave>->B<place>?(I<-option>=>I<value>?, I<-option>=>I<value>, ...?)?
41
42The B<place> method arranges for the placer
43to manage the geometry of I<$slave>.
44The remaining arguments consist of one or more I<-option>=>I<value>
45pairs that specify the way in which I<$slave>'s
46geometry is managed.
47If the placer is already managing I<$slave>, then the
48I<-option>=>I<value> pairs modify the configuration for I<$slave>.
49The B<place> method returns an empty string as result.
50The following I<-option>=>I<value> pairs are supported:
51
52=over 8
53
54=item B<-in> => I<$master>
55
56I<$master> is the reference to the window relative
57to which I<$slave> is to be placed.
58I<$master> must either be I<$slave>'s parent or a descendant
59of I<$slave>'s parent.
60In addition, I<$master> and I<$slave> must both be descendants
61of the same top-level window.
62These restrictions are necessary to guarantee
63that I<$slave> is visible whenever I<$master> is visible.
64If this option isn't specified then the master defaults to
65I<$slave>'s parent.
66
67=item B<-x> => I<location>
68
69I<Location> specifies the x-coordinate within the master window
70of the anchor point for I<$slave> widget.
71The location is specified in screen units (i.e. any of the forms
72accepted by B<Tk_GetPixels>) and need not lie within the bounds
73of the master window.
74
75=item B<-relx> => I<location>
76
77I<Location> specifies the x-coordinate within the master window
78of the anchor point for I<$slave> widget.
79In this case the location is specified in a relative fashion
80as a floating-point number: 0.0 corresponds to the left edge
81of the master and 1.0 corresponds to the right edge of the master.
82I<Location> need not be in the range 0.0-1.0.
83If both B<-x> and B<-relx> are specified for a slave
84then their values are summed. For example, "B<-relx>=>0.5, B<-x>=-2"
85positions the left edge of the slave 2 pixels to the left of the
86center of its master.
87
88=item B<-y> => I<location>
89
90I<Location> specifies the y-coordinate within the master window
91of the anchor point for I<$slave> widget.
92The location is specified in screen units (i.e. any of the forms
93accepted by B<Tk_GetPixels>) and need not lie within the bounds
94of the master window.
95
96=item B<-rely> => I<location>
97
98I<Location> specifies the y-coordinate within the master window
99of the anchor point for I<$slave> widget.
100In this case the value is specified in a relative fashion
101as a floating-point number: 0.0 corresponds to the top edge
102of the master and 1.0 corresponds to the bottom edge of the master.
103I<Location> need not be in the range 0.0-1.0.
104If both B<-y> and B<-rely> are specified for a slave
105then their values are summed. For example, B<-rely>=>0.5, B<-x>=>3
106positions the top edge of the slave 3 pixels below the
107center of its master.
108
109=item B<-anchor> => I<where>
110
111I<Where> specifies which point of I<$slave> is to be positioned
112at the (x,y) location selected by the B<-x>, B<-y>,
113B<-relx>, and B<-rely> options.
114The anchor point is in terms of the outer area of I<$slave>
115including its border, if any.
116Thus if I<where> is B<se> then the lower-right corner of
117I<$slave>'s border will appear at the given (x,y) location
118in the master.
119The anchor position defaults to B<nw>.
120
121=item B<-width> => I<size>
122
123I<Size> specifies the width for I<$slave> in screen units
124(i.e. any of the forms accepted by B<Tk_GetPixels>).
125The width will be the outer width of I<$slave> including its
126border, if any.
127If I<size> is an empty string, or if no B<-width>
128or B<-relwidth> option is specified, then the width requested
129internally by the window will be used.
130
131=item B<-relwidth> => I<size>
132
133I<Size> specifies the width for I<$slave>.
134In this case the width is specified as a floating-point number
135relative to the width of the master: 0.5 means I<$slave> will
136be half as wide as the master, 1.0 means I<$slave> will have
137the same width as the master, and so on.
138If both B<-width> and B<-relwidth> are specified for a slave,
139their values are summed. For example, B<-relwidth>=>1.0, B<-width>=>5
140makes the slave 5 pixels wider than the master.
141
142=item B<-height> => I<size>
143
144I<Size> specifies the height for I<$slave> in screen units
145(i.e. any of the forms accepted by B<Tk_GetPixels>).
146The height will be the outer dimension of I<$slave> including its
147border, if any.
148If I<size> is an empty string, or if no B<-height> or
149B<-relheight> option is specified, then the height requested
150internally by the window will be used.
151
152=item B<-relheight> => I<size>
153
154I<Size> specifies the height for I<$slave>.
155In this case the height is specified as a floating-point number
156relative to the height of the master: 0.5 means I<$slave> will
157be half as high as the master, 1.0 means I<$slave> will have
158the same height as the master, and so on.
159If both B<-height> and B<-relheight> are specified for a slave,
160their values are summed. For example, B<-relheight>=>1.0, B<-height>=>-2
161makes the slave 2 pixels shorter than the master.
162
163=item B<-bordermode> => I<mode>
164
165I<Mode> determines the degree to which borders within the
166master are used in determining the placement of the slave.
167The default and most common value is B<inside>.
168In this case the placer considers the area of the master to
169be the innermost area of the master, inside any border:
170an option of B<-x>=>B<0> corresponds to an x-coordinate just
171inside the border and an option of B<-relwidth>=>1.0
172means I<$slave> will fill the area inside the master's
173border.
174If I<mode> is B<outside> then the placer considers
175the area of the master to include its border;
176this mode is typically used when placing I<$slave>
177outside its master, as with the options
178B<-x>=>B<0>, B<-y>=>B<0>, B<-anchor>=>B<ne>.
179Lastly, I<mode> may be specified as B<ignore>, in which
180case borders are ignored: the area of the master is considered
181to be its official X area, which includes any internal border but
182no external border. A bordermode of B<ignore> is probably
183not very useful.
184
185If the same value is specified separately with
186two different options, such as B<-x> and B<-relx>, then
187the most recent option is used and the older one is ignored.
188
189=back
190
191=item I<$slave>->B<placeSlaves>
192
193The B<placeSlaves> method returns a list of all the slave
194windows for which I<$master> is the master.
195If there are no slaves for I<$master> then an empty list is
196returned.
197
198=item I<$slave>->B<placeForget>
199
200The B<placeForget> method causes the placer to stop managing
201the geometry of I<$slave>. As a side effect of this method call
202I<$slave> will be unmapped so that it doesn't appear on the
203screen.
204If I<$slave> isn't currently managed by the placer then the
205method call has no effect.
206B<placeForget> returns an empty string as result.
207
208=item I<$slave>->B<placeInfo>
209
210The B<placeInfo> method returns a list giving the current
211configuration of I<$slave>.
212The list consists of I<-option>=>I<value> pairs in exactly the
213same form as might be specified to the B<place>
214method.
215If the configuration of a window has been retrieved with
216B<placeInfo>, that configuration can be restored later by
217first using B<placeForget> to erase any existing information
218for the window and then invoking B<place> with
219the saved information.
220
221=back
222
223=head1 FINE POINTS
224
225It is not necessary for the master window to be the parent
226of the slave window.
227This feature is useful in at least two situations.
228First, for complex window layouts it means you can create a
229hierarchy of subwindows whose only purpose
230is to assist in the layout of the parent.
231The ``I<real children>'' of the parent (i.e. the windows that
232are significant for the application's user interface) can be
233children of the parent yet be placed inside the windows
234of the geometry-management hierarchy.
235This means that the path names of the ``I<real children>''
236don't reflect the geometry-management hierarchy and users
237can specify options for the real children
238without being aware of the structure of the geometry-management
239hierarchy.
240
241A second reason for having a master different than the slave's
242parent is to tie two siblings together.
243For example, the placer can be used to force a window always to
244be positioned centered just below one of its
245siblings by specifying the configuration
246
247S< >B<-in>=>I<$sibling>, B<-relx>=>0.5, B<-rely>=>1.0,
248B<-anchor>=>'n', B<-bordermode>=>'outside'
249
250Whenever the I<$sibling> widget is repositioned in the future, the slave
251will be repositioned as well.
252
253Unlike many other geometry managers (such as the packer)
254the placer does not make any attempt to manipulate the geometry of
255the master windows or the parents of slave windows (i.e. it doesn't
256set their requested sizes).
257To control the sizes of these windows, make them windows like
258frames and canvases that provide configuration options for this purpose.
259
260=head1 SEE ALSO
261
262L<Tk::form|Tk::form>
263L<Tk::grid|Tk::grid>
264L<Tk::pack|Tk::pack>
265
266=head1 KEYWORDS
267
268geometry manager, height, location, master, place, rubber sheet, slave, width
269
270=cut
271