| 1 | .\" Automatically generated by Pod::Man v1.34, Pod::Parser v1.13 |
| 2 | .\" |
| 3 | .\" Standard preamble: |
| 4 | .\" ======================================================================== |
| 5 | .de Sh \" Subsection heading |
| 6 | .br |
| 7 | .if t .Sp |
| 8 | .ne 5 |
| 9 | .PP |
| 10 | \fB\\$1\fR |
| 11 | .PP |
| 12 | .. |
| 13 | .de Sp \" Vertical space (when we can't use .PP) |
| 14 | .if t .sp .5v |
| 15 | .if n .sp |
| 16 | .. |
| 17 | .de Vb \" Begin verbatim text |
| 18 | .ft CW |
| 19 | .nf |
| 20 | .ne \\$1 |
| 21 | .. |
| 22 | .de Ve \" End verbatim text |
| 23 | .ft R |
| 24 | .fi |
| 25 | .. |
| 26 | .\" Set up some character translations and predefined strings. \*(-- will |
| 27 | .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left |
| 28 | .\" double quote, and \*(R" will give a right double quote. | will give a |
| 29 | .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to |
| 30 | .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' |
| 31 | .\" expand to `' in nroff, nothing in troff, for use with C<>. |
| 32 | .tr \(*W-|\(bv\*(Tr |
| 33 | .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' |
| 34 | .ie n \{\ |
| 35 | . ds -- \(*W- |
| 36 | . ds PI pi |
| 37 | . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch |
| 38 | . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch |
| 39 | . ds L" "" |
| 40 | . ds R" "" |
| 41 | . ds C` "" |
| 42 | . ds C' "" |
| 43 | 'br\} |
| 44 | .el\{\ |
| 45 | . ds -- \|\(em\| |
| 46 | . ds PI \(*p |
| 47 | . ds L" `` |
| 48 | . ds R" '' |
| 49 | 'br\} |
| 50 | .\" |
| 51 | .\" If the F register is turned on, we'll generate index entries on stderr for |
| 52 | .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index |
| 53 | .\" entries marked with X<> in POD. Of course, you'll have to process the |
| 54 | .\" output yourself in some meaningful fashion. |
| 55 | .if \nF \{\ |
| 56 | . de IX |
| 57 | . tm Index:\\$1\t\\n%\t"\\$2" |
| 58 | .. |
| 59 | . nr % 0 |
| 60 | . rr F |
| 61 | .\} |
| 62 | .\" |
| 63 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes |
| 64 | .\" way too many mistakes in technical documents. |
| 65 | .hy 0 |
| 66 | .if n .na |
| 67 | .\" |
| 68 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). |
| 69 | .\" Fear. Run. Save yourself. No user-serviceable parts. |
| 70 | . \" fudge factors for nroff and troff |
| 71 | .if n \{\ |
| 72 | . ds #H 0 |
| 73 | . ds #V .8m |
| 74 | . ds #F .3m |
| 75 | . ds #[ \f1 |
| 76 | . ds #] \fP |
| 77 | .\} |
| 78 | .if t \{\ |
| 79 | . ds #H ((1u-(\\\\n(.fu%2u))*.13m) |
| 80 | . ds #V .6m |
| 81 | . ds #F 0 |
| 82 | . ds #[ \& |
| 83 | . ds #] \& |
| 84 | .\} |
| 85 | . \" simple accents for nroff and troff |
| 86 | .if n \{\ |
| 87 | . ds ' \& |
| 88 | . ds ` \& |
| 89 | . ds ^ \& |
| 90 | . ds , \& |
| 91 | . ds ~ ~ |
| 92 | . ds / |
| 93 | .\} |
| 94 | .if t \{\ |
| 95 | . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" |
| 96 | . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' |
| 97 | . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' |
| 98 | . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' |
| 99 | . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' |
| 100 | . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' |
| 101 | .\} |
| 102 | . \" troff and (daisy-wheel) nroff accents |
| 103 | .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' |
| 104 | .ds 8 \h'\*(#H'\(*b\h'-\*(#H' |
| 105 | .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] |
| 106 | .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' |
| 107 | .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' |
| 108 | .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] |
| 109 | .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] |
| 110 | .ds ae a\h'-(\w'a'u*4/10)'e |
| 111 | .ds Ae A\h'-(\w'A'u*4/10)'E |
| 112 | . \" corrections for vroff |
| 113 | .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' |
| 114 | .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' |
| 115 | . \" for low resolution devices (crt and lpr) |
| 116 | .if \n(.H>23 .if \n(.V>19 \ |
| 117 | \{\ |
| 118 | . ds : e |
| 119 | . ds 8 ss |
| 120 | . ds o a |
| 121 | . ds d- d\h'-1'\(ga |
| 122 | . ds D- D\h'-1'\(hy |
| 123 | . ds th \o'bp' |
| 124 | . ds Th \o'LP' |
| 125 | . ds ae ae |
| 126 | . ds Ae AE |
| 127 | .\} |
| 128 | .rm #[ #] #H #V #F C |
| 129 | .\" ======================================================================== |
| 130 | .\" |
| 131 | .IX Title "WM 1" |
| 132 | .TH WM 1 "2000-12-30" "perl v5.8.0" "User Contributed Perl Documentation" |
| 133 | .SH "NAME" |
| 134 | Tk::Wm \- Communicate with window manager |
| 135 | .SH "SYNOPSIS" |
| 136 | .IX Header "SYNOPSIS" |
| 137 | \&\ \fI$toplevel\fR\->\fImethod\fR(?\fIargs\fR?) |
| 138 | .SH "DESCRIPTION" |
| 139 | .IX Header "DESCRIPTION" |
| 140 | The \fBwm\fR methods are used to interact with window managers in |
| 141 | order to control such things as the title for a window, its geometry, |
| 142 | or the increments in terms of which it may be resized. |
| 143 | The \fBwm\fR methods can take any of a number of different forms, depending on |
| 144 | the particular \fImethod\fR argument. |
| 145 | All of the forms expect \fI$toplevel\fR, which must be a |
| 146 | top-level window object. |
| 147 | .PP |
| 148 | The legal forms for the \fBwm\fR methods are: |
| 149 | .IP "\fI$toplevel\fR\->\fBaspect\fR(?\fIminNumer minDenom maxNumer maxDenom\fR?)" 4 |
| 150 | .IX Item "$toplevel->aspect(?minNumer minDenom maxNumer maxDenom?)" |
| 151 | If \fIminNumer\fR, \fIminDenom\fR, \fImaxNumer\fR, and \fImaxDenom\fR |
| 152 | are all specified, then they will be passed to the window manager |
| 153 | and the window manager should use them to enforce a range of |
| 154 | acceptable aspect ratios for \fI$toplevel\fR. The aspect ratio of |
| 155 | \&\fI$toplevel\fR (width/length) will be constrained to lie |
| 156 | between \fIminNumer\fR/\fIminDenom\fR and \fImaxNumer\fR/\fImaxDenom\fR. |
| 157 | If \fIminNumer\fR etc. are all specified as empty strings, then |
| 158 | any existing aspect ratio restrictions are removed. |
| 159 | If \fIminNumer\fR etc. are specified, then the method returns an |
| 160 | empty string. Otherwise, it returns |
| 161 | a array containing four elements, which are the current values |
| 162 | of \fIminNumer\fR, \fIminDenom\fR, \fImaxNumer\fR, and \fImaxDenom\fR |
| 163 | (if no aspect restrictions are in effect, then an empty string is |
| 164 | returned). |
| 165 | .IP "\fI$toplevel\fR\->\fBclient\fR(?\fIname\fR?)" 4 |
| 166 | .IX Item "$toplevel->client(?name?)" |
| 167 | If \fIname\fR is specified, this method stores \fIname\fR (which |
| 168 | should be the name of |
| 169 | the host on which the application is executing) in \fI$toplevel\fR's |
| 170 | \&\fB\s-1WM_CLIENT_MACHINE\s0\fR property for use by the window manager or |
| 171 | session manager. |
| 172 | The method returns an empty string in this case. |
| 173 | If \fIname\fR isn't specified, the method returns the last name |
| 174 | set in a \fBclient\fR method for \fI$toplevel\fR. |
| 175 | If \fIname\fR is specified as an empty string, the method deletes the |
| 176 | \&\fB\s-1WM_CLIENT_MACHINE\s0\fR property from \fI$toplevel\fR. |
| 177 | .IP "\fI$toplevel\fR\->\fBcolormapwindows\fR(?\fIwindowList\fR?)" 4 |
| 178 | .IX Item "$toplevel->colormapwindows(?windowList?)" |
| 179 | This method is used to manipulate the \fB\s-1WM_COLORMAP_WINDOWS\s0\fR |
| 180 | property, which provides information to the window managers about |
| 181 | windows that have private colormaps. |
| 182 | If \fIwindowList\fR isn't specified, the method returns a list |
| 183 | whose elements are the names of the windows in the \fB\s-1WM_COLORMAP_WINDOWS\s0\fR |
| 184 | property. |
| 185 | If \fIwindowList\fR is specified, it consists of a list of widgets; |
| 186 | the method overwrites the \fB\s-1WM_COLORMAP_WINDOWS\s0\fR |
| 187 | property with the given windows and returns an empty string. |
| 188 | The \fB\s-1WM_COLORMAP_WINDOWS\s0\fR property should normally contain a |
| 189 | list of the internal windows within \fI$toplevel\fR whose colormaps differ |
| 190 | from their parents. |
| 191 | The order of the windows in the property indicates a priority order: |
| 192 | the window manager will attempt to install as many colormaps as possible |
| 193 | from the head of this list when \fI$widget\fR gets the colormap focus. |
| 194 | If \fI$widget\fR is not included among the windows in \fIwindowList\fR, |
| 195 | Tk implicitly adds it at the end of the \fB\s-1WM_COLORMAP_WINDOWS\s0\fR |
| 196 | property, so that its colormap is lowest in priority. |
| 197 | If \fI$widget\fR\->colormapwindows is not invoked, Tk will automatically set |
| 198 | the property for each top-level window to all the internal windows |
| 199 | whose colormaps differ from their parents, followed by the top-level |
| 200 | itself; the order of the internal windows is undefined. |
| 201 | See the \s-1ICCCM\s0 documentation for more information on the |
| 202 | \&\fB\s-1WM_COLORMAP_WINDOWS\s0\fR property. |
| 203 | .IP "\fI$toplevel\fR\->\fBcommand\fR(?\fIvalue\fR?)" 4 |
| 204 | .IX Item "$toplevel->command(?value?)" |
| 205 | If \fIvalue\fR is specified, this method stores \fIvalue\fR in \fI$toplevel\fR's |
| 206 | \&\fB\s-1WM_COMMAND\s0\fR property for use by the window manager or |
| 207 | session manager and returns an empty string. |
| 208 | \&\fIValue\fR must have proper list structure; the elements should |
| 209 | contain the words of the command used to invoke the application. |
| 210 | If \fIvalue\fR isn't specified then the method returns the last value |
| 211 | set in a \fBcommand\fR method for \fI$toplevel\fR. |
| 212 | If \fIvalue\fR is specified as an empty string, the method |
| 213 | deletes the \fB\s-1WM_COMMAND\s0\fR property from \fI$toplevel\fR. |
| 214 | .IP "\fI$toplevel\fR\->\fBdeiconify\fR" 4 |
| 215 | .IX Item "$toplevel->deiconify" |
| 216 | Arrange for \fI$toplevel\fR to be displayed in normal (non\-iconified) form. |
| 217 | This is done by mapping the window. If the window has never been |
| 218 | mapped then this method will not map the window, but it will ensure |
| 219 | that when the window is first mapped it will be displayed |
| 220 | in de-iconified form. Returns an empty string. |
| 221 | .IP "\fI$toplevel\fR\->\fBfocusmodel\fR(?\fBactive\fR|\fBpassive\fR?)" 4 |
| 222 | .IX Item "$toplevel->focusmodel(?active|passive?)" |
| 223 | If \fBactive\fR or \fBpassive\fR is supplied as an optional argument |
| 224 | to the method, then it specifies the focus model for \fI$toplevel\fR. |
| 225 | In this case the method returns an empty string. If no additional |
| 226 | argument is supplied, then the method returns the current focus |
| 227 | model for \fI$toplevel\fR. |
| 228 | An \fBactive\fR focus model means that \fI$toplevel\fR will claim the |
| 229 | input focus for itself or its descendants, even at times when |
| 230 | the focus is currently in some other application. \fBPassive\fR means that |
| 231 | \&\fI$toplevel\fR will never claim the focus for itself: the window manager |
| 232 | should give the focus to \fI$toplevel\fR at appropriate times. However, |
| 233 | once the focus has been given to \fI$toplevel\fR or one of its descendants, |
| 234 | the application may re-assign the focus among \fI$toplevel\fR's descendants. |
| 235 | The focus model defaults to \fBpassive\fR, and Tk's \fBfocus\fR method |
| 236 | assumes a passive model of focusing. |
| 237 | .IP "\fI$toplevel\fR\->\fBframe\fR" 4 |
| 238 | .IX Item "$toplevel->frame" |
| 239 | If \fI$widget\fR has been reparented by the window manager into a |
| 240 | decorative frame, the method returns the platform specific window |
| 241 | identifier for the outermost frame that contains \fI$toplevel\fR (the |
| 242 | window whose parent is the root or virtual root). If \fI$toplevel\fR |
| 243 | hasn't been reparented by the window manager then the method returns |
| 244 | the platform specific window identifier for \fI$toplevel\fR. |
| 245 | .IP "\fI$toplevel\fR\->\fBgeometry\fR(?\fInewGeometry\fR?)" 4 |
| 246 | .IX Item "$toplevel->geometry(?newGeometry?)" |
| 247 | If \fInewGeometry\fR is specified, then the geometry of \fI$toplevel\fR |
| 248 | is changed and an empty string is returned. Otherwise the current |
| 249 | geometry for \fI$toplevel\fR is returned (this is the most recent |
| 250 | geometry specified either by manual resizing or |
| 251 | in a \fBgeometry\fR method). \fINewGeometry\fR has |
| 252 | the form \fB=\fR\fIwidth\fR\fBx\fR\fIheight\fR\fB+\-\fR\fIx\fR\fB+\-\fR\fIy\fR, where |
| 253 | any of \fB=\fR, \fIwidth\fR\fBx\fR\fIheight\fR, or \fB+\-\fR\fIx\fR\fB+\-\fR\fIy\fR |
| 254 | may be omitted. \fIWidth\fR and \fIheight\fR are positive integers |
| 255 | specifying the desired dimensions of \fI$toplevel\fR. If \fI$toplevel\fR |
| 256 | is gridded (see \*(L"\s-1GRIDDED\s0 \s-1GEOMETRY\s0 \s-1MANAGEMENT\s0\*(R" below) then the dimensions |
| 257 | are specified in grid units; otherwise they are specified in pixel |
| 258 | units. \fIX\fR and \fIy\fR specify the desired location of |
| 259 | \&\fI$toplevel\fR on the screen, in pixels. |
| 260 | If \fIx\fR is preceded by \fB+\fR, it specifies |
| 261 | the number of pixels between the left edge of the screen and the left |
| 262 | edge of \fI$toplevel\fR's border; if preceded by \fB\-\fR then |
| 263 | \&\fIx\fR specifies the number of pixels |
| 264 | between the right edge of the screen and the right edge of \fI$toplevel\fR's |
| 265 | border. If \fIy\fR is preceded by \fB+\fR then it specifies the |
| 266 | number of pixels between the top of the screen and the top |
| 267 | of \fI$toplevel\fR's border; if \fIy\fR is preceded by \fB\-\fR then |
| 268 | it specifies the number of pixels between the bottom of \fI$toplevel\fR's |
| 269 | border and the bottom of the screen. |
| 270 | If \fInewGeometry\fR is specified as an empty string then any |
| 271 | existing user-specified geometry for \fI$toplevel\fR is cancelled, and |
| 272 | the window will revert to the size requested internally by its |
| 273 | widgets. |
| 274 | .IP "\fI$toplevel\fR\->\fBwmGrid\fR(?\fIbaseWidth,baseHeight,widthInc,heightInc\fR?)" 4 |
| 275 | .IX Item "$toplevel->wmGrid(?baseWidth,baseHeight,widthInc,heightInc?)" |
| 276 | This method indicates that \fI$toplevel\fR is to be managed as a |
| 277 | gridded window. |
| 278 | It also specifies the relationship between grid units and pixel units. |
| 279 | \&\fIBaseWidth\fR and \fIbaseHeight\fR specify the number of grid |
| 280 | units corresponding to the pixel dimensions requested internally |
| 281 | by \fI$toplevel\fR using \fBTk_GeometryRequest\fR. \fIWidthInc\fR |
| 282 | and \fIheightInc\fR specify the number of pixels in each horizontal |
| 283 | and vertical grid unit. |
| 284 | These four values determine a range of acceptable sizes for |
| 285 | \&\fI$toplevel\fR, corresponding to grid-based widths and heights |
| 286 | that are non-negative integers. |
| 287 | Tk will pass this information to the window manager; during |
| 288 | manual resizing, the window manager will restrict the window's size |
| 289 | to one of these acceptable sizes. |
| 290 | Furthermore, during manual resizing the window manager will display |
| 291 | the window's current size in terms of grid units rather than pixels. |
| 292 | If \fIbaseWidth\fR etc. are all specified as empty strings, then |
| 293 | \&\fI$toplevel\fR will no longer be managed as a gridded window. If |
| 294 | \&\fIbaseWidth\fR etc. are specified then the return value is an |
| 295 | empty string. |
| 296 | Otherwise the return value is a array containing |
| 297 | four elements corresponding to the current \fIbaseWidth\fR, |
| 298 | \&\fIbaseHeight\fR, \fIwidthInc\fR, and \fIheightInc\fR; if |
| 299 | \&\fI$toplevel\fR is not currently gridded, then an empty string |
| 300 | is returned. |
| 301 | Note: this command should not be needed very often, since the |
| 302 | \&\fBTk_SetGrid\fR library procedure and the \fB\-setgrid\fR option |
| 303 | provide easier access to the same functionality. |
| 304 | .IP "\fI$toplevel\fR\->\fBgroup\fR(?\fI$widget\fR?)" 4 |
| 305 | .IX Item "$toplevel->group(?$widget?)" |
| 306 | If \fI$widget\fR is specified, it is the the leader of |
| 307 | a group of related windows. The window manager may use this information, |
| 308 | for example, to unmap all of the windows in a group when the group's |
| 309 | leader is iconified. \fI$widget\fR may be specified as an empty string to |
| 310 | remove \fI$toplevel\fR from any group association. If \fI$widget\fR is |
| 311 | specified then the method returns an empty string; otherwise it |
| 312 | returns the \fI$toplevel\fR's current group leader, or an empty |
| 313 | string if \fI$toplevel\fR isn't part of any group. |
| 314 | .IP "\fI$toplevel\fR\->\fBiconbitmap\fR(?\fIbitmap\fR?)" 4 |
| 315 | .IX Item "$toplevel->iconbitmap(?bitmap?)" |
| 316 | If \fIbitmap\fR is specified, then it names a bitmap in the standard |
| 317 | forms accepted by Tk (see the \fBTk_GetBitmap\fR documentation for details). |
| 318 | This \fIblack and white\fR bitmap is passed to the window manager to be displayed |
| 319 | in \fI$toplevel\fR's icon, and the method returns an empty string. If |
| 320 | an empty string is specified for \fIbitmap\fR, then any current icon |
| 321 | bitmap or image is cancelled for \fI$toplevel\fR. |
| 322 | If \fIbitmap\fR is specified then the method returns an empty string. |
| 323 | Otherwise it returns the name of |
| 324 | the current icon bitmap associated with \fI$toplevel\fR, or an empty |
| 325 | string if \fI$toplevel\fR has no icon bitmap. |
| 326 | .IP "\fI$toplevel\fR\->\fBiconify\fR" 4 |
| 327 | .IX Item "$toplevel->iconify" |
| 328 | Arrange for \fI$toplevel\fR to be iconified. It \fI$toplevel\fR hasn't |
| 329 | yet been mapped for the first time, this method will arrange for |
| 330 | it to appear in the iconified state when it is eventually mapped. |
| 331 | .IP "\fI$toplevel\fR\->\fBiconimage\fR(?\fIimage\fR?)" 4 |
| 332 | .IX Item "$toplevel->iconimage(?image?)" |
| 333 | If \fIimage\fR is specified, then it names a normal Tk image. |
| 334 | This image is rendered into a private \fIcoloured\fR bitmap which is passed to |
| 335 | the window manager to be displayed in \fI$toplevel\fR's icon, and the method returns |
| 336 | an empty string. If an empty string is specified for \fIimage\fR, then any current |
| 337 | icon bitmap or image is cancelled for \fI$toplevel\fR. |
| 338 | If \fIimage\fR is specified then the method returns an empty string. |
| 339 | Otherwise it returns the name of |
| 340 | the current icon image associated with \fI$toplevel\fR, or an empty |
| 341 | string if \fI$toplevel\fR has no icon image. |
| 342 | The private pixmap is not pre-cleared so images which are partly \*(L"transparent\*(R" |
| 343 | display rubbish in their transparent parts. |
| 344 | .Sp |
| 345 | The sizes of images that can be used as icons in this manner are platform |
| 346 | dependant. On Win32 this sets the \*(L"large\*(R" icon, which should be 32x32, it |
| 347 | will automatically be scaled down to 16x16 for use as a small icon. |
| 348 | .IP "\fI$toplevel\fR\->\fBiconmask\fR(?\fIbitmap\fR?)" 4 |
| 349 | .IX Item "$toplevel->iconmask(?bitmap?)" |
| 350 | If \fIbitmap\fR is specified, then it names a bitmap in the standard |
| 351 | forms accepted by Tk (see the \fBTk_GetBitmap\fR documentation for details). |
| 352 | This bitmap is passed to the window manager to be used as a mask |
| 353 | in conjunction with the \fBiconbitmap\fR option: where the mask |
| 354 | has zeroes no icon will be displayed; where it has ones, the bits |
| 355 | from the icon bitmap will be displayed. If |
| 356 | an empty string is specified for \fIbitmap\fR then any current icon |
| 357 | mask is cancelled for \fI$toplevel\fR (this is equivalent to specifying |
| 358 | a bitmap of all ones). If \fIbitmap\fR is specified |
| 359 | then the method returns an empty string. Otherwise it |
| 360 | returns the name of the current icon mask associated with |
| 361 | \&\fI$toplevel\fR, or an empty string if no mask is in effect. |
| 362 | .IP "\fI$toplevel\fR\->\fBiconname\fR(?\fInewName\fR?)" 4 |
| 363 | .IX Item "$toplevel->iconname(?newName?)" |
| 364 | If \fInewName\fR is specified, then it is passed to the window |
| 365 | manager; the window manager should display \fInewName\fR inside |
| 366 | the icon associated with \fI$toplevel\fR. In this case an empty |
| 367 | string is returned as result. If \fInewName\fR isn't specified |
| 368 | then the method returns the current icon name for \fI$toplevel\fR, |
| 369 | or an empty string if no icon name has been specified (in this |
| 370 | case the window manager will normally display the window's title, |
| 371 | as specified with the \fBtitle\fR method). |
| 372 | .IP "\fI$toplevel\fR\->\fBiconposition\fR(?\fIx y\fR?)" 4 |
| 373 | .IX Item "$toplevel->iconposition(?x y?)" |
| 374 | If \fIx\fR and \fIy\fR are specified, they are passed to the window |
| 375 | manager as a hint about where to position the icon for \fI$toplevel\fR. |
| 376 | In this case an empty string is returned. If \fIx\fR and \fIy\fR are |
| 377 | specified as empty strings then any existing icon position hint is cancelled. |
| 378 | If neither \fIx\fR nor \fIy\fR is specified, then the method returns |
| 379 | a array containing two values, which are the current icon position |
| 380 | hints (if no hints are in effect then an empty string is returned). |
| 381 | .IP "\fI$toplevel\fR\->\fBiconwindow\fR(?\fI$widget\fR?)" 4 |
| 382 | .IX Item "$toplevel->iconwindow(?$widget?)" |
| 383 | If \fI$widget\fR is specified, it is a window to |
| 384 | use as icon for \fI$toplevel\fR: when \fI$toplevel\fR is iconified then |
| 385 | \&\fI$widget\fR will be mapped to serve as icon, and when \fI$toplevel\fR |
| 386 | is de-iconified then \fI$widget\fR will be unmapped again. If |
| 387 | \&\fI$widget\fR is specified as an empty string then any existing |
| 388 | icon window association for \fI$toplevel\fR will be cancelled. If |
| 389 | the \fI$widget\fR argument is specified then an empty string is |
| 390 | returned. Otherwise the method returns the |
| 391 | current icon window for \fI$toplevel\fR, or an empty string if there |
| 392 | is no icon window currently specified for \fI$toplevel\fR. |
| 393 | Button press events are disabled for \fI$toplevel\fR as long as it is |
| 394 | an icon window; this is needed in order to allow window managers |
| 395 | to ``own'' those events. |
| 396 | Note: not all window managers support the notion of an icon window. |
| 397 | .IP "\fI$toplevel\fR\->\fBmaxsize\fR(?\fIwidth,height\fR?)" 4 |
| 398 | .IX Item "$toplevel->maxsize(?width,height?)" |
| 399 | If \fIwidth\fR and \fIheight\fR are specified, they give |
| 400 | the maximum permissible dimensions for \fI$toplevel\fR. |
| 401 | For gridded windows the dimensions are specified in |
| 402 | grid units; otherwise they are specified in pixel units. |
| 403 | The window manager will restrict the window's dimensions to be |
| 404 | less than or equal to \fIwidth\fR and \fIheight\fR. |
| 405 | If \fIwidth\fR and \fIheight\fR are |
| 406 | specified, then the method returns an empty string. Otherwise |
| 407 | it returns a array with two elements, which are the |
| 408 | maximum width and height currently in effect. |
| 409 | The maximum size defaults to the size of the screen. |
| 410 | If resizing has been disabled with the \fBresizable\fR method, |
| 411 | then this method has no effect. |
| 412 | See the sections on geometry management below for more information. |
| 413 | .IP "\fI$toplevel\fR\->\fBminsize\fR(?\fIwidth,height\fR?)" 4 |
| 414 | .IX Item "$toplevel->minsize(?width,height?)" |
| 415 | If \fIwidth\fR and \fIheight\fR are specified, they give the |
| 416 | minimum permissible dimensions for \fI$toplevel\fR. |
| 417 | For gridded windows the dimensions are specified in |
| 418 | grid units; otherwise they are specified in pixel units. |
| 419 | The window manager will restrict the window's dimensions to be |
| 420 | greater than or equal to \fIwidth\fR and \fIheight\fR. |
| 421 | If \fIwidth\fR and \fIheight\fR are |
| 422 | specified, then the method returns an empty string. Otherwise |
| 423 | it returns a array with two elements, which are the |
| 424 | minimum width and height currently in effect. |
| 425 | The minimum size defaults to one pixel in each dimension. |
| 426 | If resizing has been disabled with the \fBresizable\fR method, |
| 427 | then this method has no effect. |
| 428 | See the sections on geometry management below for more information. |
| 429 | .IP "\fI$toplevel\fR\->\fBoverrideredirect(?\fR\fIboolean\fR?)" 4 |
| 430 | .IX Item "$toplevel->overrideredirect(?boolean?)" |
| 431 | If \fIboolean\fR is specified, it must have a proper boolean form and |
| 432 | the override-redirect flag for \fI$toplevel\fR is set to that value. |
| 433 | If \fIboolean\fR is not specified then \fB1\fR or \fB0\fR is |
| 434 | returned to indicate whether or not the override-redirect flag |
| 435 | is currently set for \fI$toplevel\fR. |
| 436 | Setting the override-redirect flag for a window causes |
| 437 | it to be ignored by the window manager; among other things, this means |
| 438 | that the window will not be reparented from the root window into a |
| 439 | decorative frame and the user will not be able to manipulate the |
| 440 | window using the normal window manager mechanisms. |
| 441 | .IP "\fI$toplevel\fR\->\fBpositionfrom\fR(?\fIwho\fR?)" 4 |
| 442 | .IX Item "$toplevel->positionfrom(?who?)" |
| 443 | If \fIwho\fR is specified, it must be either \fBprogram\fR or |
| 444 | \&\fBuser\fR, or an abbreviation of one of these two. It indicates |
| 445 | whether \fI$toplevel\fR's current position was requested by the |
| 446 | program or by the user. Many window managers ignore program-requested |
| 447 | initial positions and ask the user to manually position the window; if |
| 448 | \&\fBuser\fR is specified then the window manager should position the |
| 449 | window at the given place without asking the user for assistance. |
| 450 | If \fIwho\fR is specified as an empty string, then the current position |
| 451 | source is cancelled. |
| 452 | If \fIwho\fR is specified, then the method returns an empty string. |
| 453 | Otherwise it returns \fBuser\fR or \f(CW$widget\fR to indicate the |
| 454 | source of the window's current position, or an empty string if |
| 455 | no source has been specified yet. Most window managers interpret |
| 456 | ``no source'' as equivalent to \fBprogram\fR. |
| 457 | Tk will automatically set the position source to \fBuser\fR |
| 458 | when a \fBgeometry\fR method is invoked, unless the source has |
| 459 | been set explicitly to \fBprogram\fR. |
| 460 | .IP "\fI$toplevel\fR\->\fBprotocol\fR(?\fIname\fR?,?\fIcallback\fR?)" 4 |
| 461 | .IX Item "$toplevel->protocol(?name?,?callback?)" |
| 462 | This method is used to manage window manager protocols such as |
| 463 | \&\fB\s-1WM_DELETE_WINDOW\s0\fR. |
| 464 | \&\fIName\fR is the name of an atom corresponding to a window manager |
| 465 | protocol, such as \fB\s-1WM_DELETE_WINDOW\s0\fR or \fB\s-1WM_SAVE_YOURSELF\s0\fR |
| 466 | or \fB\s-1WM_TAKE_FOCUS\s0\fR. |
| 467 | If both \fIname\fR and \fIcallback\fR are specified, then \fIcallback\fR |
| 468 | is associated with the protocol specified by \fIname\fR. |
| 469 | \&\fIName\fR will be added to \fI$toplevel\fR's \fB\s-1WM_PROTOCOLS\s0\fR |
| 470 | property to tell the window manager that the application has a |
| 471 | protocol handler for \fIname\fR, and \fIcallback\fR will |
| 472 | be invoked in the future whenever the window manager sends a |
| 473 | message to the client for that protocol. |
| 474 | In this case the method returns an empty string. |
| 475 | If \fIname\fR is specified but \fIcallback\fR isn't, then the current |
| 476 | callback for \fIname\fR is returned, or an empty string if there |
| 477 | is no handler defined for \fIname\fR. |
| 478 | If \fIcallback\fR is specified as an empty string then the current |
| 479 | handler for \fIname\fR is deleted and it is removed from the |
| 480 | \&\fB\s-1WM_PROTOCOLS\s0\fR property on \fI$toplevel\fR; an empty string is |
| 481 | returned. |
| 482 | Lastly, if neither \fIname\fR nor \fIcallback\fR is specified, the |
| 483 | method returns a list of all the protocols for which handlers |
| 484 | are currently defined for \fI$toplevel\fR. |
| 485 | .RS 4 |
| 486 | .Sp |
| 487 | .RS 8 |
| 488 | Tk always defines a protocol handler for \fB\s-1WM_DELETE_WINDOW\s0\fR, even if |
| 489 | you haven't asked for one with \fBprotocol\fR. |
| 490 | If a \fB\s-1WM_DELETE_WINDOW\s0\fR message arrives when you haven't defined |
| 491 | a handler, then Tk handles the message by destroying the window for |
| 492 | which it was received. |
| 493 | .RE |
| 494 | .RE |
| 495 | .RS 4 |
| 496 | .RE |
| 497 | .IP "\fI$toplevel\fR\->\fBresizable\fR(?\fIwidth,height\fR?)" 4 |
| 498 | .IX Item "$toplevel->resizable(?width,height?)" |
| 499 | This method controls whether or not the user may interactively |
| 500 | resize a top-level window. If \fIwidth\fR and \fIheight\fR are |
| 501 | specified, they are boolean values that determine whether the |
| 502 | width and height of \fI$toplevel\fR may be modified by the user. |
| 503 | In this case the method returns an empty string. |
| 504 | If \fIwidth\fR and \fIheight\fR are omitted then the method |
| 505 | returns a list with two 0/1 elements that indicate whether the |
| 506 | width and height of \fI$toplevel\fR are currently resizable. |
| 507 | By default, windows are resizable in both dimensions. |
| 508 | If resizing is disabled, then the window's size will be the size |
| 509 | from the most recent interactive resize or \fBgeometry\fR |
| 510 | method. If there has been no such operation then |
| 511 | the window's natural size will be used. |
| 512 | .IP "\fI$toplevel\fR\->\fBsizefrom\fR(?\fIwho\fR?)" 4 |
| 513 | .IX Item "$toplevel->sizefrom(?who?)" |
| 514 | If \fIwho\fR is specified, it must be either \fBprogram\fR or |
| 515 | \&\fBuser\fR, or an abbreviation of one of these two. It indicates |
| 516 | whether \fI$toplevel\fR's current size was requested by the |
| 517 | program or by the user. Some window managers ignore program-requested |
| 518 | sizes and ask the user to manually size the window; if |
| 519 | \&\fBuser\fR is specified then the window manager should give the |
| 520 | window its specified size without asking the user for assistance. |
| 521 | If \fIwho\fR is specified as an empty string, then the current size |
| 522 | source is cancelled. |
| 523 | If \fIwho\fR is specified, then the method returns an empty string. |
| 524 | Otherwise it returns \fBuser\fR or \f(CW$widget\fR to indicate the |
| 525 | source of the window's current size, or an empty string if |
| 526 | no source has been specified yet. Most window managers interpret |
| 527 | ``no source'' as equivalent to \fBprogram\fR. |
| 528 | .IP "\fI$toplevel\fR\->\fBstate\fR" 4 |
| 529 | .IX Item "$toplevel->state" |
| 530 | Returns the current state of \f(CW$widget:\fR either \fBnormal\fR, |
| 531 | \&\fBiconic\fR, \fBwithdrawn\fR, or \fBicon\fR. The difference |
| 532 | between \fBiconic\fR and \fBicon\fR is that \fBiconic\fR refers |
| 533 | to a window that has been iconified (e.g., with the \fBiconify\fR |
| 534 | method) while \fBicon\fR refers to a window whose only purpose is |
| 535 | to serve as the icon for some other window (via the \fBiconwindow\fR |
| 536 | method). |
| 537 | .IP "\fI$toplevel\fR\->\fBtitle\fR(?\fIstring\fR?)" 4 |
| 538 | .IX Item "$toplevel->title(?string?)" |
| 539 | If \fIstring\fR is specified, then it will be passed to the window |
| 540 | manager for use as the title for \fI$toplevel\fR (the window manager |
| 541 | should display this string in \fI$toplevel\fR's title bar). In this |
| 542 | case the method returns an empty string. If \fIstring\fR isn't |
| 543 | specified then the method returns the current title for the |
| 544 | \&\fI$toplevel\fR. The title for a window defaults to its name. |
| 545 | .IP "\fI$toplevel\fR\->\fBtransient\fR(?\fImaster\fR?)" 4 |
| 546 | .IX Item "$toplevel->transient(?master?)" |
| 547 | If \fImaster\fR is specified, then the window manager is informed |
| 548 | that \fI$toplevel\fR is a transient window (e.g. pull-down menu) working |
| 549 | on behalf of \fImaster\fR (where \fImaster\fR is |
| 550 | a top-level window). Some window managers will use |
| 551 | this information to manage \fI$toplevel\fR specially. If \fImaster\fR |
| 552 | is specified as an empty string then \fI$toplevel\fR is marked as not |
| 553 | being a transient window any more. If \fImaster\fR is specified, |
| 554 | then the method returns an empty string. Otherwise the method |
| 555 | returns the path name of \fI$toplevel\fR's current master, or an |
| 556 | empty string if \fI$toplevel\fR isn't currently a transient window. |
| 557 | .IP "\fI$toplevel\fR\->\fBwithdraw\fR" 4 |
| 558 | .IX Item "$toplevel->withdraw" |
| 559 | Arranges for \fI$toplevel\fR to be withdrawn from the screen. This |
| 560 | causes the window to be unmapped and forgotten about by the window |
| 561 | manager. If the window |
| 562 | has never been mapped, then this method |
| 563 | causes the window to be mapped in the withdrawn state. Not all |
| 564 | window managers appear to know how to handle windows that are |
| 565 | mapped in the withdrawn state. |
| 566 | Note: it sometimes seems to be necessary to withdraw a |
| 567 | window and then re-map it (e.g. with \fBdeiconify\fR) to get some |
| 568 | window managers to pay attention to changes in window attributes |
| 569 | such as group. |
| 570 | .IP "\fI$toplevel\fR\->\fBwrapper\fR" 4 |
| 571 | .IX Item "$toplevel->wrapper" |
| 572 | Returns the window id of the wrapper window in which Tk has placed |
| 573 | \&\fI$toplevel\fR. This is the id by which window manager will know |
| 574 | \&\fI$toplevel\fR, and so is appropriate place to add X properties. |
| 575 | .SH "ICON SIZES" |
| 576 | .IX Header "ICON SIZES" |
| 577 | The sizes of bitmaps/images that can be used as icons in this manner are platform |
| 578 | and window manager dependant. Unix window managers are typically more tolerant |
| 579 | than Win32. It is possible that coloured \f(CW\*(C`iconimage\*(C'\fR icons may cause problems |
| 580 | on some X window managers. |
| 581 | .IP "\(bu Win32" 4 |
| 582 | .IX Item "Win32" |
| 583 | \&\f(CW\*(C`iconimage\*(C'\fR and \f(CW\*(C`iconbitmap\*(C'\fR set the \*(L"large\*(R" icon, which should be |
| 584 | 32x32, it will automatically be scaled down to 16x16 for use as a small icon. |
| 585 | Win32 ignores \f(CW\*(C`iconwin\*(C'\fR requests. |
| 586 | .ie n .IP "\(bu \s-1KDE\s0's ""kwm""" 4 |
| 587 | .el .IP "\(bu \s-1KDE\s0's ``kwm''" 4 |
| 588 | .IX Item "KDE's kwm" |
| 589 | Accepts coloured \f(CW\*(C`iconimage\*(C'\fR and black and white \f(CW\*(C`iconbitmap\*(C'\fR but |
| 590 | will scale either to a small (14x14?) icon. Kwm ignores \f(CW\*(C`iconwin\*(C'\fR. |
| 591 | .ie n .IP "\(bu Sun's ""olwm"" or ""olvwm""" 4 |
| 592 | .el .IP "\(bu Sun's ``olwm'' or ``olvwm''" 4 |
| 593 | .IX Item "Sun's olwm or olvwm" |
| 594 | Honours \f(CW\*(C`iconwin\*(C'\fR which will override \f(CW\*(C`iconimage\*(C'\fR or \f(CW\*(C`iconbitmap\*(C'\fR. |
| 595 | Coloured images work. |
| 596 | .IP "\(bu Sun's \s-1CDE\s0 window manager" 4 |
| 597 | .IX Item "Sun's CDE window manager" |
| 598 | Coloured images work. ... |
| 599 | .SH "GEOMETRY MANAGEMENT" |
| 600 | .IX Header "GEOMETRY MANAGEMENT" |
| 601 | By default a top-level window appears on the screen in its |
| 602 | \&\fInatural size\fR, which is the one determined internally by its |
| 603 | widgets and geometry managers. |
| 604 | If the natural size of a top-level window changes, then the window's size |
| 605 | changes to match. |
| 606 | A top-level window can be given a size other than its natural size in two ways. |
| 607 | First, the user can resize the window manually using the facilities |
| 608 | of the window manager, such as resize handles. |
| 609 | Second, the application can request a particular size for a |
| 610 | top-level window using the \fBgeometry\fR method. |
| 611 | These two cases are handled identically by Tk; in either case, |
| 612 | the requested size overrides the natural size. |
| 613 | You can return the window to its natural by invoking \fBgeometry\fR |
| 614 | with an empty \fIgeometry\fR string. |
| 615 | .PP |
| 616 | Normally a top-level window can have any size from one pixel in each |
| 617 | dimension up to the size of its screen. |
| 618 | However, you can use the \fBminsize\fR and \fBmaxsize\fR methods |
| 619 | to limit the range of allowable sizes. |
| 620 | The range set by \fBminsize\fR and \fBmaxsize\fR applies to |
| 621 | all forms of resizing, including the window's natural size as |
| 622 | well as manual resizes and the \fBgeometry\fR method. |
| 623 | You can also use the method \fBresizable\fR to completely |
| 624 | disable interactive resizing in one or both dimensions. |
| 625 | .SH "GRIDDED GEOMETRY MANAGEMENT" |
| 626 | .IX Header "GRIDDED GEOMETRY MANAGEMENT" |
| 627 | Gridded geometry management occurs when one of the widgets of an |
| 628 | application supports a range of useful sizes. |
| 629 | This occurs, for example, in a text editor where the scrollbars, |
| 630 | menus, and other adornments are fixed in size but the edit widget |
| 631 | can support any number of lines of text or characters per line. |
| 632 | In this case, it is usually desirable to let the user specify the |
| 633 | number of lines or characters\-per\-line, either with the |
| 634 | \&\fBgeometry\fR method or by interactively resizing the window. |
| 635 | In the case of text, and in other interesting cases also, only |
| 636 | discrete sizes of the window make sense, such as integral numbers |
| 637 | of lines and characters\-per\-line; arbitrary pixel sizes are not useful. |
| 638 | .PP |
| 639 | Gridded geometry management provides support for this kind of |
| 640 | application. |
| 641 | Tk (and the window manager) assume that there is a grid of some |
| 642 | sort within the application and that the application should be |
| 643 | resized in terms of \fIgrid units\fR rather than pixels. |
| 644 | Gridded geometry management is typically invoked by turning on |
| 645 | the \fBsetGrid\fR option for a widget; it can also be invoked |
| 646 | with the \fBwmGrid\fR method or by calling \fBTk_SetGrid\fR. |
| 647 | In each of these approaches the particular widget (or sometimes |
| 648 | code in the application as a whole) specifies the relationship between |
| 649 | integral grid sizes for the window and pixel sizes. |
| 650 | To return to non-gridded geometry management, invoke |
| 651 | \&\fBgrid\fR with empty argument strings. |
| 652 | .PP |
| 653 | When gridded geometry management is enabled then all the dimensions specified |
| 654 | in \fBminsize\fR, \fBmaxsize\fR, and \fBgeometry\fR methods |
| 655 | are treated as grid units rather than pixel units. |
| 656 | Interactive resizing is also carried out in even numbers of grid units |
| 657 | rather than pixels. |
| 658 | .SH "BUGS" |
| 659 | .IX Header "BUGS" |
| 660 | Most existing window managers appear to have bugs that affect the |
| 661 | operation of the \fBwm\fR methods. For example, some changes won't |
| 662 | take effect if the window is already active: the window will have |
| 663 | to be withdrawn and de-iconified in order to make the change happen. |
| 664 | .SH "SEE ALSO" |
| 665 | .IX Header "SEE ALSO" |
| 666 | Tk::Widget |
| 667 | Tk::tixWm |
| 668 | Tk::Mwm |
| 669 | .SH "KEYWORDS" |
| 670 | .IX Header "KEYWORDS" |
| 671 | aspect ratio, deiconify, focus model, geometry, grid, group, icon, iconify, increments, position, size, title, top-level window, units, window manager |