From 272e57235cd60a2e65ac8258d96a02eb3939b687 Mon Sep 17 00:00:00 2001 From: marha Date: Fri, 25 Mar 2011 10:41:05 +0000 Subject: git update until 25 Mar 2011 xserver fontconfig glproto libXau libXft libXmu libfontenc libxcb mesa mkfontscale pixman randrproto xkeyboard-config xtrans xwininfo updated following packages: xproto-7.0.21 xineramaproto-1.2.1 libXt-1.1.1 libxkbfile-1.0.7 libXpm-3.5.9 libXfont-1.4.3 libXaw-1.0.9 bdftopcf-1.0.3 encodings-1.0.4 fixesproto-5.0 font-adobe-100dpi-1.0.3 font-adobe-75dpi-1.0.3 font-adobe-utopia-100dpi-1.0.4 font-adobe-utopia-75dpi-1.0.4 font-adobe-utopia-type1-1.0.4 font-alias-1.0.3 font-arabic-misc-1.0.3 font-bh-100dpi-1.0.3 font-bh-75dpi-1.0.3 font-bh-lucidatypewriter-100dpi-1.0.3 font-bh-lucidatypewriter-75dpi-1.0.3 font-bh-ttf-1.0.3 font-bh-type1-1.0.3 font-bitstream-100dpi-1.0.3 font-bitstream-75dpi-1.0.3 font-bitstream-speedo-1.0.2 font-bitstream-type1-1.0.3 font-cronyx-cyrillic-1.0.3 font-cursor-misc-1.0.3 font-daewoo-misc-1.0.3 font-dec-misc-1.0.3 font-ibm-type1-1.0.3 font-isas-misc-1.0.3 font-jis-misc-1.0.3 font-micro-misc-1.0.3 font-misc-cyrillic-1.0.3 font-misc-ethiopic-1.0.3 font-misc-meltho-1.0.3 font-misc-misc-1.1.2 font-mutt-misc-1.0.3 font-schumacher-misc-1.1.2 font-screen-cyrillic-1.0.4 font-sony-misc-1.0.3 font-sun-misc-1.0.3 font-util-1.2.0 font-winitzki-cyrillic-1.0.3 font-xfree86-type1-1.0.4 --- libXaw/spec/CH7.intro | 99 --------------------------------------------------- 1 file changed, 99 deletions(-) delete mode 100644 libXaw/spec/CH7.intro (limited to 'libXaw/spec/CH7.intro') diff --git a/libXaw/spec/CH7.intro b/libXaw/spec/CH7.intro deleted file mode 100644 index 7aaa1896b..000000000 --- a/libXaw/spec/CH7.intro +++ /dev/null @@ -1,99 +0,0 @@ -.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 -- cgit v1.2.3