| 1 |
578 |
markom |
'\"
|
| 2 |
|
|
'\" Copyright (c) 1990-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 |
|
|
'\"
|
| 9 |
|
|
'\" RCS: @(#) $Id: GeomReq.3,v 1.1.1.1 2002-01-16 10:25:48 markom Exp $
|
| 10 |
|
|
'\"
|
| 11 |
|
|
.so man.macros
|
| 12 |
|
|
.TH Tk_GeometryRequest 3 "" Tk "Tk Library Procedures"
|
| 13 |
|
|
.BS
|
| 14 |
|
|
.SH NAME
|
| 15 |
|
|
Tk_GeometryRequest, Tk_SetInternalBorder \- specify desired geometry or internal border for a window
|
| 16 |
|
|
.SH SYNOPSIS
|
| 17 |
|
|
.nf
|
| 18 |
|
|
\fB#include \fR
|
| 19 |
|
|
.sp
|
| 20 |
|
|
\fBTk_GeometryRequest\fR(\fItkwin, reqWidth, reqHeight\fR)
|
| 21 |
|
|
.sp
|
| 22 |
|
|
\fBTk_SetInternalBorder\fR(\fItkwin, width\fR)
|
| 23 |
|
|
.SH ARGUMENTS
|
| 24 |
|
|
.AS baseHeight clientData
|
| 25 |
|
|
.AP Tk_Window tkwin in
|
| 26 |
|
|
Window for which geometry is being requested.
|
| 27 |
|
|
.AP int reqWidth in
|
| 28 |
|
|
Desired width for \fItkwin\fR, in pixel units.
|
| 29 |
|
|
.AP int reqHeight in
|
| 30 |
|
|
Desired height for \fItkwin\fR, in pixel units.
|
| 31 |
|
|
.AP int width in
|
| 32 |
|
|
Space to leave for internal border for \fItkwin\fR, in pixel units.
|
| 33 |
|
|
.BE
|
| 34 |
|
|
|
| 35 |
|
|
.SH DESCRIPTION
|
| 36 |
|
|
.PP
|
| 37 |
|
|
\fBTk_GeometryRequest\fR is called by widget code to indicate its
|
| 38 |
|
|
preference for the dimensions of a particular window. The arguments
|
| 39 |
|
|
to \fBTk_GeometryRequest\fR are made available to the geometry
|
| 40 |
|
|
manager for the window, which then decides on the actual geometry
|
| 41 |
|
|
for the window. Although geometry managers generally try to satisfy
|
| 42 |
|
|
requests made to \fBTk_GeometryRequest\fR, there is no guarantee that
|
| 43 |
|
|
this will always be possible. Widget code should not assume that
|
| 44 |
|
|
a geometry request will be satisfied until it receives a
|
| 45 |
|
|
\fBConfigureNotify\fR event indicating that the geometry change has
|
| 46 |
|
|
occurred. Widget code should never call procedures like
|
| 47 |
|
|
\fBTk_ResizeWindow\fR directly. Instead, it should invoke
|
| 48 |
|
|
\fBTk_GeometryRequest\fR and leave the final geometry decisions to
|
| 49 |
|
|
the geometry manager.
|
| 50 |
|
|
.PP
|
| 51 |
|
|
If \fItkwin\fR is a top-level window, then the geometry information
|
| 52 |
|
|
will be passed to the window manager using the standard ICCCM protocol.
|
| 53 |
|
|
.PP
|
| 54 |
|
|
\fBTk_SetInternalBorder\fR is called by widget code to indicate that
|
| 55 |
|
|
the widget has an internal border. This means that the widget draws
|
| 56 |
|
|
a decorative border inside the window instead of using the standard
|
| 57 |
|
|
X borders, which are external to the window's area. For example,
|
| 58 |
|
|
internal borders are used to draw 3-D effects. \fIWidth\fR
|
| 59 |
|
|
specifies the width of the border in pixels. Geometry managers will
|
| 60 |
|
|
use this information to avoid placing any children of \fItkwin\fR
|
| 61 |
|
|
overlapping the outermost \fIwidth\fR pixels of \fItkwin\fR's area.
|
| 62 |
|
|
.PP
|
| 63 |
|
|
The information specified in calls to \fBTk_GeometryRequest\fR and
|
| 64 |
|
|
\fBTk_SetInternalBorder\fR can be retrieved using the macros
|
| 65 |
|
|
\fBTk_ReqWidth\fR, \fBTk_ReqHeight\fR, and \fBTk_InternalBorderWidth\fR.
|
| 66 |
|
|
See the \fBTk_WindowId\fR manual entry for details.
|
| 67 |
|
|
|
| 68 |
|
|
.SH KEYWORDS
|
| 69 |
|
|
geometry, request
|
