Commit | Line | Data |
---|---|---|
86530b38 AT |
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 "CONFIGSPECS 1" | |
132 | .TH CONFIGSPECS 1 "2000-12-30" "perl v5.8.0" "User Contributed Perl Documentation" | |
133 | .SH "NAME" | |
134 | Tk::ConfigSpecs \- Defining behaviour of 'configure' for composite widgets. | |
135 | .SH "SYNOPSIS" | |
136 | .IX Header "SYNOPSIS" | |
137 | .Vb 9 | |
138 | \& sub Populate | |
139 | \& { | |
140 | \& my ($composite,$args) = @_; | |
141 | \& ... | |
142 | \& $composite->ConfigSpecs('-attribute' => [ where,dbName,dbClass,default ]); | |
143 | \& $composite->ConfigSpecs('-alias' => '-otherattribute'); | |
144 | \& $composite->ConfigSpecs('DEFAULT' => [ where ]); | |
145 | \& ... | |
146 | \& } | |
147 | .Ve | |
148 | .PP | |
149 | .Vb 1 | |
150 | \& $composite->configure(-attribute => value); | |
151 | .Ve | |
152 | .SH "DESCRIPTION" | |
153 | .IX Header "DESCRIPTION" | |
154 | The aim is to make the composite widget configure method look as much like | |
155 | a regular Tk widget's configure as possible. | |
156 | (See Tk::options for a description of this behaviour.) | |
157 | To enable this the attributes that the composite as a whole accepts | |
158 | needs to be defined. | |
159 | .Sh "Defining the ConfigSpecs for a class." | |
160 | .IX Subsection "Defining the ConfigSpecs for a class." | |
161 | Typically a widget will have one or more calls like the following | |
162 | .PP | |
163 | .Vb 1 | |
164 | \& $composite->ConfigSpecs(-attribute => [where,dbName,dbClass,default]); | |
165 | .Ve | |
166 | .PP | |
167 | in its \fBPopulate\fR method. When \fBConfigSpecs\fR is called this way | |
168 | (with arguments) the arguments are used to construct or augment/replace | |
169 | a hash table for the widget. (More than one \fI\-option\fR=>\fIvalue\fR | |
170 | pair can be specified to a single call.) | |
171 | .PP | |
172 | \&\fBdbName\fR, \fBdbClass\fR and default are only used by \fBConfigDefault\fR described | |
173 | below, or to respond to 'inquiry' configure commands. | |
174 | .PP | |
175 | It may be either one of the values below, or a list of such values | |
176 | enclosed in \fB[]\fR. | |
177 | .PP | |
178 | The currently permitted values of \fBwhere\fR are: | |
179 | .IP "\fB'\s-1ADVERTISED\s0'\fR" 4 | |
180 | .IX Item "'ADVERTISED'" | |
181 | apply \fBconfigure\fR to \fIadvertised\fR subwidgets. | |
182 | .IP "\fB'\s-1DESCENDANTS\s0'\fR" 4 | |
183 | .IX Item "'DESCENDANTS'" | |
184 | apply \fBconfigure\fR recursively to all descendants. | |
185 | .IP "\fB'\s-1CALLBACK\s0'\fR" 4 | |
186 | .IX Item "'CALLBACK'" | |
187 | Setting the attribute does \f(CW\*(C`Tk::Callback\->new($value)\*(C'\fR before storing | |
188 | in \f(CW\*(C`$composite\->{Configure}{\-attribute}\*(C'\fR. This is appropriate for | |
189 | \&\f(CW\*(C`\-command => ...\*(C'\fR attributes that are handled by the composite and not | |
190 | forwarded to a subwidget. (E.g. \fBTk::Tiler\fR has \f(CW\*(C`\-yscrollcommand\*(C'\fR to | |
191 | allow it to have scrollbar attached.) | |
192 | .Sp | |
193 | This may be the first of several 'validating' keywords (e.g. font, cursor, | |
194 | anchor etc.) that core Tk makes special for C code. | |
195 | .IP "\fB'\s-1CHILDREN\s0'\fR" 4 | |
196 | .IX Item "'CHILDREN'" | |
197 | apply \fBconfigure\fR to all children. (Children are the immediate | |
198 | descendants of a widget.) | |
199 | .IP "\fB'\s-1METHOD\s0'\fR" 4 | |
200 | .IX Item "'METHOD'" | |
201 | Call \f(CW\*(C`$cw\->attribute(value)\*(C'\fR | |
202 | .Sp | |
203 | This is the most general case. Simply have a method of the composite | |
204 | class with the same name as the attribute. The method may do any | |
205 | validation and have whatever side-effects you like. (It is probably | |
206 | worth 'queueing' using \fBafterIdle\fR for more complex side\-effects.) | |
207 | .IP "\fB'\s-1PASSIVE\s0'\fR" 4 | |
208 | .IX Item "'PASSIVE'" | |
209 | Simply store value in \f(CW\*(C`$composite\->{Configure}{\-attribute}\*(C'\fR. | |
210 | .Sp | |
211 | This form is also a useful placeholder for attributes which you | |
212 | currently only handle at create time. | |
213 | .IP "\fB'\s-1SELF\s0'\fR" 4 | |
214 | .IX Item "'SELF'" | |
215 | Apply \fBconfigure\fR to the core widget (e.g. \fBFrame\fR) that is the basis of | |
216 | the composite. (This is the default behaviour for most attributes which | |
217 | makes a simple Frame behave the way you would expect.) Note that once | |
218 | you have specified \fBConfigSpecs\fR for an attribute you must explicitly | |
219 | include \f(CW'SELF'\fR in the list if you want the attribute to apply to the | |
220 | composite itself (this avoids nasty infinite recursion problems). | |
221 | .IP "\fB$reference\fR (blessed)" 4 | |
222 | .IX Item "$reference (blessed)" | |
223 | Call \fB$reference\fR\->configure(\-attribute => value) | |
224 | .Sp | |
225 | A common case is where \fB$reference\fR is a subwidget. | |
226 | .Sp | |
227 | $reference may also be result of | |
228 | .Sp | |
229 | .Vb 1 | |
230 | \& Tk::Config->new(setmethod,getmethod,args,...); | |
231 | .Ve | |
232 | .Sp | |
233 | \&\fBTk::Config\fR class is used to implement all the above keyword types. The | |
234 | class has \f(CW\*(C`configure\*(C'\fR and \f(CW\*(C`cget\*(C'\fR methods so allows higher level code to | |
235 | \&\fIalways\fR just call one of those methods on an \fIobject\fR of some kind. | |
236 | .IP "\fBhash reference\fR" 4 | |
237 | .IX Item "hash reference" | |
238 | Defining: | |
239 | .Sp | |
240 | .Vb 6 | |
241 | \& $cw->ConfigSpecs( | |
242 | \& ... | |
243 | \& -option => [ { -optionX=>$w1, -optionY=>[$w2, $w3] }, | |
244 | \& dbname dbclass default ], | |
245 | \& ... | |
246 | \& ); | |
247 | .Ve | |
248 | .Sp | |
249 | So \f(CW\*(C`$cw\->configure(\-option => value)\*(C'\fR actually does | |
250 | .Sp | |
251 | .Vb 3 | |
252 | \& $w1->configure(-optionX => value); | |
253 | \& $w2->configure(-optionY => value); | |
254 | \& $w3->configure(-optionY => value); | |
255 | .Ve | |
256 | .IP "\fB'otherstring'\fR" 4 | |
257 | .IX Item "'otherstring'" | |
258 | Call | |
259 | .Sp | |
260 | .Vb 1 | |
261 | \& $composite->Subwidget('otherstring')->configure( -attribute => value ); | |
262 | .Ve | |
263 | .Sp | |
264 | While this is here for backward compatibility with Tk\-b5, it is probably | |
265 | better just to use the subwidget reference directly. The only | |
266 | case for retaining this form is to allow an additional layer of | |
267 | abstraction \- perhaps having a 'current' subwidget \- this is unproven. | |
268 | .IP "\fBAliases\fR" 4 | |
269 | .IX Item "Aliases" | |
270 | \&\f(CW\*(C`ConfigSpecs( \-alias => '\-otherattribute' )\*(C'\fR is used to make \f(CW\*(C`\-alias\*(C'\fR | |
271 | equivalent to \f(CW\*(C`\-otherattribute\*(C'\fR. For example the aliases | |
272 | .Sp | |
273 | .Vb 2 | |
274 | \& -fg => '-foreground', | |
275 | \& -bg => '-background' | |
276 | .Ve | |
277 | .Sp | |
278 | are provided automatically (if not already specified). | |
279 | .Sh "Default Values" | |
280 | .IX Subsection "Default Values" | |
281 | When the \fBPopulate\fR method returns \fBConfigDefault\fR is called. This calls | |
282 | .PP | |
283 | .Vb 1 | |
284 | \& $composite->ConfigSpecs; | |
285 | .Ve | |
286 | .PP | |
287 | (with no arguments) to return a reference to a hash. Entries in the hash | |
288 | take the form: | |
289 | .PP | |
290 | .Vb 1 | |
291 | \& '-attribute' => [ where, dbName, dbClass, default ] | |
292 | .Ve | |
293 | .PP | |
294 | \&\fBConfigDefault\fR ignores 'where' completely (and also the \s-1DEFAULT\s0 entry) and | |
295 | checks the 'options' database on the widget's behalf, and if an entry is | |
296 | present matching dbName/dbClass | |
297 | .PP | |
298 | .Vb 1 | |
299 | \& -attribute => value | |
300 | .Ve | |
301 | .PP | |
302 | is added to the list of options that \fBnew\fR will eventually apply to the | |
303 | widget. Likewise if there is not a match and default is defined this | |
304 | default value will be added. | |
305 | .PP | |
306 | Alias entries in the hash are used to convert user-specified values for the | |
307 | alias into values for the real attribute. | |
308 | .Sh "\fINew()\fP\-time Configure" | |
309 | .IX Subsection "New()-time Configure" | |
310 | Once control returns to \fBnew\fR, the list of user-supplied options | |
311 | augmented by those from \fBConfigDefault\fR are applied to the widget using the | |
312 | \&\fBconfigure\fR method below. | |
313 | .PP | |
314 | Widgets are most flexible and most Tk-like if they handle the majority of | |
315 | their attributes this way. | |
316 | .Sh "Configuring composites" | |
317 | .IX Subsection "Configuring composites" | |
318 | Once the above have occurred calls of the form: | |
319 | .PP | |
320 | .Vb 1 | |
321 | \& $composite->configure( -attribute => value ); | |
322 | .Ve | |
323 | .PP | |
324 | should behave like any other widget as far as end-user code is concerned. | |
325 | \&\fBconfigure\fR will be handled by \fBTk::Derived::configure\fR as follows: | |
326 | .PP | |
327 | .Vb 1 | |
328 | \& $composite->ConfigSpecs; | |
329 | .Ve | |
330 | .PP | |
331 | is called (with no arguments) to return a reference to a hash \fB\-attribute\fR is | |
332 | looked up in this hash, if \fB\-attribute\fR is not present in the hash then | |
333 | \&\fB'\s-1DEFAULT\s0'\fR is looked for instead. (Aliases are tried as well and cause | |
334 | redirection to the aliased attribute). The result should be a reference to a | |
335 | list like: | |
336 | .PP | |
337 | .Vb 1 | |
338 | \& [ where, dbName, dbClass, default ] | |
339 | .Ve | |
340 | .PP | |
341 | at this stage only \fIwhere\fR is of interest, it maps to a list of object | |
342 | references (maybe only one) foreach one | |
343 | .PP | |
344 | .Vb 1 | |
345 | \& $object->configure( -attribute => value ); | |
346 | .Ve | |
347 | .PP | |
348 | is \fBeval\fRed. | |
349 | .Sh "Inquiring attributes of composites" | |
350 | .IX Subsection "Inquiring attributes of composites" | |
351 | .Vb 1 | |
352 | \& $composite->cget( '-attribute' ); | |
353 | .Ve | |
354 | .PP | |
355 | This is handled by \fBTk::Derived::cget\fR in a similar manner to configure. At | |
356 | present if \fIwhere\fR is a list of more than one object it is ignored completely | |
357 | and the \*(L"cached\*(R" value in | |
358 | .PP | |
359 | .Vb 1 | |
360 | \& $composite->{Configure}{-attribute}. | |
361 | .Ve | |
362 | .PP | |
363 | is returned. | |
364 | .SH "CAVEATS" | |
365 | .IX Header "CAVEATS" | |
366 | It is the author's intention to port as many of the \*(L"Tix\*(R" composite widgets | |
367 | as make sense. The mechanism described above may have to evolve in order to | |
368 | make this possible, although now aliases are handled I think the above is | |
369 | sufficient. | |
370 | .SH "SEE ALSO" | |
371 | .IX Header "SEE ALSO" | |
372 | Tk::composite, | |
373 | Tk::options |