The hush library is meant to give flexible access to a window programming toolkit and possibly multiple embedded interpreters. Moreover, its design is based on principles of object-oriented software development as outlined in A. Eliëns -- Principles of Object-Oriented Software Development, Addison-Wesley (1995).
The library originated as a C++ API to Tcl/Tk. It is sometimes referred to as 'the' C++ API to Tcl/Tk. Instead we, the developers of hush, would like to see it as a minimal set of classes for hypermedia programming, of which the interface to Tcl/Tk is only a part. The core set of basic classes is gradually becoming stable. These classes are based on what we, The Hush Development Team, consider to be more or less basic concepts, as indicated below. A discussion of design issues can be found in issues(2). There are a number of extensions built on these concepts, see extern(2). Currently, we are using and developing version 2.0 and beyond. See changes(2) for a summary of the difference with the 1.x versions. Information on technical issues related to hush may be found in help(1). For platform specific information see News from the Portmaster.
The basic concepts and their corresponding classes are listed below:
session(4) -- to manage (parts of) the application kit(4) -- to provide access to underlying system handler(4) -- to bind C++ functionality to events event(4) -- stores information concerning user actions or system events widget(4) -- to display information on a screen item(4) -- represents an element of a widgetAll these classes, are needed by even the most casual user of hush. The binding class described in bind(2) is for more advanced users only. Read the respective manual pages for a more detailed description of the classes.
In addition, hush offers a number of convenience support classes, or foundation classes as they are called in the other empire.
iter(4) -- abstract iteration class string(4) -- (hush) string manipulation list(4) -- a (convenience) list class dictionary(4) -- dictionary class, based on Tcl hashtable
These manual pages describe the hush library classes. Hush is meant to be simple, but experience has shown that its simplicity may give it the appearence of complexity. Please read the documentation as given in Hush -- a C++ API for Tcl/Tk and look at the example programs before complaining about the complexity of hush. More advanced users wiil profit from the additional information given in The Hush Cookbook (when available). Diehards will not be satisfied until they had a look at The DejaVu Codebook (which is in production).
For the average user only a basic knowledge of C++ is required. One needs to know how to define classes and how to employ inheritance to define a derived class. In particular many classes in a hush application will either be derived from a handler class or from a widget class. The Hush Cookbook will give examples of the preferred style of using hush. System level hush programmers need to have a more detailed knowledge of the idioms applied in the realization of the hush library and its extensions.
As you have noticed, we distinguish between three categories or levels of programming, (1) average or casual users, (2) advanced users, and (3) system level hush programmers. Unfortunately, these distictions are not completely clear cut. However, one can say that whoever wishes to contribute to the hush environment must take the perspective of a system level programmer and act accordingly, in terms of styles and idioms.
The hush library does provide high level classes corresponding to the basic concepts mentioned. However, extensive use is made of the handle/body idiom in order to realize the flexibility needed for implementing the envisaged functionality. Rumors had it that hush is a quick hack. Even if that may have been true for elements of hush in particular stages of its development, this is no longer true for the major part of hush. See papers/patterns.
The hush library is organized around a limited number of (semi) abstract interface classes and is realized in a corresponding set of implementation classes employing the handle body idiom, virtual self reference and dynamic role switching. The average user however needs to have NO knowledge of any of these techniques.
Every class in hush is derived from the handler class to allow for access via a script language. To some extent this may lead to a situation that programmers complain that all they have to do is to define handler classes. To the extent that this is true, the quality of the code is then still dependent on the design of the various handler classes and their relations. Needless to say, on any level one can practice the art of hush programming.
The hush library allows for a very compact style of programming. Moreover, the interplay between script programming and C++ programming allows for a wide range of styles of development, from rapid (and dirty) prototyping to slow, but more robust class development. Since style is to a high degree individual, we decided to be not too pedantic about style, that is to allow for multiple solutions in case there is a choice. For example, the decision whether to declare an external handler or to declare a derived widget class to be its own handler is entirely up to the user. In other words, hush is meant to provide enabling technology and not as a restrictive environment. Nevertheless, we have tried to indicate a preferred style and a preferred method of developing for example wigdet classes in The Widget Cookbook.
Since code inspection is (still) one of the most effective means for verifying program correctness, the hush environment provides support for literate programming of which you might already have seen an example in the The Widget Cookbook. Our plan is to make a fully documented version of the hush source code and its extensions. Tools for literate programming include the ones described in cc-t(8), ht-ml(8). and html-latex(8). See literate(8) for style guidelines. With the tools described in oolex(1) and ooyacc(1), and in the future possibly others, you may extend the facilities provided by hush according to your needs.
There are still a number of features in hush undocumented, such as ... Well, find out for yourself, but don't rely on them. These features may be eliminated from the next version.
One particularly interesting (collection of) undocumented feature(s) is the event class. If you look at the code in <hush/api/event.h> you see that event actually has a very fat interface. Moreover it is derived from a handler, that has a function dispatch that takes an event as a parameter. One of the reasons is historic, this is simply the way hush has been developed. But apart from that, another reason is that the event class is also used in the discrete event simulation library sim (see event(6)). The sim library is closely integrated with hush and hence this particular realization of the event class provided a nice solution to avoiding a clash without introducing silly names such as simevent.
This solution for the event class proceeds from the assumption that the perspective from which the programmer looks at the event class will suffficiently guide the programmers behavior. Hence, the documentation needs only be adequate for one particular perspective. However, see issues(2).
There has been an extensive discussion in our group whether this situation is acceptable. As a compromise, we have adopted a solution that allows you to employ (the default) implicit dispatching as described in the original documentation (letting you believe the world consists of simple Tcl and X events only) or to employ explicit dispatching. This solution however employs pseudo-event object classes, which do not have an actual relation with the actual event class. This raises ethical questions. Can we let the user think that there is a relation between classes when there is none? Or, reversely, can we let the user think that there is no dependency when there is one, but one which is more or less hidden? Must we allow the user to look in the include files? See issues(2).
It is our firm conviction hat garbage collection should be supported by the language environment, as the developers of Java have realized. In C++ this is unfortunately not the case. Nevertheless, the hush library is becoming increasingly strict in collecting garbage. It may clean up itself one day. Many classes do provide a register method that allows the user to declare which (component) objects must be deleted when cleaning up. In most cases you do not have to be very strict in cleaning up obsolete objects, except when resource management (such as occupying the audio device) is involved. A hush programmer should never, or only very rarely, delete an object explicitly. Rather, one must register each newly created object to a (handler) object that provides the most suitable scope. For example some objects live as long as a session, whereas for other objects the widget they belong to is a more suitable scope. See garbage(4) and handler(4).
The hush library has been developed under Solaris on a Sun Sparc workstation. However, also a version for MS-Windows 3.1/95/NT is available, including some of the extensions such as sim(1). We strive for full source code portability of hush between platforms. However this excludes (some of the) extensions. Also, an excessive use of the kit::eval function may hinder portability.
|
Hush Online Technology
hush@cs.vu.nl
09/24/99 |
|
|