Steven Palm
2003-12-03 16:19:35 UTC
A thousand curses on me for not using the mail-list before I filed this
as a bug, but I have no time machine so apologies will have to do.
Here is my issue:
Maybe this something nobody has interest in, but I am using wxWindows
for other programs on MacOSX and I required the latest CVS version
(2.5.x) to make them work.
So, in trying to get bitpim to work with that version of
wxWindows/wxPython I am running into a few problems, and it all appears
to be based on this note from the migration notes file in wxPython:
"The import-startup-bootstrap process employed by wxPython was changed
such that wxWindows and the underlying gui toolkit are not initialized
until the wx.App object is created (but before wx.App.OnInit is
called.) This was required because of some changes that were made to
the C++ wxApp class.
There are both benefits and potential problems with this change. The
benefits are that you can import wxPython without requiring access to a
GUI (for checking version numbers, etc.) and that in a multi-threaded
environment the thread that creates the app object will now be the GUI
thread instead of the one that imports wxPython. Some potential
problems are that the C++ side of the "stock-objects" (wx.BLUE_PEN,
wx.TheColourDatabase, etc.) are not initialized until the wx.App object
is created, so you should not use them until after you have created
your wx.App object. (In fact, until I find a better solution trying to
use one of the stock objects before the app is created will probably
result in a crash.)
Also, you will probably not be able to do any kind of GUI or bitmap
operation unless you first have created an app object, (even on Windows
where most anything was possible before.)"
Indeed, this is the case, becuase the calendarcontrol.py module is
causing a segfault when it is imported due to the following:
class CalendarCellAttributes:
def __init__(self):
# Set some defaults
self.cellbackground=wxTheBrushList.FindOrCreateBrush(wx
Colour(230,255,255), wxSOLID)
.
.
.
This happens even when trying to run the calendarcontrol.py module
standalone. However, when running standalone, if you create the wxApp
instance at the top of the module, it doesn't crash which is in line
with the notes posted above.
I am just learning Python, and don't know enough yet to find a
workaround for this issue. Is there any interest in making this forward
compatible with the upcoming 2.5.x release of wxPython?? It shouldn't
affect it's ability to run with 2.4.x at all.
Thanks!
-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--
as a bug, but I have no time machine so apologies will have to do.
Here is my issue:
Maybe this something nobody has interest in, but I am using wxWindows
for other programs on MacOSX and I required the latest CVS version
(2.5.x) to make them work.
So, in trying to get bitpim to work with that version of
wxWindows/wxPython I am running into a few problems, and it all appears
to be based on this note from the migration notes file in wxPython:
"The import-startup-bootstrap process employed by wxPython was changed
such that wxWindows and the underlying gui toolkit are not initialized
until the wx.App object is created (but before wx.App.OnInit is
called.) This was required because of some changes that were made to
the C++ wxApp class.
There are both benefits and potential problems with this change. The
benefits are that you can import wxPython without requiring access to a
GUI (for checking version numbers, etc.) and that in a multi-threaded
environment the thread that creates the app object will now be the GUI
thread instead of the one that imports wxPython. Some potential
problems are that the C++ side of the "stock-objects" (wx.BLUE_PEN,
wx.TheColourDatabase, etc.) are not initialized until the wx.App object
is created, so you should not use them until after you have created
your wx.App object. (In fact, until I find a better solution trying to
use one of the stock objects before the app is created will probably
result in a crash.)
Also, you will probably not be able to do any kind of GUI or bitmap
operation unless you first have created an app object, (even on Windows
where most anything was possible before.)"
Indeed, this is the case, becuase the calendarcontrol.py module is
causing a segfault when it is imported due to the following:
class CalendarCellAttributes:
def __init__(self):
# Set some defaults
self.cellbackground=wxTheBrushList.FindOrCreateBrush(wx
Colour(230,255,255), wxSOLID)
.
.
.
This happens even when trying to run the calendarcontrol.py module
standalone. However, when running standalone, if you create the wxApp
instance at the top of the module, it doesn't crash which is in line
with the notes posted above.
I am just learning Python, and don't know enough yet to find a
workaround for this issue. Is there any interest in making this forward
compatible with the upcoming 2.5.x release of wxPython?? It shouldn't
affect it's ability to run with 2.4.x at all.
Thanks!
-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--