aboutsummaryrefslogtreecommitdiff
path: root/libXaw/spec/CH7.intro
blob: 7aaa1896bd926d1568c4096b8ae08891ffa4cb38 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
.LP
.bp
.if e .bp  \" make sure we break on an odd page.
\&
.sp 1
.ce 5
\s+1\fBChapter 7\fP\s-1

\s+1\fBCreating New Widgets (Subclassing)\fP\s-1

\s+1Written By: Ralph Swick\s-1
.sp 2
.nr H1 7
.nr H2 0
.nr H3 0
.nr H4 0
.nr H5 0
.na
.LP
.XS
Chapter 7 - Creating New Widgets (Subclassing)
.XE
.IN "subclassing" "" "@DEF@"
.IN "creating new widgets" "" "@DEF@"
.LP
Although the task of creating a new widget may at first appear a little
daunting, there is a basic simple pattern that all widgets follow.  The
Athena Widget library contains a special widget called the
\fITemplate\fP widget that is intended to assist the novice widget
programmer in writing a custom widget.
.LP
Reasons for wishing to write a custom widget include:
.IP \(bu 3
Providing a graphical interface not currently supported by any existing
widget set.
.IP \(bu 3
Convenient access to resource management procedures to obtain fonts,
colors, etc., even if user customization is not desired.
.IP \(bu 3
Convenient access to user input dispatch and translation management procedures.
.IP \(bu 3
Access to callback mechanism for building higher-level application libraries.
.IP \(bu 3
Customizing the interface or behavior of an existing widget to suit a
special application need.
.IP \(bu 3
Desire to allow user customization of resources such as fonts, colors,
etc., or to allow convenient re-binding of keys and buttons to internal
functions.
.IP \(bu 3
Converting a non-Toolkit application to use the Toolkit.
.LP
In each of these cases, the operation needed to create a new widget is
to "subclass" an existing one.  If the desired semantics of the new
widget are similar to an existing one, then the implementation of the
existing widget should be examined to see how much work would be
required to create a subclass that will then be
able to share the existing class methods.  Much time will be saved in
writing the new widget if an existing widget class Expose, Resize and/or
GeometryManager method can be used by the subclass.
.LP
Note that some trivial uses of a ``bare-bones'' widget may be achieved by
simply creating an instance of the Core
widget.  The class variable to use when creating a Core widget is
.PN widgetClass .
The geometry of the Core widget is determined entirely by the parent
widget.
.LP
It is very often the case than an application will have a special need
for a certain set of functions and that many copies of these functions
will be needed.  For example, when converting an older application to use
the Toolkit, it may be desirable to have a "Window Widget" class that
might have the following semantics:
.IN "Window widget"
.IN "Core widget"
.IN "widgetClass"
.IP \(bu 3
Allocate 2 drawing colors in addition to a background color.
.IP \(bu 3
Allocate a text font.
.IP \(bu 3
Execute an application-supplied function to handle exposure events.
.IP \(bu 3
Execute an application-supplied function to handle user input events.
.LP
It is obvious that a completely general-purpose WindowWidgetClass could
be constructed that would export all class methods as callbacks lists,
but such a widget would be very large and would have to choose some
arbitrary number of resources such as colors to allocate.  An application
that used many instances of the general-purpose widget would therefore
un-necessarily waste many resources.
.LP
.sp
In this section, an outline will be given of the procedure to follow to
construct a special-purpose widget to address the items listed above.
The reader should refer to the appropriate sections of the \fI\*(xT\fP
for complete details of the material outlined here.  Section 1.4 of
the \fI\*(xI\fP should be read in conjunction with this section.
.LP