Actually, MFC's View class is one of many subclasses of Window, and other
(non-View) Window subclasses play major roles in MFC programming. OWL
uses multiple inheritance to make its view-that-is-also-a-window, so
(unlike MFC) views that are not also windows are possible. Or you can keep
the View and Window as distinct objects and delegate back and forth to
handle all the view and window responsibilities from either.
>The reason I am bringing this up is that a Python GUI model is going
>to have to adopt one approach or the other, and I am leaning toward
>the document/view model. The main reason is that Microsoft claims
>that it offers a higher level of abstraction which enables MFC code
>to run on a Mac.
This Microsoft claim is mostly hot air. The Mac and UNIX portability
libraries basically emulate the Windows API. MFC still helps when
porting, but by smoothing over the differences between the 32-bit and
16-bit versions of the Windows API. The Mac library is a big ugly pig,
which is (in part) why MS-Word 6 on the Mac is unusable.
Document/View is a useful pattern, in its place, but I wouldn't force everyone
who wants a Window to use Document/View to get it. I don't really know Python;
if it has multiple inheritance or easy delegation, I'd say make Window and View
distinct classes.
Paul A. Perkins
perkinsp@nando.net
(All things are Fire)