|
2
|
1 |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>Using the Multiplexing Look and Feel</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
|
|
|
7 |
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
|
8 |
|
|
|
9 |
<b>
|
|
|
10 |
<font size=+3>
|
|
|
11 |
Using the Multiplexing Look and Feel
|
|
|
12 |
</font>
|
|
|
13 |
</b>
|
|
|
14 |
|
|
|
15 |
<blockquote>
|
|
|
16 |
<hr>
|
|
|
17 |
<i>
|
|
|
18 |
<p>
|
|
|
19 |
This document is based on an article
|
|
|
20 |
originally published in
|
|
|
21 |
<a href="http://java.sun.com/products/jfc/tsc/" target="_top"><em>The Swing
|
|
|
22 |
Connection</em></a>.
|
|
|
23 |
</p>
|
|
|
24 |
</i>
|
|
|
25 |
<hr>
|
|
|
26 |
</blockquote>
|
|
|
27 |
|
|
|
28 |
<p>
|
|
|
29 |
The Multiplexing look and feel lets
|
|
|
30 |
you supplement an ordinary look and feel
|
|
|
31 |
(called the <em>default</em> look and feel)
|
|
|
32 |
with one or more <em>auxiliary</em> look and feels.
|
|
|
33 |
For example, you could
|
|
|
34 |
simultaneously provide text-to-speech and Braille outputs,
|
|
|
35 |
in addition to the ordinary visual output that a Swing-based
|
|
|
36 |
application generates,
|
|
|
37 |
by adding
|
|
|
38 |
two auxiliary look and feels (one for text-to-speech,
|
|
|
39 |
the other for Braille)
|
|
|
40 |
to the default look and feel.
|
|
|
41 |
The default look and feel can be any ordinary look and feel --
|
|
|
42 |
the Java or Windows look and feel, for example --
|
|
|
43 |
and requires no modifications to work with auxiliary look and feels.
|
|
|
44 |
</p>
|
|
|
45 |
|
|
|
46 |
</p>
|
|
|
47 |
|
|
|
48 |
<p>
|
|
|
49 |
This document has the following sections:
|
|
|
50 |
<ul>
|
|
|
51 |
<li> <a href="#overview">Overview</a>
|
|
|
52 |
<li> <a href="#howtouse">How to Use Auxiliary Look and Feels</a>
|
|
|
53 |
<li> <a href="#howtowrite">Tips for Writing an Auxiliary Look and Feel</a>
|
|
|
54 |
<ul>
|
|
|
55 |
<li> <a href="#dosanddonts">Dos and Don'ts</a>
|
|
|
56 |
<li> <a href="#uidefaults">Extending UIDefaults</a>
|
|
|
57 |
<li> <a href="#defaultui">Examining Other UI Objects</a>
|
|
|
58 |
</ul>
|
|
|
59 |
<li> <a href="#implementation">How the Multiplexing Look and Feel is
|
|
|
60 |
Implemented</a>
|
|
|
61 |
<li> <a href="#custom">How to Provide a Custom Multiplexing
|
|
|
62 |
Look and Feel</a>
|
|
|
63 |
</ul>
|
|
|
64 |
|
|
|
65 |
<p>
|
|
|
66 |
Before reading further, you should be familiar
|
|
|
67 |
with the concept of pluggable look and feels.
|
|
|
68 |
For basic information, see
|
|
7959
|
69 |
<a href="http://java.sun.com/docs/books/tutorial/uiswing/lookandfeel/plaf.html">How to Set the Look and Feel</a>,
|
|
2
|
70 |
a section in
|
|
|
71 |
<em>The Java Tutorial</em>.
|
|
|
72 |
For architectural details, you can read
|
|
|
73 |
<a
|
|
|
74 |
href="http://java.sun.com/products/jfc/tsc/articles/architecture/#pluggable">Pluggable look-and-feel architecture</a>, a section within
|
|
|
75 |
a <em>Swing Connection</em> article.
|
|
|
76 |
</p>
|
|
|
77 |
|
|
|
78 |
<p>
|
|
|
79 |
<a name="overview">
|
|
|
80 |
<hr width=100% align=LEFT size=2>
|
|
|
81 |
</a>
|
|
|
82 |
<b>
|
|
|
83 |
<font color="#000080" size="+2">Overview</font>
|
|
|
84 |
</b>
|
|
|
85 |
|
|
|
86 |
<p></p>
|
|
|
87 |
|
|
|
88 |
<p>
|
|
|
89 |
|
|
|
90 |
The classes in the
|
|
|
91 |
<code>javax.swing.plaf.multi</code> package
|
|
|
92 |
implement a
|
|
|
93 |
<i>multiplexing look and feel</i>.
|
|
|
94 |
A multiplexing look and feel transparently creates -- and
|
|
|
95 |
simultaneously supports -- UI objects from several different look and feels
|
|
|
96 |
in response to a component requesting its UI object
|
|
|
97 |
(with the <code>getUI</code> method).
|
|
|
98 |
|
|
|
99 |
<p>
|
|
|
100 |
Without a multiplexing look and feel, a
|
|
|
101 |
developer who wanted to enhance a particular look and feel would
|
|
|
102 |
need to extend the classes supporting that look and feel. For example, to
|
|
|
103 |
add text-to-speech support to the Java look and feel without using a multiplexing
|
|
|
104 |
look and feel, the developer would need to create a group of
|
|
|
105 |
classes that extend those of
|
|
|
106 |
the Java look and feel, and add text-to-speech support to the new classes.
|
|
|
107 |
If the developer also wanted to add text-to-speech support to other look
|
|
|
108 |
and feels,
|
|
|
109 |
such as Motif or Windows, the developers would need to create subclasses
|
|
|
110 |
of those classes as well.
|
|
|
111 |
</p>
|
|
|
112 |
|
|
|
113 |
<p>
|
|
|
114 |
This approach has at least two shortcomings:
|
|
|
115 |
<ul type="DISC">
|
|
|
116 |
<li>First, each subclass must use what is
|
|
|
117 |
essentially a copy of the same code, potentially creating a difficult
|
|
|
118 |
support situation for the developer.<br></li>
|
|
|
119 |
<li>Second, and more significantly for the
|
|
|
120 |
end user, some application developers might force a
|
|
|
121 |
particular look and feel to be used. When this approach is used,
|
|
|
122 |
the end user can't even use the enhanced look and feel.</li>
|
|
|
123 |
</ul>
|
|
|
124 |
|
|
|
125 |
<p>
|
|
|
126 |
A multiplexing look and feel
|
|
|
127 |
both these problems simultaneously because it allows multiple look
|
|
|
128 |
and feels to be combined.
|
|
|
129 |
The first problem (having to use what amounts to a second copy of the same
|
|
|
130 |
code) is solved because the developer can create a specialized look
|
|
|
131 |
and feel that can then be combined with other look and feels.
|
|
|
132 |
</p>
|
|
|
133 |
|
|
|
134 |
<p>
|
|
|
135 |
The second problem (having to force the use of
|
|
|
136 |
a particular look and feel) is solved because a specialized look and feel
|
|
|
137 |
can be used with whatever default look and feel the
|
|
|
138 |
application may have locked in place.
|
|
|
139 |
</p>
|
|
|
140 |
|
|
|
141 |
<p>
|
|
|
142 |
The default multiplexing look and feel implementation,
|
|
|
143 |
represented by the <code>MultiLookAndFeel</code> class
|
|
|
144 |
in the <code>javax.swing.plaf.multi</code> package,
|
|
|
145 |
is called (unsurprisingly)
|
|
|
146 |
the Multiplexing look and feel.
|
|
|
147 |
|
|
|
148 |
<p>
|
|
|
149 |
<a name="howtouse">
|
|
|
150 |
<hr width=100% align=LEFT size=2>
|
|
|
151 |
</a>
|
|
|
152 |
<b>
|
|
|
153 |
<font color="#000080" size="+2">How to Use Auxiliary Look and Feels</font>
|
|
|
154 |
</b>
|
|
|
155 |
|
|
|
156 |
<p></p>
|
|
|
157 |
|
|
|
158 |
<p>
|
|
|
159 |
It's easy to use auxiliary look and feels with Swing. To instruct
|
|
|
160 |
Swing to use the Multiplexing look and feel, all an application
|
|
|
161 |
has to do is modify the <code>$JDKHOME/lib/swing.properties</code>
|
|
|
162 |
file to include a definition of the <code>swing.auxiliarylaf</code>
|
|
|
163 |
property. Swing treats the <code>swing.auxiliarylaf</code>
|
|
|
164 |
property as a comma-separated list of <code>LookAndFeel</code>
|
|
|
165 |
subclasses that specify what auxiliary look and feels should be
|
|
|
166 |
used in addition to the default look and feel. If at least one valid
|
|
|
167 |
<code>LookAndFeel</code>
|
|
|
168 |
subclass is specified in the <code>swing.auxiliarylaf</code>
|
|
|
169 |
property, Swing automatically uses the Multiplexing look and feel
|
|
|
170 |
to load and support the default and auxiliary look and feels.
|
|
|
171 |
</p>
|
|
|
172 |
|
|
|
173 |
<p>
|
|
|
174 |
For example, let's assume that an application
|
|
|
175 |
makes use of a look and feel that supports text-to-speech feedback, and also
|
|
|
176 |
uses an look and feel that adds support for a device
|
|
|
177 |
that emits perfume.
|
|
|
178 |
Let's assume that the text-to-speech
|
|
|
179 |
look and feel is named <code>com.myco.TextTalkerLookAndFeel</code>,
|
|
|
180 |
and the look and feel that adds support for perfume
|
|
|
181 |
is named <code>com.smellco.OlfactoryLookAndFeel</code>.
|
|
|
182 |
</p>
|
|
|
183 |
|
|
|
184 |
<p>
|
|
|
185 |
To tell Swing to use both these look and feels
|
|
|
186 |
-- and to use a default look and feel at the same time -- your application
|
|
|
187 |
could simply add the following line to the <code>$JDKHOME/lib/swing.properties</code> file:
|
|
|
188 |
</p>
|
|
|
189 |
|
|
|
190 |
<p>
|
|
|
191 |
<code>
|
|
|
192 |
swing.auxiliarylaf=com.myco.TextTalkerLookAndFeel,<br>
|
|
|
193 |
com.smellco.OlfactoryLookAndFeel</code>
|
|
|
194 |
</p>
|
|
|
195 |
|
|
|
196 |
<p>
|
|
|
197 |
This statement tells Swing to obtain a component's UI from the Multiplexing
|
|
|
198 |
look and feel automatically, instead of obtaining it directly from
|
|
|
199 |
the default look and feel. The resulting multiplexing UI is a small
|
|
|
200 |
delegate that obtains and maintains UIs from the default and auxiliary
|
|
|
201 |
look and feels. As a result, when a method is invoked in a multiplexing
|
|
|
202 |
UI object, the multiplexing UI invokes the same method on each
|
|
|
203 |
of the UIs obtained from the default and auxiliary look and feels.
|
|
|
204 |
</p>
|
|
|
205 |
|
|
|
206 |
<p>
|
|
|
207 |
<a name="howtowrite">
|
|
|
208 |
<hr width=100% align=LEFT size=2>
|
|
|
209 |
</a>
|
|
|
210 |
<b>
|
|
|
211 |
<font color="#000080" size="+2">Tips for Writing an Auxiliary Look and Feel</font>
|
|
|
212 |
</b>
|
|
|
213 |
|
|
|
214 |
<p></p>
|
|
|
215 |
|
|
|
216 |
<p>
|
|
|
217 |
An auxiliary look and feel is like any other look and feel,
|
|
|
218 |
except that it doesn't have to provide the complete support
|
|
|
219 |
that a default look and feel must. For
|
|
|
220 |
example, an auxiliary look and feel that supports just text-to-speech feedback
|
|
|
221 |
doesn't need to provide any code for painting.
|
|
|
222 |
Also, it might not need to support all components --
|
|
|
223 |
<code>JSeparator</code>s, for example, might be ignored.
|
|
|
224 |
|
|
|
225 |
<p>
|
|
|
226 |
Auxiliary look and feels tend to be simple,
|
|
|
227 |
so developing one can be easier than developing a visual
|
|
|
228 |
look and feel.
|
|
|
229 |
The developer can concentrate solely
|
|
|
230 |
on providing the specialized functionality.
|
|
|
231 |
|
|
|
232 |
<p>
|
|
|
233 |
Because the primary purpose of an auxiliary look and feel is to enhance the
|
|
|
234 |
default look and feel, auxiliary look and feels tend
|
|
|
235 |
be nonvisual. Since an auxiliary look and feel is a genuine
|
|
|
236 |
look and feel, however, there is nothing to prevent it
|
|
|
237 |
from rendering information on the display.
|
|
|
238 |
</p>
|
|
|
239 |
|
|
|
240 |
<p>
|
|
|
241 |
Just like for any other look and feel, you
|
|
|
242 |
implement an auxiliary look and feel
|
|
|
243 |
by writing a subclass of <code>javax.swing.LookAndFeel</code>
|
|
|
244 |
and creating subclasses of the
|
|
|
245 |
<code><em>Foo</em>UI</code> classes defined in
|
|
|
246 |
the <code>javax.swing.plaf</code> package.
|
|
|
247 |
</p>
|
|
|
248 |
|
|
|
249 |
<p>
|
|
|
250 |
<br>
|
|
|
251 |
<a name="dosanddonts">
|
|
|
252 |
<font color="#000080" size="+1"><b>Dos and Don'ts</b></font>
|
|
|
253 |
</a>
|
|
|
254 |
</p>
|
|
|
255 |
<p></p>
|
|
|
256 |
|
|
|
257 |
<p>
|
|
|
258 |
The following paragraphs provide some general recommendations for developing
|
|
|
259 |
auxiliary look and feels.
|
|
|
260 |
</p>
|
|
|
261 |
|
|
|
262 |
<p>
|
|
|
263 |
<font color="#000080"><b>Use the <code>installUI</code> method
|
|
|
264 |
to perform all initialization,
|
|
|
265 |
and the <code>uninstallUI</code> method
|
|
|
266 |
to perform all cleanup.</b></font>
|
|
|
267 |
</font>
|
|
|
268 |
</p>
|
|
|
269 |
<ul>
|
|
|
270 |
<p>
|
|
|
271 |
The <code>installUI</code> and <code>uninstallUI</code>
|
|
|
272 |
methods are invoked when a component's look and feel is set.
|
|
|
273 |
The <code>installUI</code> method gives the new UI object
|
|
|
274 |
a chance to add listeners on the component and its data model.
|
|
|
275 |
Similarly, the <code>uninstallUI</code> method
|
|
|
276 |
lets the previous UI object remove its listeners.
|
|
|
277 |
</p>
|
|
|
278 |
</ul>
|
|
|
279 |
<p> <font color="#000080"><b>Don't extend
|
|
|
280 |
visual look and feels.</b></font></p>
|
|
|
281 |
<ul>
|
|
|
282 |
<p> We recommended that you <i>don't</i> implement
|
|
|
283 |
UI classes of an auxiliary look and feel as subclasses of the
|
|
|
284 |
UI classes of a visual look and feel. Why not? Because they might
|
|
|
285 |
accidentally inherit code that installs listeners on a component
|
|
|
286 |
object or renders the component on the display. As a result,
|
|
|
287 |
your auxiliary look and feel would compete with the default look
|
|
|
288 |
and feel rather than cooperating with it.<br>
|
|
|
289 |
<br>
|
|
|
290 |
Instead, we recommend that the UI classes of an auxiliary look
|
|
|
291 |
and feel directly extend the abstract UI classes in the <code>javax.swing.plaf</code>
|
|
|
292 |
package. By using this strategy, the developer of an auxiliary
|
|
|
293 |
look and feel can avoid competing with the default look and feel.</p>
|
|
|
294 |
</ul>
|
|
|
295 |
<p> <font color="#000080"><b>Override all UI-specific methods
|
|
|
296 |
your UI classes inherit.</b></font>
|
|
|
297 |
</p>
|
|
|
298 |
<ul>
|
|
|
299 |
<p> We recommend that each UI class of
|
|
|
300 |
an auxiliary look and feel override the methods
|
|
|
301 |
defined in the <code>javax.swing.plaf</code>
|
|
|
302 |
UI classes it descends from
|
|
|
303 |
The reasons for this recommendation are similar
|
|
|
304 |
to those for not extending a visual look and feel.
|
|
|
305 |
For example, the <code>ComponentUI</code>
|
|
|
306 |
class, from which all UI classes descend,
|
|
|
307 |
provides a default implementation for the <code>update</code>
|
|
|
308 |
method. This default implementation paints on the display
|
|
|
309 |
if the
|
|
|
310 |
component is opaque. If a UI class from a non-visual auxiliary
|
|
|
311 |
look and feel does not override this method, all
|
|
|
312 |
opaque components appear as blank areas on the screen!</p>
|
|
|
313 |
</ul>
|
|
|
314 |
<p>
|
|
|
315 |
|
|
|
316 |
<br>
|
|
|
317 |
<a name="uidefaults">
|
|
|
318 |
<font color="#000080" size="+1"><b>Extending UIDefaults</b></font>
|
|
|
319 |
</a>
|
|
|
320 |
<p></p>
|
|
|
321 |
|
|
|
322 |
<p>In many cases, you
|
|
|
323 |
might want an auxiliary look and feel to be "incomplete." That
|
|
|
324 |
is, you might not need to support the complete set
|
|
|
325 |
of components.
|
|
|
326 |
For example, an auxiliary look and feel might choose
|
|
|
327 |
to provide a <code>ButtonUI</code> subclass but no
|
|
|
328 |
<code>LabelUI</code> subclass.
|
|
|
329 |
This
|
|
|
330 |
option is allowed, and the multiplexing look and feel gracefully
|
|
|
331 |
handles such situations.</p>
|
|
|
332 |
<p>By default, however, Swing issues an error message when it asks
|
|
|
333 |
a look and feel for a UI object and the look and feel does not
|
|
|
334 |
support that UI. This message can be annoying, especially to auxiliary
|
|
|
335 |
look-and-feel developers who don't want to support a particular
|
|
|
336 |
component.</p>
|
|
|
337 |
<p>Fortunately, you can prevent this error
|
|
|
338 |
message by creating a subclass of the <code>UIDefaults</code>
|
|
|
339 |
class and returning an instance of it from the
|
|
|
340 |
<code>getDefaults</code> method
|
|
|
341 |
of your <code>LookAndFeel</code> class.
|
|
|
342 |
For example:
|
|
|
343 |
</p>
|
|
|
344 |
<p><code>public class MyAuxLookAndFeel
|
|
|
345 |
extends LookAndFeel {<br>
|
|
|
346 |
...<br>
|
|
|
347 |
public UIDefaults getDefaults() {<br>
|
|
|
348 |
<b>UIDefaults table = <br>
|
|
|
349 |
|
|
|
350 |
new MyAuxUIDefaults();<br>
|
|
|
351 |
</b> Object[] uiDefaults = {<br>
|
|
|
352 |
"ButtonUI", "MyAuxButtonUI",<br>
|
|
|
353 |
...<br>
|
|
|
354 |
}<br>
|
|
|
355 |
table.putDefaults(uiDefaults);<br>
|
|
|
356 |
return table;<br>
|
|
|
357 |
}<br>
|
|
|
358 |
}<br>
|
|
|
359 |
<br>
|
|
|
360 |
<b>class MyAuxUIDefaults extends UIDefaults {<br>
|
|
|
361 |
protected void getUIError(String msg) {<br>
|
|
|
362 |
//System.err.println<br>
|
|
|
363 |
// ("An
|
|
|
364 |
annoying message!");<br>
|
|
|
365 |
}<br>
|
|
|
366 |
}</b></code></p>
|
|
|
367 |
|
|
|
368 |
<p>
|
|
|
369 |
In the preceding example, an auxiliary look and feel named <code>MyAux</code>
|
|
|
370 |
creates a <code>UIDefaults</code> subclass
|
|
|
371 |
that overrides the <code>getUIError</code>
|
|
|
372 |
method. The <code>getUIError</code>
|
|
|
373 |
method is the method that is invoked when Swing cannot find a UI
|
|
|
374 |
object in a look and feel. By merely doing nothing in this method,
|
|
|
375 |
you can avoid the error message.</p>
|
|
|
376 |
<p>
|
|
|
377 |
|
|
|
378 |
<br>
|
|
|
379 |
<a name="defaultui">
|
|
|
380 |
<b><font color="#000080" size="+1">Examining Other UI Objects</font></b>
|
|
|
381 |
</a>
|
|
|
382 |
<p></p>
|
|
|
383 |
|
|
|
384 |
<p>In
|
|
|
385 |
rare instances, a UI object from an auxiliary look and feel
|
|
|
386 |
may be interested in the default UI object used by the component. In
|
|
|
387 |
these cases, the UI object from auxiliary look and feel can obtain
|
|
|
388 |
the UI from a component by calling its <code>getUI</code>
|
|
|
389 |
method. The returned UI is an instance of one of the multiplexing
|
|
|
390 |
look and feel UI classes (for example, <code>MultiButtonUI</code>).
|
|
|
391 |
The UI object from the auxiliary look and feel can call the <code>getUIs</code>
|
|
|
392 |
method of the returned object to obtain an array containing a complete list
|
|
|
393 |
of all UI objects handled by the multiplexing UI. The first element
|
|
|
394 |
is guaranteed to be the UI created from the default look and feel.
|
|
|
395 |
</p>
|
|
|
396 |
|
|
|
397 |
<p>
|
|
|
398 |
<a name="implementation">
|
|
|
399 |
<hr width=100% align=LEFT size=2>
|
|
|
400 |
</a>
|
|
|
401 |
<font color="#000080" size="+2"><b>How the Multiplexing Look and Feel
|
|
|
402 |
Is Implemented</b></font>
|
|
|
403 |
<p></p>
|
|
|
404 |
|
|
|
405 |
<p>
|
|
|
406 |
The Multiplexing look and feel
|
|
|
407 |
(represented by
|
|
|
408 |
<code>javax.swing.plaf.multi.MultiLookAndFeel</code>)
|
|
|
409 |
is meant to be transparent to
|
|
|
410 |
all developers and users. It should "just work" -- and
|
|
|
411 |
it is used only when the user tells Swing to use an auxiliary look
|
|
|
412 |
and feel.</p>
|
|
|
413 |
|
|
|
414 |
<p>
|
|
|
415 |
When the Multiplexing look and
|
|
|
416 |
feel is in use, the type of the UI object
|
|
|
417 |
associated with each component
|
|
|
418 |
depends on whether
|
|
|
419 |
any of the auxiliary look and feels currently in use
|
|
|
420 |
support the component.
|
|
|
421 |
If so, the component's UI object is
|
|
|
422 |
an instance of a multiplexing UI.
|
|
|
423 |
If only the default look and feel supports the component,
|
|
|
424 |
then the component gets
|
|
|
425 |
a UI object from the default look and feel,
|
|
|
426 |
just as if no auxiliary look and feels were installed.
|
|
|
427 |
|
|
|
428 |
<p>
|
|
|
429 |
A multiplexing UI object
|
|
|
430 |
obtains and maintains UI objects
|
|
|
431 |
from the default and auxiliary look
|
|
|
432 |
and feels,
|
|
|
433 |
referring to these UIs in the following manner:
|
|
|
434 |
|
|
|
435 |
<ul type="DISC">
|
|
|
436 |
<li> The UI object from the default look
|
|
|
437 |
and feel is always the first to be created. After that, a UI object
|
|
|
438 |
is created from each auxiliary look and feel in the order
|
|
|
439 |
they are specified in the <code>swing.auxiliarylaf</code>
|
|
|
440 |
property.</li>
|
|
|
441 |
<p>
|
|
|
442 |
<li> When a method that requests information
|
|
|
443 |
from a UI object is invoked, the multiplexing UI object
|
|
|
444 |
invokes the method on all the UI objects, but returns
|
|
|
445 |
only the results from the UI for the default look and feel.
|
|
|
446 |
For example, when the <code>getPreferredSize</code>
|
|
|
447 |
method is invoked on a multiplexing UI, the UI returns only the
|
|
|
448 |
results of invoking <code>getPreferredSize</code>
|
|
|
449 |
on the UI obtained from the default look and feel.
|
|
|
450 |
The <code>getPreferredSize</code> method
|
|
|
451 |
is also invoked on the UI object for each auxiliary look and feel,
|
|
|
452 |
but the return values are ignored.
|
|
|
453 |
</li>
|
|
|
454 |
<p>
|
|
|
455 |
<li> When a method that does not request information
|
|
|
456 |
from the UI object is invoked, the multiplexing UI object
|
|
|
457 |
invokes that method on all UIs --
|
|
|
458 |
on the UI object obtained from the default look
|
|
|
459 |
and feel
|
|
|
460 |
and on all the UIs obtained from the auxiliary look and feels,
|
|
|
461 |
as well.
|
|
|
462 |
For example, invoking the <code>installUI</code>
|
|
|
463 |
method on a multiplexing UI causes the multiplexing UI to invoke
|
|
|
464 |
<code>installUI</code>
|
|
|
465 |
on the UI obtained from the default look and feel and the UIs obtained from
|
|
|
466 |
the auxiliary factories.</li>
|
|
|
467 |
</ul>
|
|
|
468 |
<p> In all cases, the UI object obtained from
|
|
|
469 |
the default look and feel is acted upon first, and then the auxiliary
|
|
|
470 |
look and feels are acted upon in the order they are specified in
|
|
|
471 |
the <code>swing.auxiliarylaf</code>
|
|
|
472 |
property.
|
|
|
473 |
</p>
|
|
|
474 |
|
|
|
475 |
<p>
|
|
|
476 |
|
|
|
477 |
<a name="custom">
|
|
|
478 |
<hr width=100% align=LEFT size=2>
|
|
|
479 |
</a>
|
|
|
480 |
<font color="#000080" size="+2"><b>How to Provide a Custom Multiplexing Look
|
|
|
481 |
and Feel</b></font>
|
|
|
482 |
<p></p>
|
|
|
483 |
|
|
|
484 |
<p><font color="#000080" size="+2"><b></b></font>While
|
|
|
485 |
we hope the behavior of the Multiplexing look and feel is
|
|
|
486 |
flexible enough not to require an alternative multiplexing look
|
|
|
487 |
and feel, Swing allows the user to specify another multiplexing look
|
|
|
488 |
and feel to use.
|
|
|
489 |
</p>
|
|
|
490 |
|
|
|
491 |
<p> To do that, all the user has to do is modify
|
|
|
492 |
the <code>$JDKHOME/lib/swing.properties</code>
|
|
|
493 |
file to include a definition of the <code>swing.plaf.multiplexinglaf</code>
|
|
|
494 |
property. Swing then treats the <code>swing.plaf.multiplexinglaf</code>
|
|
|
495 |
property as a <code>LookAndFeel</code>
|
|
|
496 |
subclass that supports multiplexing.
|
|
|
497 |
</p>
|
|
|
498 |
<p> For example, if a user has a multiplexing
|
|
|
499 |
look and feel represented by <code>com.myco.SuperMultiLookAndFeel</code>
|
|
|
500 |
that is a better match for their needs than the Multiplexing
|
|
|
501 |
look and feel
|
|
|
502 |
(<code>javax.swing.plaf.multi.MultiLookAndFeel</code>),
|
|
|
503 |
the user could include the following line in <code>$JDKHOME/lib/swing.properties</code>:
|
|
|
504 |
</p>
|
|
|
505 |
|
|
|
506 |
<p>
|
|
|
507 |
<code>swing.plaf.multiplexinglaf = com.myco.SuperMultiLookAndFeel</code>
|
|
|
508 |
</p>
|
|
|
509 |
|
|
|
510 |
<p>
|
|
|
511 |
This statement instructs Swing to use <code>com.myco.SuperMultiLookAndFeel</code>
|
|
|
512 |
instead of <code>javax.swing.plaf.multi.MultiLookAndFeel</code>. But
|
|
|
513 |
if you use this kind of statement, be careful, because the suppliers
|
|
|
514 |
of auxiliary look and feels will most likely have developed and
|
|
|
515 |
tested against our Multiplexing look and feel.
|
|
|
516 |
</p>
|
|
|
517 |
|
|
|
518 |
</BODY>
|
|
|
519 |
</HTML>
|