--- Python-Docs-2.4/./mac/libframework.tex	2003-09-23 00:27:11.000000000 +0900
+++ Python-Docs-2.5/./mac/libframework.tex	2005-06-19 02:54:13.000000000 +0900
@@ -15,7 +15,8 @@
 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
+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
@@ -28,8 +29,8 @@
 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.
+that shouldn't be difficult), that its dialog support is minimal and
+that its control/toolbar support is non-existent.
 \end{quotation}
 
 
@@ -151,7 +152,7 @@
 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
+(such as FrameWork itself). By default \var{async_dispatch} will immediately
 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.
