Re: Seeking alternative to wxPython

> When I embarked on my programming project, I had hoped that
> my choice of
> wxPython would make it possible for me to run my program
> without too much
> difficulty on Linux, Win XP, Win Mobile, and OSX, but so far
> I have not been
> able to get it to run reliably on even one platform, least of
> all winCE.  I
> had high hopes for the port recently announced by Ingmar
> Steen, but so far,
> at least, it suffers from the same problems that the earlier port had
> (although many other things are working better).  Even the
> version that runs
> on XP has problems that don't seem to be getting resolved.

If you are having problems with Windows XP, it would be brave to hope that
Windows CE would have *less* problems <wink>.

> I have seen references here to Pythonwin, but I am not
> familiar with it.  I
> gather that it contains the module win32gui and, if I
> understand correctly,
> that module provides an interface to the MFC routines for
> creating a GUI.

Pythonwin and the win32ui module are MFC wrappers, and I suspect you will
have some problems getting these to work on CE.  The win32gui module (poor
module names, I know...) wraps the native win32 GUI api and does not rely on
MFC at all.  As a result, it is fairly low-level, but is also less likely to
get in your way too much.

> I
> understand that wxPython uses native routines to actually draw the GUI
> elements, so if I am reasoning correctly it follows that
> wxPython is calling
> the same routines that I could call directly using win32gui.
> Thus, I should
> be able to do with win32gui anything that I am doing with
> wxPython

That is true to some extent - although the effort may be significantly more
than you expect.  I believe the widget set in wx is larger than Windows
itself provides - which would mean wx implements these widgets itself using
the 'lower-level' widgets (or even just the low-level drawing routines) as a
framework.  You theoretically could reimplement all such widgets using
win32gui - but depending on the widget, that would be very difficult.  In
some cases, win32gui may not be complete enough to do everything - it
doesn't cover *all* win32 GUI functions (but does cover the majority of the
useful ones)

> win32gui is not complete.  What I lose by using win32gui rather than
> wxPython is portability, but perhaps I would have better luck
> getting the
> program to run reliably on winCE.  Is this reasoning correct?

It depends on exactly what your program needs to do.  Without knowing why wx
fails on CE for you, I can't speculate if the same thing would be any easier
using win32gui.

> It looks as if the best documentation for Pythonwin is the
> book by Mark
> Hammond and Andy Robinson, but I note that it was published
> over 6 years
> ago.  Is it still sufficiently current to be useful? Does anyone know
> whether a new edition is scheduled to appear soon?

The book doesn't cover win32gui in any detail at all - it does cover
Pythonwin/win32ui in some detail, but that isn't what you want to use.  We
are starting work on a new edition this year, but that is unlikely to cover
win32gui in any detail - the point of win32gui is a thin wrapper around the
windows API, and the intent of the book is not to document that API.
Similarly, the documentation that does existing for Pythonwin/win32ui
doesn't attempt to be a tutorial in MFC programming - Microsoft already has
lots of documentation on that.

> Is there more current documentation somewhere?

As above, given it is a thin wrapper, the only Python relevant documentation
covers things like argument and return-value handling.  There will be no
attempt (by me) to write a tutorial on low-level win32 UI development.

> Does Python Programming on WIN32 do
> an adequate
> job of explaining how to build GUIs using win32gui, or do I need
> documentation for the relevant portion of MFC as well?

The latter.

> I hate the thought of rewriting my code again for a different
> GUI library.
> I was happy using Qt on a Sharp Zaurus running Linux, but when Sharp
> withdrew the Zaurus from the US market I could not find a suitable
> substitute.  The only alternative I can think of in my
> current dilemma is to
> try to fix the bugs in the wxPython port myself, but I doubt
> that I have the skill.

If you can't get a Windows XP version working the way you want, I suspect
you have a lot of work ahead of you to get a CE version working the way you
want.  If your only problem was that the CE port failed in some fundamental
way (eg, failed to load), then I expect it would be a much simpler thing to
fix.  I've no real wx experience though.

Sorry I can't offer more concrete advice, but I hope this helps anyway...

Mark