wxPython before MainLoop

Bjoern Schliessmann usenet-mail-0306.20.chr0n0ss at spamgourmet.com
Tue Aug 14 16:21:49 EDT 2007


[david] wrote:

> Well yes, I have tried this app with native windows,
> and I know how to do it.

Then I wonder why you complained about concurrency problems (solved
by using a worker thread, or using wx.Yield) in the first place.
Windows has the same solutions, just as about every GUI framework.

http://msdn2.microsoft.com/en-us/library/69644x60(VS.80).aspx
 
> But if all wxPython can offer is a poor imitation of MFC,

>From what did you conclude this? As already stated, almost ALL GUI
toolkits available function in a similar way (using an event loop).
To say that every such toolkit was just an imitation of MFC is
quite childish, IMHO. 

Same niveau would be to say that all other cars are poor imitations
of Ford cars because they all have four wheels.

> I'm better off using MFC aren't I? 

That depends on your demands. If you don't want it cross platform
you may be right, especially if you require very special Windows
features.

> And too all those people who wrote back to insist
> that users MUST explicitly build a multi-threaded
> framework for wxPython:

Could you please cite one posting where this is claimed? I can't
find this claim.

> It's supposed to already be a framework :~)

wxWidgets _has_ cross-platform threads implemented on its own:

http://www.wxwidgets.org/manuals/stable/wx_wxthread.html#wxthread

It has just been dropped from wxPython because cross-platform
threads are already part of the Python library. C++, the basis for
wxWidgets, has no multithreading support in STL.

Regards,


Björn

-- 
BOFH excuse #61:

not approved by the FCC




More information about the Python-list mailing list