--
`
`--
`
`The X Toolkit: More Bricks for Building User-Interfaces
`]or]
`Widgets For Hire
`
`Ralph R. Swick
`
`Digital Equipment Corporation
`Project Athena
`Massachusetts Institute of Technology
`Cambridge, MA 02139
`swick@ATHENA.MIT.EDU
`
`Mark S. Ackerman
`
`Project Athena
`Massachusetts Institute of Technology
`Cambridge, MA 02139
`ackerman@ATHENA.MIT.EDU
`
`ABSTRACT
`
`Primitives for application-level user interface construction facilities currently
`under development at M.I.T. Project Athena are described. The design philosophy of the
`X Toolkit and associated widgets and some of the practical implications are discussed.
`
`Introduction
`
`The X Window System†1, 2 was developed
`at the Massachusetts Institute of Technology to
`satisfy the needs of a broad spectrum of users for
`a high-performance, high functionality, network-
`based window system that can be implemented on
`a wide variety of high-resolution raster graphics
`display devices. The widespread interest and
`unprecedented vendor support for the X Window
`System has assuaged one of the principal con-
`cerns of application developers: the cost of sup-
`porting multiple hardware platforms with dif-
`ferent base technologies, including window sys-
`tems.
`
`† The X Window System and X Windows are trade-
`marks of the Massachusetts Institute of Technology. Use
`of the latter is strongly discouraged. The developers
`prefer simply "X" when a shorter form is required.
`
`The X Window System has been carefully
`designed to address two (sometimes conflicting)
`desires
`of
`application
`developers:
`to
`use
`hardware-level techniques for maximum perfor-
`mance and to maintain portability with a common
`programming interface across multiple vendor
`platforms. X has succeeded in gaining broad ven-
`dor support largely because its specification is
`intentionally restricted to the set of primitives
`needed to manipulate multiple independent win-
`dow contexts on raster graphics displays without
`declaring (or restricting) the choice of particular
`user-interface semantics. It is explicitly intended
`that developers be able to choose a visual inter-
`face appropriate to their needs, their corporate
`philosophy, their research requirements, religious
`preferences, or whatever.
`
`This restriction to low-level control and
`input primitives in the definition of the X com-
`munications protocol and in the corresponding
`
`Apple Ex. 1023, p. 1
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`- 2 -
`
`application interface layer, Xlib3 ,
`is either a
`strength or a weakness in the X Standard, depend-
`ing on the reviewer’s point of view. Vendors
`whose installed base of products contains well-
`defined visual
`interface and human-computer
`interface researchers find this flexibility in the
`standard to be of major importance. However,
`many
`application
`developers
`consider
`user
`interaction
`and
`other
`higher-level
`graphics
`libraries to be a base system technology that
`should be provided by the hardware vendors and,
`of course, be standard across vendors.
`
`To address the desires of such developers
`for common higher-level development tools, there
`are several projects under way at various loca-
`tions covering different application needs and
`problem domains. One such project
`is the X
`Toolkit
`project,
`a
`collaborative
`effort
`of
`MIT/Project Athena, DEC/Western Software
`Laboratory, Hewlett-Packard Company/Corvallis
`Workstation Operation and others. The X Toolkit
`project
`is producing an applications interface
`layer above the Xlib layer specifically tailored to
`visual user interface construction.
`
`Toolkit Overview
`
`(hereafter called simply
`The X Toolkit
`"Xtk") recognizes that no single comprehensive
`set of user interface tools is likely to be accept-
`able for standardization in the near future.
`In
`order to maximize the utility and acceptability of
`the user interface library, Xtk has been divided
`into two separable pieces. These two layers will
`be described below.
`
`The fundamental entity in Xtk for user
`interface construction is the widget.†
`
`The core of Xtk, the "Intrinsics" (a term
`appropriated from a previous H-P user interface
`library for X), is a set of utility routines intended
`for use in developing widgets. The Intrinsics are
`a set of user interface primitives that are them-
`selves free of visual and interaction style. The
`
`†We chose this term since all other common terms were
`overloaded with inappropriate connotations. We offer
`the observation to the skeptical, however, that the princi-
`pal realization of a widget is its associated X window and
`the common initial letter is not un-useful.
`
`Intrinsics do not constrain the widget writer to
`make the widget look or operate in any particular
`way. These primitives may be used together or
`separately to produce higher layers which do
`incorporate specific policy and style. Such higher
`layers will further reduce applications develop-
`ment cost.
`
`Most applications will call only a few of
`the Intrinsic routines directly. These routines
`offer a uniform programming interface to the
`basic procedures (methods) of all widgets, regard-
`less of the widget type.
`
`The Xtk Intrinsics have been presented in
`an earlier paper4 and, although the detailed design
`has evolved,5 the philosophy and architecture of
`the X Toolkit remain the same. The principal
`additions are a class hierarchy for widget types;
`the separation of widget
`identifiers from the
`corresponding X window identifiers; and the abil-
`ity, using the class hierarchy, for new widgets to
`inherit methods from an existing widget. These
`changes simplify significantly the task of widget
`development and make widgets more modular.
`
`Widgets define input semantics and visual
`appearance. Some widgets are pliable; their input
`semantics (mouse buttons, pointer motion, key-
`board input) are bound at run-time, while other
`widgets may have fixed (hard-coded) semantics.
`Likewise, visual appearance (highlighting, reposi-
`tioning or other animation) may be fixed or may
`be adjusted at run-time.
`
`The Intrinsics provide a uniform way for
`widget developers to handle the common chores
`of widget construction: initialization, input event
`dispatching (including enabling and disabling
`user input dispatch to sub-hierarchies of widgets),
`run-time configurability, uniform handling of
`common events (such as exposure and re-size),
`cleanup, and others. The Intrinsics also include
`the uniform application programming interfaces
`for creating, controlling, and destroying widgets.
`The Intrinsics currently consist of over 90 public
`procedures, of which half are intended solely for
`widget construction.
`
`The goal of the Intrinsics is to make possi-
`ble the quick development of widgets. Sets of
`widgets should adhere to a consistent application
`interface, user
`interaction policy, and visual
`
`Apple Ex. 1023, p. 2
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`is viewed as desirable (or, by
`It
`appearance.
`some, a necessary evil) that the construction of
`multiple such sets ("widget families") covering
`different philosophies be possible with the Xtk
`Intrinsics.
`
`The second piece of the Xtk is a set of
`basic widgets. Most
`application developers
`require a minimum set of widgets as a component
`of any product-quality user interface library. The
`X Toolkit project also recognizes the need for
`concrete examples in a real widget family. To
`serve both these needs, the first author is leading
`the effort at Project Athena to produce a basic
`widget set that will be included with the version 1
`release of the X Toolkit. To distinguish this set
`from others which we know of, or expect to be
`developed, we shall here call these the "Athena
`Widgets".
`
`In addition to the goal of being a basic wid-
`get set, the Athena Widgets have another goal
`arising from code which had been written prior to
`X Version 11. Many of the components of Xtk
`had been prototyped in a toolkit for X Version 10
`that was released by DEC Ultrix Engineering in
`the spring of 1987. The Athena Widgets borrow
`heavily from those prototypes in order to ease
`some of the porting burden for certain applica-
`tions built on these prototypes.
`
`The widgets described here are being
`developed in conjunction with a set of visual
`courseware projects at Project Athena. These
`projects vary considerably in their user dialogs
`and yet require a standard visual appearance.
`This has led to an emphasis in the Athena Wid-
`gets on handling text, graphics, and video in a
`variety of ways, and has extended the widget
`hierarchy to fulfill these needs.
`
`The Athena Widgets are intended to fulfill
`80% of application requirements. We have tried
`to select the critical widgets that will allow the
`easy solution of individual requirements. (See the
`section on Creating New Widgets for more on
`this.)
`
`- 3 -
`
`Intrinsics
`
`the principles espoused in the
`One of
`design of the Xtk is the construction of widgets
`from primitives. We will describe two indepen-
`dent facilities available in the Intrinsics for such
`construction: subclassing and composition. From
`an application point of view, every widget is a
`single object. The actual semantics and appear-
`ance of the widget may, however, be very com-
`plex. For example, a "control panel" widget is
`likely to consist of simpler widgets with a
`"geometry manager" controlling the spatial rela-
`tionship between the component widgets and pos-
`sibly a "focus manager" controlling the dispatch-
`ing of user input to those components. Depend-
`ing upon the needs of the application, such a com-
`pound (or "composite") widget may be imple-
`mented independently and added to the widget
`library as a new widget class, may be constructed
`by the application at run-time with in-line calls to
`the Xtk Intrinsics, or may be constructed by the
`composite widget itself from a resource record
`retrieved through the Intrinsic resource manage-
`ment facilities.
`
`Composition of widgets is most appropriate
`when there are distinct visual regions to a widget,
`each having separate input/display semantics, and
`especially when the same semantics may appear
`in a region of another widget class. In this case,
`the semantics common to both regions may be
`extracted into a more primitive widget class.
`
`This is the principle of modularity of wid-
`gets: the application will still view a composite
`widget (a control panel, for example) as a single
`widget. The internals of this composite widget
`are built when the widget is instantiated. The
`composite widget may determine and instantiate
`all of its components, as for a custom application
`panel. The components may also be instantiated
`and assigned by the client of the composite wid-
`get. Some of the Athena Widgets exhibit this
`recursive construction behavior; e.g. Dialog,
`while others are ‘boxes’, or frames into which the
`client inserts independently instantiated widgets,
`e.g. Form and VPaned.
`
`The second construction facility, subclass-
`ing, allows a widget class to semi-automatically
`inherit some or all of the characteristics of an
`existing widget class, and to share portions of the
`
`Apple Ex. 1023, p. 3
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`- 4 -
`
`the parent (super-) class
`implement
`code that
`methods. The new widget may call upon the
`superclass methods to manipulate any part of the
`widget state defined by the superclass and needs
`only to implement the code to manage the state
`that is unique to the new class.
`
`The subclassing facility is most appropriate
`for new widgets which need only to add addi-
`tional semantics to an existing widget, or to con-
`strain in some manner the full generality of an
`existing widget. Examples of both subclassing
`and composition in the Athena Widgets are
`described below.
`
`Several widget classes have been defined
`solely for the purpose of being subclassed. The
`Composite class provides methods to maintain a
`list of child widgets, to manage the insertion and
`removal of children, to manage requests from the
`children for new geometries, and to manage the
`assignment of input events to specific children
`(input focus). The Constraint class has all the
`methods of Composite and in addition provides
`methods to automatically create and initialize an
`arbitrary data record attached to each child. The
`contents of this data record are defined by each
`subclass of Constraint and are intended to contain
`layout information used by the subclass geometry
`manager. Neither Composite nor Constraint are
`intended to be instantiated; only their subclasses
`are. Nothing in the implementation, however,
`will prevent an application from instantiating any
`class, should it prove useful.
`
`All widgets are expected to be self-
`contained with respect to exposure, resize and
`input event handling. That is, the clients of the
`widget (i.e. the application program or a compos-
`ite widget of which this widget is a component)
`are guaranteed that all exposure and input events
`sent by the X server for the window defining the
`widget will be processed completely by the wid-
`get. A client
`that creates an instance of the
`ScrolledAsciiText widget, for example,
`is not
`involved in any of the details of text re-painting,
`scrolling, selection, cut and paste, and so on. The
`client is also free to assign any shape to the wid-
`get and assume that the widget will adjust to the
`imposed size.
`
`The principal mechanism the Athena Wid-
`gets use to communicate back to the client is the
`
`callback procedure. While a client has the option
`to query the widget state, it is usually more con-
`venient for a command button, for example, to
`directly call a client-supplied procedure when
`‘pressed’ by the user. Some widgets accept more
`than one callback procedure for alternate interac-
`tions that they implement.
`
`Runtime Configurability
`
`One of the major design principles fol-
`lowed by the Athena Widgets is to make as much
`of the user interface as possible customizable by
`the end-user of the application. Fierce debates
`(i.e. wars) break out every time someone pro-
`poses a single set of key or button bindings for all
`users, or that a fixed choice of colors or text fonts
`will be appropriate for all individuals. Even such
`characteristics as whether scrollbars go on the left
`or right (or top/bottom) of a window may be
`appropriate for individual customization.
`
`The Xtk implements run-time configurabil-
`ity through the Xlib Resource Manager. The
`Resource Manager is a general-purpose reposi-
`tory for storage and retrieval of arbitrary data
`within a single process address space. During ini-
`tialization, the Xtk pre-loads the resource data-
`base from the X server and from one or more
`files. When a new instance of a widget is created
`by the application,
`the widget resource list is
`examined and the widget instance is initialized
`with data from the resource database. Each wid-
`get declares an instance name and a class name
`for purposes of matching against resource names
`in the database. The Resource Manager defines
`rules for partial name matches so that a single
`resource
`entry may initialize many widget
`instances.
`
`The implementor of a new widget has the
`choice of which widget characteristics to declare
`as resources and which to hard-wire into the wid-
`get. In general, any instance data for which the
`widget is willing to allow modification requests
`from the client should be declared in the resource
`list.
`
`Widget characteristics such as text font and
`color are obvious resource choices. The Athena
`Widgets also declare the keyboard and mouse
`button bindings as resources.
`In this way, the
`
`Apple Ex. 1023, p. 4
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`- 5 -
`
`user of any application linked against the widgets
`has the option to accept our default bindings or
`enter his/her own bindings. The Resource
`Manager naming mechanism allows the user to
`attach the new bindings to all instances of a wid-
`get class (e.g. Scrollbar) in any application, or to
`a specific widget in a specific application only, or
`any combination in-between. A client may, if it
`so chooses, override any entry in the resource
`database either by storing its own entry (pre-
`ferred), or by passing an explicit value when
`instantiating the widget (discouraged).
`
`The keyboard and button bindings are con-
`figurable in yet a second way. Each widget that
`accepts user input declares a list of action rou-
`tines that may be invoked by input events. The
`Athena Widgets use the Translation Management
`facilities in the Intrinsics to bind keys and buttons
`to widget action routines. These bindings can
`specify parameters to the action routines to
`further configure their behavior. The Scrollbar
`widget, for example, declares three action rou-
`tines, one of which is parameterized so that the
`range of values it returns may be established by
`the bindings.
`
`Using these action routines and the default
`scrollbar bindings, the ScrolledAsciiText widget,
`for example, allows the user to scroll a block of
`text forward or backward by a variable amount
`and to drag the thumb (elevator) to a new posi-
`tion, displaying any portion of the text. A user
`may supply an alternate set of Scrollbar bindings
`that will cause the scrollbar to report full-length
`forward or backward scrolls, independent of the
`pointer position, possibly disabling the variable
`scrolling as desired.
`
`Two of the Athena widget classes exist for
`the purpose of handling interprocess interactions
`with other X client processes. The Shell widget
`defines no user action routines, but maintains all
`the appropriate window properties established by
`convention for X window managers,
`including
`icon representation. Many of these parameters
`are controlled by command line options and
`parsed by the Xtk initialization routine. Most
`applications use a Shell widget as their outermost
`(top level) widget.
`
`Additional semantics appropriate for tem-
`porary, or "pop-up", panels are added to a
`
`subclass of Shell, the Popup widget. From the
`client’s point-of-view, both Shell and Popup are
`simple widgets; they manage exactly one child
`widget and have a trivial geometry manager.
`UIMS developers may find it desirable to extend
`Shell at some time in the future, even allowing
`site tailoring for specific choices of window
`manager. One such addition might be a Shell
`that, when made smaller by the window manager
`(as instructed by the user, of course); added
`scrollbars (or other interaction semantics); and
`provided a movable viewport on the application
`window which, from the application’s point-of-
`view, retains its original size.
`
`Current Widgets
`
`The Athena Widgets are divided into two
`major classes. The first are simple widgets: vari-
`ous sorts of buttons, labels, edit buffers and the
`ubiquitous scrollbar. These form the elemental
`building blocks of a user interface. The second
`are composite widgets:
`scrolled text, dialog
`boxes, and various methods of putting together
`simple widgets in more complex arrangements.
`
`All simple widgets have initialization, reali-
`zation, display, and interaction methods. These
`methods may be fairly simple, as with the button
`widgets, or quite complex, as with the text wid-
`get.
`
`All widgets use the Core widget as the root
`of their class hierarchy. The Core widget (whose
`class name, as a special case, is just Widget) has
`the minimal set of instance fields common to all
`widgets: width, height, border width, and so on.
`While it is not usually intended that an applica-
`tion ever create an instance of (Core) Widget, it is
`supported: an application that wants a simple
`window within a widget panel may instantiate
`Widget and use the resulting window.
`
`The Label widget is just that; a widget that
`displays either a text string or (in the near future)
`a pixmap without any interaction semantics and
`therefore without any callback procedures. It can
`only center, right justify, or left justify its text in
`the client’s choice of fonts within its assigned
`size. (The default size is a bounding box for the
`text or graphics.) A Label may be insensitive, or
`grayed-out, and the border, as for all widgets,
`
`Apple Ex. 1023, p. 5
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`- 6 -
`
`need not be visible. Like all widgets, the Label
`widget processes exposure events on its window
`so the parent can be assured that all visible por-
`tions of the Label are properly refreshed on the
`screen. One will typically use the label to posi-
`tion and paint items intended for display only.
`
`The Command button widget is a subclass
`of Label with interaction semantics and therefore
`a callback procedure. A Command button is a
`Label with enter,
`leave, set, unset, and notify
`actions. When insensitive, the Command button
`does not respond to user input events. On enter
`to a sensitive Command,
`the border will, by
`default, become visibly thicker. On set, the but-
`ton is displayed in reverse video; on unset, the
`button is returned to normal. On notify, a single
`client-supplied callback procedure is activated.
`These actions are mapped, by default but not by
`necessity, to the pointer enter, button down, and
`button up events. One will
`typically use the
`Command button to create "clickable" icons or
`labels that start a program action. The Command
`button is an essential building block for point-
`and-click interfaces.
`
`Figure 1 shows several Labels and Com-
`mand buttons. The user has moved the pointer
`into one of the Command buttons, and the button
`has been highlighted. These Labels and Com-
`mand buttons are enclosed in two layers of
`Boxes, which will be discussed below.
`
`Figure 1
`
`The Command widget can be extended into
`its subclass TwoState button. On set, the Two-
`State widget displays a second label or graphic.
`In all other respects, it is similar to Command.
`TwoState is useful for simultaneously displaying
`and changing a binary application state.
`
`The Toggle widget is also a subclass of
`Command and also has simple interaction seman-
`tics and a callback procedure. A Toggle is a
`binary state button. Once set, e.g. by button
`down, it remains in that state until the user selects
`the Toggle again. Toggle is useful for selecting
`on-off options. The application may use the call-
`back to be notified on each state change, or may
`query the Toggle for its current state as appropri-
`ate.
`
`The Grip widget is a minimal Command
`button. Grip (a.k.a. Knob) has a single callback
`but no default interaction semantics. The interac-
`tions (event bindings) are provided by the client
`when Grip is instantiated. Grip simply uses the X
`window background as its display. This widget
`was built for clients who need to identify specific
`locations where, for example, the pointer may be
`used to drag an object.
`
`The Scrollbar widget implements a verti-
`cal or horizontal scrollbar. There are three call-
`backs: one to move the scrollbar thumb (eleva-
`tor), a second to execute a client callback passing
`a distance in pixels as data, and a third to execute
`an application callback passing as data the posi-
`tion of the pointer as a percentage of the scrollbar
`length. The inclusion of the moveThumb action
`routine in the actions table allows the client some
`control over whether or not the scrollbar widget
`automatically repositions the thumb on input.
`
`The AsciiFile and AsciiString text widgets
`allow the entry, modification, and display of text.
`The widgets can be instantiated in read-only or
`read-write modes. They implement a subset of
`the ever popular Emacs, including mouse-driven
`cutting and pasting. Key bindings are, of course,
`completely settable
`through the Translation
`Manager.†
`
`The AsciiString widget operates on a single
`in-core text string; AsciiFile on a disk file. They
`are both subclasses of Text, which implements
`
`†It has been suggested that some users would prefer an
`AsciiFile widget that allowed them to specify their favor-
`ite text editor. While the full semantics of the Text wid-
`get may be difficult to support with an arbitrary external
`process, it may be an interesting exercise to implement a
`sub-process interface widget that, in carefully defined cir-
`cumstances, could be substituted by the user for the Asci-
`iFile widget.
`
`Apple Ex. 1023, p. 6
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`- 7 -
`
`The Dialog widget is a subclass of Form. It
`arranges a specific combination of Label, Ascii-
`String field, and Command buttons. The Label is
`displayed on the first line, followed by the text
`field, and the buttons are on the last line. Dialog
`is principally a convenience widget implemented
`to handle a common programming problem.
`
`The ScrolledAsciiText widget contains a
`scrollbar and an AsciiString or AsciiFile widget.
`Using the default scrollbar bindings, the Scrolled-
`AsciiText widget allows the user to scroll the
`contained text forward or backward by a variable
`amount. By dragging the thumb to a new posi-
`tion, s/he can display any portion of the text.
`
`The Paned widget manages any number of
`simple or composite widgets in a tiled manner.
`The current Paned widget, VPaned, stacks its
`children vertically with the top and bottom edges
`of successive widgets touching. VPaned uses
`Grip to allow the user to re-position the boun-
`daries between the tiled widgets.
`
`Figure 2 illustrates the current Athena Wid-
`get hierarchy. This diagram should only be of
`interest
`to widget
`developers;
`application
`developers should be concerned only with the
`external characteristics of a widget. The fact that
`a Toggle button actually uses the Label code to
`display its text string should be of no conse-
`quence to the application. The widget class
`Simple contains only the procedure to change a
`widget’s borders to indicate sensitivity or insensi-
`tivity.
`
`Special-purpose Widgets
`
`The Clock widget displays an analog or
`time-of-day clock. The Load widget
`digital
`displays a continuous system load graph. Both of
`these were exercises in converting existing simple
`applications into widgets. Load allows the client
`to supply its own procedure to fetch data, or to
`use the built-in default GetSystemLoadAverage
`procedure.
`
`most of the user interactions. The implementa-
`tion of the Text widget follows a source/sink
`model, allowing for the development of addi-
`tional text sources (other than string and file) and
`for additional display sinks.
`
`These few simple widgets are an attempt to
`create a number of general widgets that can then
`be tailored for individual uses. A more complex
`button widget
`(for example, one that might
`display two lines of text) would require a dif-
`ferent display method but keep the interaction
`method for Command.
`
`However, few interfaces of any real com-
`plexity or use could be created using just these
`simple widgets. The simple widgets must be
`combined using Composite widgets. Composite
`widgets require geometry, child insertion and
`deletion, and input focus methods. The geometry
`manager for the composite may or may not be
`constraint based, and must handle resizing events
`by re-positioning the child widgets. Generally,
`the child insertion, child deletion, and input focus
`methods will be inherited from the superclass,
`Composite.
`
`The Box widget arranges its children in the
`minimum bounding box. The children are
`automatically rearranged when one is deleted or
`added. One can create button areas or horizontal
`menus using Box.
`
`The RadioButtonBox widget is a subclass
`of Box exclusively for Toggle Buttons. It allows
`only one Toggle button to be set at a time. If a
`second Toggle becomes set, the RadioButtonBox
`will check its list of children and unset any others.
`This is useful for mutually exclusive application
`options.
`
`The Form widget can contain any number
`of simple or composite widgets. Form is a
`general-purpose constraint-based layout widget
`that can be instructed to maintain fixed separa-
`tions between children, or to maintain fixed dis-
`tances between children and the edges of the
`form, and so on. When Form is resized, it uses
`the constraint information to resize and reposition
`the children to maintain the assigned separations.
`Forms are useful for creating arbitarily complex
`interaction windows that exhibit ‘nice’ resizing
`behavior.
`
`Apple Ex. 1023, p. 7
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`- 8 -
`
`Core
`
`Simple
`
`Clock
`
`Load
`
`Composite
`
`Label
`
`Grip
`
`Text
`
`ScrollBar
`
`Command
`
`AsciiString
`
`AsciiFile
`
`Two-State
`
`Toggle
`
`Shell
`
`Box
`
`Constraint
`
`Popup
`
`Radio
`
`Form
`
`Paned
`
`Dialog
`
`VPaned
`
`Figure 2
`
`Apple Ex. 1023, p. 8
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`- 9 -
`
`Example
`
`Figure 3 shows a variety of composite and
`simple widgets instantiated in a single trivial
`application. The outermost widget is a VPaned
`(inside a Shell) which, in turn, contains several
`other composite and simple widgets. The small
`solid boxes are Grips which allow the user to
`move the attached pane boundary up or down,
`forcing the associated widgets to be resized.
`
`The uppermost pane of the VPaned is a
`Command button marked "quit". Appropriately,
`when the user clicks on this button, the applica-
`tion exits. The pane below this is a Label.
`
`The third pane is a Dialog containing a
`Label "I am a dialog form"; an AsciiString text
`field with an initial value; and a Command button
`marked "ok". The next pane is a Box containing
`a Label marked "label" and a Command button
`marked "command". The Clock and Load wid-
`gets form the next two panes.
`
`The seventh pane is another Box with an
`AsciiString widget and a Scrollbar. The last pane
`in figure 3 is an AsciiFile widget displaying
`/etc/motd.
`
`The application that instantiated this entire
`hierarchy is less than 200 lines of C source,
`including four callback procedures.
`
`Creating New Widgets
`
`Small changes to existing widgets can be
`made through the general facilities of the resource
`and translation managers. With these managers,
`one can make changes to color, font, key bind-
`ings, and the such. Many changes that would
`require a new interface object in other toolkits
`can be done through resource changes to the
`existing widgets in the X Toolkit.
`
`The simplest case of creating a new widget
`is to create a subclass of an existing widget. For
`example, if one wanted a command button with
`two lines of text, s/he might create a subclass of
`Command. Since all superclass structures are
`inherited, one would merely need to add an
`
`Figure 3
`
`additional string field to the instance structure and
`nothing to the class structure. Since there is no
`change in user interaction semantics, only the
`display method would need to be changed.
`In
`addition, code to allow the modification of the
`second text string would be required. All other
`code could be inherited. This new widget could
`then be incorporated in any composite widget that
`allowed buttons.
`
`Subclassing composite widgets is a little
`more work since new geometry managers may be
`desired. In general, the additional methods of a
`Composite widget tend to be complex and the
`new subclass will want to inherit as much as pos-
`sible.
`
`One potential ‘client’ of a widget that the
`implementor of the widget should keep in mind is
`the writer of
`the next widget. With a little
`Apple Ex. 1023, p. 9
` Apple v. Fintiv
`IPR2020-00019
`
`

`

`--
`
`--
`
`- 10 -
`
`thought, the designer of a new widget can decide
`which of the new methods added by the subclass
`should be declared as class variables, which as
`widget instance variables and which as in-line
`code.
`
`Class variables are the best way to export
`methods to potential future subclasses. By instal-
`ling a procedure pointer into a class variable, the
`new subclass has the option to easily inherit the
`old method or to define its own implementation.
`
`The developer of a family of widgets may
`find circumstances in which a small modification
`to a parent class would make a new subclass
`much easier to implement. From the application
`point-of-view, widget instance and widget class
`data structures are opaque types. The effect of an
`addition to one of these structures can be isolated
`to subclasses of
`the changed widget without
`breaking existing application code.
`
`A subclass is free to manipulate any of the
`widget instance variables defined by its super-
`classes. The subclass must be careful if it simul-
`taneously manipulates superclass instance data
`and inherits superclass methods that use the same
`data. At present, the only way to determine such
`side-effects is by examination of the superclass
`implementation(s). We hope to establish conven-
`tions in the future for documenting all the public
`and semi-public interfaces of a widget.
`
`Widgets Of The Future
`
`On our wish list are:
`
`read-only dial: posts a position between 0 and 1
`to a circular dial. Useful for indicating position
`or state.
`
`title bar: the mandatory title, horizontal lines,
`and close button. A convenience widget, like
`Dialog.
`
`menus: pull-down, pull-aside, and deck-of-cards
`menus.
`
`index pane: allows the user to select from a
`scrollable list of text strings. Useful for selecting
`topics or filenames.
`
`video label: handles the display of video from an
`
`external source inside a widg