66 lines
3.5 KiB
HTML
66 lines
3.5 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html><head><title>PyGUI - Overview</title>
|
|
|
|
<meta name="GENERATOR" content="Mozilla/3.01Gold (X11; I; SunOS 5.6 sun4u) [Netscape]"></head>
|
|
|
|
<body>
|
|
<p><!-- Changed by: Greg Ewing, 11-Dec-1997 --></p>
|
|
<h1>Overview of the PyGUI Framework</h1>
|
|
<p>This section briefly describes the main classes making up the PyGUI application
|
|
framework and how they interact.</p>
|
|
<h2>Application class</h2>
|
|
<p>There is exactly one Application object which looks after everything that
|
|
is global to the application. If your application is very simple, you may
|
|
not even need to know about the Application class - an instance of it will
|
|
be created automatically when needed. If you want to make use of the Document-View
|
|
architecture, however, you will probably want to define a subclass of Application
|
|
and add your own code to it.</p>
|
|
<h2>Document class</h2>
|
|
<p>A Document object represents an application data structure which
|
|
can be stored in a file. A Document is also a Model so that it can have
|
|
Views attached to it (see below). If the data structure is simple, it could
|
|
be contained entirely in the Document object. A more complex data structure
|
|
might be composed of many objects, with a Document object at the head. Some
|
|
or all of these sub-objects may be Models so that Views can be attached to
|
|
parts of the data structure.</p>
|
|
<h2>Window and Component classes</h2>
|
|
<p>A Window represents a top-level window on the screen. Windows serve
|
|
as containers for Components, which are all the usual user interface widgets
|
|
such as buttons, scroll bars, text fields, etc. Some kinds of Components
|
|
are also Containers. A Container can contain other Components and clip them to its
|
|
boundary. Window and View, for example, are subclasses of Container.</p>
|
|
<h2>View and Model classes</h2>
|
|
<p>A View is a general-purpose Component for displaying graphics and
|
|
handling input events. A View can be associated with a Model representing
|
|
the data structure that it is to display. There can be many Views attached
|
|
to each Model, and when the Model is changed, all of its Views are notified
|
|
so that they can update themselves.</p>
|
|
<h2>Ownership hierarchy</h2>
|
|
<p>There are ownership relationships between Application, Document, Window
|
|
and Component objects. The Application is at the top of the hierarchy, and
|
|
owns all of the Documents. Each Document can own some number of Windows,
|
|
each Window owns all of its contained Components, those Components which are Containers own all their contained Components, and so forth. There can also be
|
|
Windows that do not belong to a Document and are owned directly by the
|
|
Application.</p>
|
|
<p>The ownership hierarchy serves two purposes. It defines a path for handling
|
|
events (see <a href="event_handling.html">Event Handling</a>), and
|
|
it allows a Document to be closed when all the Windows belonging to it have
|
|
been closed.</p>
|
|
<p>Figure 1 below illustrates the ownership relationships, and Figure 2 shows
|
|
some examples of how View-Model relationships might be set up.</p>
|
|
<p> </p>
|
|
<hr width="100%"> <p></p>
|
|
<p align="center"><img src="ownership.jpg" alt="" height="648" width="576">
|
|
</p>
|
|
<center> <p><b>Figure 1</b> </p>
|
|
<hr width="100%"> <p></p>
|
|
</center>
|
|
<center> <p><img src="view-model.jpg" alt="" height="648" width="576">
|
|
</p>
|
|
</center>
|
|
<center> <p><b>Figure 2</b> </p>
|
|
<hr width="100%"> <p></p>
|
|
</center>
|
|
<br>
|
|
<br>
|
|
</body></html> |