mirror of
https://github.com/python/cpython.git
synced 2024-11-28 16:45:42 +01:00
658865c370
Added summary of the strengths and weaknesses of the FrameWork module and fixed some typos.
314 lines
12 KiB
TeX
314 lines
12 KiB
TeX
\section{\module{FrameWork} ---
|
|
Interactive application framework}
|
|
|
|
\declaremodule{standard}{FrameWork}
|
|
\platform{Mac}
|
|
\modulesynopsis{Interactive application framework.}
|
|
|
|
|
|
The \module{FrameWork} module contains classes that together provide a
|
|
framework for an interactive Macintosh application. The programmer
|
|
builds an application by creating subclasses that override various
|
|
methods of the bases classes, thereby implementing the functionality
|
|
wanted. Overriding functionality can often be done on various
|
|
different levels, i.e. to handle clicks in a single dialog window in a
|
|
non-standard way it is not necessary to override the complete event
|
|
handling.
|
|
|
|
The \module{FrameWork} is still very much work-in-progress, and the
|
|
documentation describes only the most important functionality, and not
|
|
in the most logical manner at that. Examine the source or the examples
|
|
for more details. The following are some comments posted on the
|
|
MacPython newsgroup about the strengths and limitations of
|
|
\module{FrameWork}:
|
|
|
|
\begin{quotation}
|
|
The strong point of \module{FrameWork} is that it allows you to break
|
|
into the control-flow at many different places. \refmodule{W}, for
|
|
instance, uses a different way to enable/disable menus and that plugs
|
|
right in leaving the rest intact. The weak points of
|
|
\module{FrameWork} are that it has no abstract command interface (but
|
|
that shouldn't be difficult), that it's dialog support is minimal and
|
|
that it's control/toolbar support is non-existent.
|
|
\end{quotation}
|
|
|
|
|
|
The \module{FrameWork} module defines the following functions:
|
|
|
|
|
|
\begin{funcdesc}{Application}{}
|
|
An object representing the complete application. See below for a
|
|
description of the methods. The default \method{__init__()} routine
|
|
creates an empty window dictionary and a menu bar with an apple menu.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{MenuBar}{}
|
|
An object representing the menubar. This object is usually not created
|
|
by the user.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{Menu}{bar, title\optional{, after}}
|
|
An object representing a menu. Upon creation you pass the
|
|
\code{MenuBar} the menu appears in, the \var{title} string and a
|
|
position (1-based) \var{after} where the menu should appear (default:
|
|
at the end).
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{MenuItem}{menu, title\optional{, shortcut, callback}}
|
|
Create a menu item object. The arguments are the menu to create, the
|
|
item item title string and optionally the keyboard shortcut
|
|
and a callback routine. The callback is called with the arguments
|
|
menu-id, item number within menu (1-based), current front window and
|
|
the event record.
|
|
|
|
Instead of a callable object the callback can also be a string. In
|
|
this case menu selection causes the lookup of a method in the topmost
|
|
window and the application. The method name is the callback string
|
|
with \code{'domenu_'} prepended.
|
|
|
|
Calling the \code{MenuBar} \method{fixmenudimstate()} method sets the
|
|
correct dimming for all menu items based on the current front window.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{Separator}{menu}
|
|
Add a separator to the end of a menu.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{SubMenu}{menu, label}
|
|
Create a submenu named \var{label} under menu \var{menu}. The menu
|
|
object is returned.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{Window}{parent}
|
|
Creates a (modeless) window. \var{Parent} is the application object to
|
|
which the window belongs. The window is not displayed until later.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{DialogWindow}{parent}
|
|
Creates a modeless dialog window.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{windowbounds}{width, height}
|
|
Return a \code{(\var{left}, \var{top}, \var{right}, \var{bottom})}
|
|
tuple suitable for creation of a window of given width and height. The
|
|
window will be staggered with respect to previous windows, and an
|
|
attempt is made to keep the whole window on-screen. However, the window will
|
|
however always be the exact size given, so parts may be offscreen.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{setwatchcursor}{}
|
|
Set the mouse cursor to a watch.
|
|
\end{funcdesc}
|
|
|
|
\begin{funcdesc}{setarrowcursor}{}
|
|
Set the mouse cursor to an arrow.
|
|
\end{funcdesc}
|
|
|
|
|
|
\subsection{Application Objects \label{application-objects}}
|
|
|
|
Application objects have the following methods, among others:
|
|
|
|
|
|
\begin{methoddesc}[Application]{makeusermenus}{}
|
|
Override this method if you need menus in your application. Append the
|
|
menus to the attribute \member{menubar}.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Application]{getabouttext}{}
|
|
Override this method to return a text string describing your
|
|
application. Alternatively, override the \method{do_about()} method
|
|
for more elaborate ``about'' messages.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Application]{mainloop}{\optional{mask\optional{, wait}}}
|
|
This routine is the main event loop, call it to set your application
|
|
rolling. \var{Mask} is the mask of events you want to handle,
|
|
\var{wait} is the number of ticks you want to leave to other
|
|
concurrent application (default 0, which is probably not a good
|
|
idea). While raising \var{self} to exit the mainloop is still
|
|
supported it is not recommended: call \code{self._quit()} instead.
|
|
|
|
The event loop is split into many small parts, each of which can be
|
|
overridden. The default methods take care of dispatching events to
|
|
windows and dialogs, handling drags and resizes, Apple Events, events
|
|
for non-FrameWork windows, etc.
|
|
|
|
In general, all event handlers should return \code{1} if the event is fully
|
|
handled and \code{0} otherwise (because the front window was not a FrameWork
|
|
window, for instance). This is needed so that update events and such
|
|
can be passed on to other windows like the Sioux console window.
|
|
Calling \function{MacOS.HandleEvent()} is not allowed within
|
|
\var{our_dispatch} or its callees, since this may result in an
|
|
infinite loop if the code is called through the Python inner-loop
|
|
event handler.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Application]{asyncevents}{onoff}
|
|
Call this method with a nonzero parameter to enable
|
|
asynchronous event handling. This will tell the inner interpreter loop
|
|
to call the application event handler \var{async_dispatch} whenever events
|
|
are available. This will cause FrameWork window updates and the user
|
|
interface to remain working during long computations, but will slow the
|
|
interpreter down and may cause surprising results in non-reentrant code
|
|
(such as FrameWork itself). By default \var{async_dispatch} will immedeately
|
|
call \var{our_dispatch} but you may override this to handle only certain
|
|
events asynchronously. Events you do not handle will be passed to Sioux
|
|
and such.
|
|
|
|
The old on/off value is returned.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Application]{_quit}{}
|
|
Terminate the running \method{mainloop()} call at the next convenient
|
|
moment.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Application]{do_char}{c, event}
|
|
The user typed character \var{c}. The complete details of the event
|
|
can be found in the \var{event} structure. This method can also be
|
|
provided in a \code{Window} object, which overrides the
|
|
application-wide handler if the window is frontmost.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Application]{do_dialogevent}{event}
|
|
Called early in the event loop to handle modeless dialog events. The
|
|
default method simply dispatches the event to the relevant dialog (not
|
|
through the the \code{DialogWindow} object involved). Override if you
|
|
need special handling of dialog events (keyboard shortcuts, etc).
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Application]{idle}{event}
|
|
Called by the main event loop when no events are available. The
|
|
null-event is passed (so you can look at mouse position, etc).
|
|
\end{methoddesc}
|
|
|
|
|
|
\subsection{Window Objects \label{window-objects}}
|
|
|
|
Window objects have the following methods, among others:
|
|
|
|
\setindexsubitem{(Window method)}
|
|
|
|
\begin{methoddesc}[Window]{open}{}
|
|
Override this method to open a window. Store the MacOS window-id in
|
|
\member{self.wid} and call the \method{do_postopen()} method to
|
|
register the window with the parent application.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Window]{close}{}
|
|
Override this method to do any special processing on window
|
|
close. Call the \method{do_postclose()} method to cleanup the parent
|
|
state.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Window]{do_postresize}{width, height, macoswindowid}
|
|
Called after the window is resized. Override if more needs to be done
|
|
than calling \code{InvalRect}.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Window]{do_contentclick}{local, modifiers, event}
|
|
The user clicked in the content part of a window. The arguments are
|
|
the coordinates (window-relative), the key modifiers and the raw
|
|
event.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[Window]{do_update}{macoswindowid, event}
|
|
An update event for the window was received. Redraw the window.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}{do_activate}{activate, event}
|
|
The window was activated (\code{\var{activate} == 1}) or deactivated
|
|
(\code{\var{activate} == 0}). Handle things like focus highlighting,
|
|
etc.
|
|
\end{methoddesc}
|
|
|
|
|
|
\subsection{ControlsWindow Object \label{controlswindow-object}}
|
|
|
|
ControlsWindow objects have the following methods besides those of
|
|
\code{Window} objects:
|
|
|
|
|
|
\begin{methoddesc}[ControlsWindow]{do_controlhit}{window, control,
|
|
pcode, event}
|
|
Part \var{pcode} of control \var{control} was hit by the
|
|
user. Tracking and such has already been taken care of.
|
|
\end{methoddesc}
|
|
|
|
|
|
\subsection{ScrolledWindow Object \label{scrolledwindow-object}}
|
|
|
|
ScrolledWindow objects are ControlsWindow objects with the following
|
|
extra methods:
|
|
|
|
|
|
\begin{methoddesc}[ScrolledWindow]{scrollbars}{\optional{wantx\optional{,
|
|
wanty}}}
|
|
Create (or destroy) horizontal and vertical scrollbars. The arguments
|
|
specify which you want (default: both). The scrollbars always have
|
|
minimum \code{0} and maximum \code{32767}.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[ScrolledWindow]{getscrollbarvalues}{}
|
|
You must supply this method. It should return a tuple \code{(\var{x},
|
|
\var{y})} giving the current position of the scrollbars (between
|
|
\code{0} and \code{32767}). You can return \code{None} for either to
|
|
indicate the whole document is visible in that direction.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[ScrolledWindow]{updatescrollbars}{}
|
|
Call this method when the document has changed. It will call
|
|
\method{getscrollbarvalues()} and update the scrollbars.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[ScrolledWindow]{scrollbar_callback}{which, what, value}
|
|
Supplied by you and called after user interaction. \var{which} will
|
|
be \code{'x'} or \code{'y'}, \var{what} will be \code{'-'},
|
|
\code{'--'}, \code{'set'}, \code{'++'} or \code{'+'}. For
|
|
\code{'set'}, \var{value} will contain the new scrollbar position.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[ScrolledWindow]{scalebarvalues}{absmin, absmax,
|
|
curmin, curmax}
|
|
Auxiliary method to help you calculate values to return from
|
|
\method{getscrollbarvalues()}. You pass document minimum and maximum value
|
|
and topmost (leftmost) and bottommost (rightmost) visible values and
|
|
it returns the correct number or \code{None}.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[ScrolledWindow]{do_activate}{onoff, event}
|
|
Takes care of dimming/highlighting scrollbars when a window becomes
|
|
frontmost. If you override this method, call this one at the end of
|
|
your method.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[ScrolledWindow]{do_postresize}{width, height, window}
|
|
Moves scrollbars to the correct position. Call this method initially
|
|
if you override it.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[ScrolledWindow]{do_controlhit}{window, control,
|
|
pcode, event}
|
|
Handles scrollbar interaction. If you override it call this method
|
|
first, a nonzero return value indicates the hit was in the scrollbars
|
|
and has been handled.
|
|
\end{methoddesc}
|
|
|
|
|
|
\subsection{DialogWindow Objects \label{dialogwindow-objects}}
|
|
|
|
DialogWindow objects have the following methods besides those of
|
|
\code{Window} objects:
|
|
|
|
|
|
\begin{methoddesc}[DialogWindow]{open}{resid}
|
|
Create the dialog window, from the DLOG resource with id
|
|
\var{resid}. The dialog object is stored in \member{self.wid}.
|
|
\end{methoddesc}
|
|
|
|
\begin{methoddesc}[DialogWindow]{do_itemhit}{item, event}
|
|
Item number \var{item} was hit. You are responsible for redrawing
|
|
toggle buttons, etc.
|
|
\end{methoddesc}
|