[wxPython] wxWindows Book

Gary_Young · March 8, 2002, 9:32pm

Kevin,

Yes, the silence is deafening about the document view architecture. I think it needs to be done and since I am writing a book on a related topic I may as well do it.

As much as this seems contradictory, I do agree with you on doing it in Python if you can, but there is also the other school of thinking that needs to be addressed. People become acclimated to working in a framework and they like to stay within that framework. A classic case in point is the Microsoft Foundation Classes. Personally I like the CString class in MFC more than the standard C++ string class. People that program on wxWindows and use the wxString class may prefer this also for the same reason. (However the rules do change in Python and people should adopt the standard Python data types - I agree wholeheartedly.)

As far as the other classes to port, the Interprocess Communication and Streams classes would be an interesting exercise. I am open to suggestions from anyone on the value of classes outside of the mainstream wxWindows GUI classes being ported. This may save me some work.

Regards,
Gary

···

-----Original Message-----
From: Kevin Altis [mailto:altis@semi-retired.com]
Sent: Friday, March 08, 2002 9:31 PM
To: wxpython-users@lists.wxwindows.org
Subject: RE: [wxPython] wxWindows Book

From: Gary Young

There are a few classes that are not stricly GUI in nature.
Also, I had earlier alluded to wrapping some of the wxWindows
classes (starting with document/view which are GUI in nature) and
some other people I know have talked about wrapping a
significant portion of the wxWindows framework.

Wrapping doc/view probably makes sense, but when I enquired on wx-dev and
wx-users in the past whether anyone actually used the wxWindows doc/view
framework the silence was deafening.

However, at this stage, it is essentially a GUI framework. But it
has a lot of potential to be extended and would make it much
easier for the non-C++ programmer to use in performing more
complex programming tasks. But you are correct, it is very
convenient for doing GUIs and that is it's major purpose at this time.

This part I don't understand from the point of a Python programmer. It seems
to only make sense if you wanted to program in a variety of languages, but
always programs to the wxWindows API for non-GUI classes. As has been stated
on this list recently and in the past, most of the wxWindows classes which
aren't wrapped in wxPython are not wrapped because there is a more
convenient or better library, class, method, etc. already in Python. The
rule of thumb is if Python already does it, don't wrap a wxWindows class for
that functionality.

Are there specific wxWindows classes that you have in mind that Python
doesn't handle?

ka

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwindows.org
http://lists.wxwindows.org/mailman/listinfo/wxpython-users

Robin · March 8, 2002, 9:56pm

Yes, the silence is deafening about the document view
architecture. I think it needs to be done and since
I am writing a book on a related topic I may as well
do it.

As much as this seems contradictory, I do agree with
you on doing it in Python if you can, but there is
also the other school of thinking that needs to be
addressed. People become acclimated to working in a
framework and they like to stay within that framework.

I would like to see Doc/View implemented in Python *AND* be (at least
mostly) compatible with the documented API of the C++ Doc/View. You could
easily spend a chapter or two of the book ("Extending wxPython with Python"
or something) walking thought the development of that version of Doc/View.

As far as the other classes to port, the Interprocess
Communication and Streams classes would be an interesting
exercise. I am open to suggestions from anyone on the
value of classes outside of the mainstream wxWindows GUI
classes being ported. This may save me some work.

Streams are partially done now. (Enough that a Python file-like object can
masqarade as a wxInputStream for loading wxImages and etc.) I've also
thought about doing wxSocket and related classes since there is some nice
integration with the wx event system. If it is done then I would like a
wrapped wxSocket to be able to be passed to any methods/functions that
expect a Python socket object. It should be possible to wrap a socket
around a Python socket object too.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!