source: trunk/essentials/dev-lang/python/Doc/mac/libframework.tex@ 3315

\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.

Work on the \module{FrameWork} has pretty much stopped, now that
\module{PyObjC} is available for full Cocoa access from Python, 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 its dialog support is minimal and
that its 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 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