[wxpython-dev] OS X Cocoa wxPython available in trunk
Kevin Ollivier
Just a note to let anyone on Mac who's working off the trunk know that
I yesterday committed the OS X Cocoa bindings for wxPython. I've
actually been using and testing it for a couple weeks now, and it's
really shaping up. Stefan used a lot of the Core frameworks on Mac so
that almost everything but the native controls themselves are using
shared code, and he's also implemented a lot of methods in a way that
work both with the Carbon and Cocoa impl. (wxDC and wxGraphicsContext
code is almost 100% the same between Carbon and Cocoa, so there's
really a lot of shared code.)
In short, it's pretty far along overall, and we could really use some
help hammering out what's left. For those working on trunk, the only
change you should need to make when building is to add --with-
osx_cocoa to your configure line - the rest of the process should be
the same. Or you can just use the build-wxpython.py script, in the
wxPy root dir, like so:
build-wxpython.py --unicode --debug --osx_cocoa (--reswig)
--reswig should only be needed if you edit the SWIG bindings though.
Hopefully, we can have a binary release of it out soon for people to
play with!
Thanks,
Kevin
Robin Dunn
>
> Yea, I was able to get Editra started with only one change (not to use
> wx.NamedColour anymore)
You probably meant this the other way around, but for the record (and to
avoid panic) wx.NamedColour will still work, it was the alias without
the 'u' that was removed.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Kevin Ollivier
On Mar 11, 2009, at 9:54 PM, Cody Precord wrote:
> Hello,
>
> On Mar 11, 2009, at 12:20 AM, Kevin Ollivier wrote:
>
>> Hi all,
>>
>> Just a note to let anyone on Mac who's working off the trunk know
>> that I yesterday committed the OS X Cocoa bindings for wxPython.
>> I've actually been using and testing it for a couple weeks now, and
>> it's really shaping up. Stefan used a lot of the Core frameworks on
>> Mac so that almost everything but the native controls themselves
>> are using shared code, and he's also implemented a lot of methods
>> in a way that work both with the Carbon and Cocoa impl. (wxDC and
>> wxGraphicsContext code is almost 100% the same between Carbon and
>> Cocoa, so there's really a lot of shared code.)
>>
>> In short, it's pretty far along overall, and we could really use
>> some help hammering out what's left. For those working on trunk,
>> the only change you should need to make when building is to add --
>> with-osx_cocoa to your configure line - the rest of the process
>> should be the same. Or you can just use the build-wxpython.py
>> script, in the wxPy root dir, like so:
>>
>> build-wxpython.py --unicode --debug --osx_cocoa (--reswig)
>>
>> --reswig should only be needed if you edit the SWIG bindings though.
>>
>> Hopefully, we can have a binary release of it out soon for people
>> to play with!
>
> Tried building with the above command and got the following right
> when the wxPython part of the build started.
>
> WARNING: WXWIN not set in environment. Assuming '..'
> Preparing CORE...
> Preparing STC...
> Preparing GLCANVAS...
> Preparing GIZMOS...
> Traceback (most recent call last):
> File "./setup.py", line 681, in <module>
> [ '%s/_treelist.i' % location])
> File "/Users/codyprecord/Desktop/devel/wxWidgets/wxPython/
> config.py", line 411, in run_swig
> copy_file(py_file, package, update=not force, verbose=0)
> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/distutils/file_util.py", line 119, in copy_file
> "can't copy '%s': doesn't exist or not a regular file" % src
> distutils.errors.DistutilsFileError: can't copy 'contrib/gizmos/
> osx_cocoa/gizmos.py': doesn't exist or not a regular file
> ERROR: failed building wxPython.
>
> Which is quite correct as there is no 'contrib/gizmos/osx_cocoa'
> directory. Forgot to commit?
Me? No, never. There, uhm... must have been something wrong with your
SVN... yeah, that's it! try updating again, I see it there... ;-)
Thanks,
Kevin
>
> Cody
>
>
> _______________________________________________
> wxpython-dev mailing list
> wxpyth...@lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev
Robin Dunn
> Just out of curiosity are all the 'colour' aliases for all
> objects/methods/functions being removed as well? or is this just a
> special case.
I think I zapped all of them.
Cody Precord
On Mar 11, 2009, at 12:20 AM, Kevin Ollivier wrote:
Tried building with the above command and got the following right when
the wxPython part of the build started.
WARNING: WXWIN not set in environment. Assuming '..'
Preparing CORE...
Preparing STC...
Preparing GLCANVAS...
Preparing GIZMOS...
Traceback (most recent call last):
File "./setup.py", line 681, in <module>
[ '%s/_treelist.i' % location])
File "/Users/codyprecord/Desktop/devel/wxWidgets/wxPython/
config.py", line 411, in run_swig
copy_file(py_file, package, update=not force, verbose=0)
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/distutils/file_util.py", line 119, in copy_file
"can't copy '%s': doesn't exist or not a regular file" % src
distutils.errors.DistutilsFileError: can't copy 'contrib/gizmos/
osx_cocoa/gizmos.py': doesn't exist or not a regular file
ERROR: failed building wxPython.
Which is quite correct as there is no 'contrib/gizmos/osx_cocoa'
directory. Forgot to commit?
Cody
Kevin Ollivier
On Mar 12, 2009, at 6:46 PM, Cody Precord wrote:
> Hello,
>
> On Mar 12, 2009, at 12:13 AM, Kevin Ollivier wrote:
>
>>>
>>> Which is quite correct as there is no 'contrib/gizmos/osx_cocoa'
>>> directory. Forgot to commit?
>>
>> Me? No, never. There, uhm... must have been something wrong with
>> your SVN... yeah, that's it! try updating again, I see it
>> there... ;-)
>
> Oh you were right I updated and they were magically there ;)
>
> It runs fairly well on the tests I did. What kind of feedback are
> you looking for at this point because there are a fair number of
> obvious issues.
Anything at this point. Everyone has blind spots and over time it gets
hard to track what I have and haven't tested, so while some things
might be reminders, that's fine with me if you don't mind. :-)
> Here are a few (let me know if they would rather be sent to trac):
>
> 1) Sizers seem to behave differently and often items seem to
> overflow the right side of a sizer.
Could you be more specific? I've run into some best size problems
before, maybe we still have something in the tree.
> 2) Constant stream of warnings about memory leaks sent to console:
> 2009-03-12 20:22:03.222 Python[11739:613] ***
> _NSAutoreleaseNoPool(): Object 0x1919aea0 of class
> NSConcreteMutableData autoreleased with no pool in place - just
> leaking
> Stack: (0x9153973f 0x91445e32 0x92b03c61 0x1a44ec5 0x1a428b5
> 0x92b0329c 0x92b01d93 0x92b0212a 0x92b0212a 0x92b0212a 0x92b0212a
> 0x92b006e9 0x92b01543 0x92b0002b 0x92afcb4f 0x92a3d523 0x92a3d0d1
> 0x1a35275 0xbe7a29 0x3fadac 0x4846e1 0x48771d 0x484d9e 0x486b86
> 0x486b86 0x486b86 0x486b86 0x48771d 0x4878d1 0x4ab031 0x4ab3cb
> 0x4b8bbe)
Please file a ticket about this. Stefan has said it's harmless, and
I'm inclined to believe him, but I really want to stop seeing these
too. ;-)
> 3) ToolBars seem to initialize correctly but doesn't have any icons
> in it
Okay, do you know if it's related to #4 or not?
> 4) Many controls seem to cause the following error (not sure if its
> a 2.9 api change or a case of not implemented).
>
> File "ToolBar.py", line 201, in OnButton
> win = TestToolBar(self, self.log)
> File "ToolBar.py", line 132, in __init__
> size=(150,-1), style=wx.CB_DROPDOWN
> File "/Users/codyprecord/Desktop/devel/wxWidgets/wxPython/wx/
> _controls.py", line 590, in __init__
> _controls_.ComboBox_swiginit(self,_controls_.new_ComboBox(*args,
> **kwargs))
> wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed
> at /Users/codyprecord/Desktop/devel/wxWidgets/src/common/
> stockitem.cpp(202) in wxGetStockLabel(): invalid stock item ID
Well, this is bizarre... It looks like there are at least two
problems that have to occur to get to this point:
1) wxIsStockId(wx.NewId()) has to return true for that particular ID,
and
2) Even though wxIsStockId(wx.NewId()) returns true, wxGetStockLabel
does not accept that label
It's weird that a ComboBox would have empty labels in the first place,
though. Have to check into this more tomorrow.
> 5) In a RadioBox the radio button labels get cut off by 2-4 pixels
> on the right side.
Yeah, I see this too. Please file a ticket, I've been meaning to get
this but I guess if there's a ticket there's a chance Stefan will get
to it before I can. :-)
> 6) The Stock Help button shows a ? and also has the Help text
> overlapping it as well.
I'll try to take a look.
Many thanks for your help! I'm hoping to get a binary out to people
soon, as I think that while there's still a number of issues to
tackle, a lot of apps probably will startup and run, and can be tested
at least somewhat already.
Cody Precord
On Mar 13, 2009, at 12:24 AM, Kevin Ollivier wrote:
>
>
>> Here are a few (let me know if they would rather be sent to trac):
>>
>> 1) Sizers seem to behave differently and often items seem to
>> overflow the right side of a sizer.
>
> Could you be more specific? I've run into some best size problems
> before, maybe we still have something in the tree.
Best Size issues sound likely. For example if you run the wxpython
demo all the info pages "first tab in a particular demo" have the text/
html window not fully sized.
Also look at the platebutton demo the two panels with custom
backgrounds overflow the scroll bar on the right side (this could very
well be a paint issue instead of a sizer one).
Let me get back to you when I next have a chance to look at it more
carefully (maybe tonight).
>> 3) ToolBars seem to initialize correctly but doesn't have any icons
>> in it
>
> Okay, do you know if it's related to #4 or not?
No I don't think so. This was just with a plain tool bar that only
used regular tools in it (no controls). I will look more carefully to
see whats going on. I just tried to run Editra and the toolbar was
created and I didn't see any errors but it had no buttons on it.
>
>
>> 4) Many controls seem to cause the following error (not sure if its
>> a 2.9 api change or a case of not implemented).
>>
>> File "ToolBar.py", line 201, in OnButton
>> win = TestToolBar(self, self.log)
>> File "ToolBar.py", line 132, in __init__
>> size=(150,-1), style=wx.CB_DROPDOWN
>> File "/Users/codyprecord/Desktop/devel/wxWidgets/wxPython/wx/
>> _controls.py", line 590, in __init__
>> _controls_.ComboBox_swiginit(self,_controls_.new_ComboBox(*args,
>> **kwargs))
>> wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed
>> at /Users/codyprecord/Desktop/devel/wxWidgets/src/common/
>> stockitem.cpp(202) in wxGetStockLabel(): invalid stock item ID
>
> Well, this is bizarre... It looks like there are at least two
> problems that have to occur to get to this point:
>
> 1) wxIsStockId(wx.NewId()) has to return true for that particular
> ID, and
>
> 2) Even though wxIsStockId(wx.NewId()) returns true, wxGetStockLabel
> does not accept that label
>
> It's weird that a ComboBox would have empty labels in the first
> place, though. Have to check into this more tomorrow.
Yea it only happens to some and not others. Mostly saw it with some
Combo and Choice controls. The only potential relationship I can see
between the ones it happened in is that they were Combo/Choice
controls that were either created with just an Empty String in them as
the only choice or initial choice. (not a 100% on this but will look
again).
i.e) wx.Choice(..., choices=[""])
>
> Many thanks for your help! I'm hoping to get a binary out to people
> soon, as I think that while there's still a number of issues to
> tackle, a lot of apps probably will startup and run, and can be
> tested at least somewhat already.
Yea, I was able to get Editra started with only one change (not to use
wx.NamedColour anymore) and it started up so I think most apps should
be able to get running in some form or shape.
Cody
Cody Precord
Cody Precord wrote:You probably meant this the other way around, but for the record (and to avoid panic) wx.NamedColour will still work, it was the alias without the 'u' that was removed.
Yea, I was able to get Editra started with only one change (not to use wx.NamedColour anymore)
Cody Precord
On Mar 12, 2009, at 12:13 AM, Kevin Ollivier wrote:
>>
>> Which is quite correct as there is no 'contrib/gizmos/osx_cocoa'
>> directory. Forgot to commit?
>
> Me? No, never. There, uhm... must have been something wrong with
> your SVN... yeah, that's it! try updating again, I see it there... ;-)
Oh you were right I updated and they were magically there ;)
It runs fairly well on the tests I did. What kind of feedback are you
looking for at this point because there are a fair number of obvious
issues.
Here are a few (let me know if they would rather be sent to trac):
1) Sizers seem to behave differently and often items seem to overflow
the right side of a sizer.
2) Constant stream of warnings about memory leaks sent to console:
2009-03-12 20:22:03.222 Python[11739:613] *** _NSAutoreleaseNoPool():
Object 0x1919aea0 of class NSConcreteMutableData autoreleased with no
pool in place - just leaking
Stack: (0x9153973f 0x91445e32 0x92b03c61 0x1a44ec5 0x1a428b5
0x92b0329c 0x92b01d93 0x92b0212a 0x92b0212a 0x92b0212a 0x92b0212a
0x92b006e9 0x92b01543 0x92b0002b 0x92afcb4f 0x92a3d523 0x92a3d0d1
0x1a35275 0xbe7a29 0x3fadac 0x4846e1 0x48771d 0x484d9e 0x486b86
0x486b86 0x486b86 0x486b86 0x48771d 0x4878d1 0x4ab031 0x4ab3cb 0x4b8bbe)
3) ToolBars seem to initialize correctly but doesn't have any icons in
it
4) Many controls seem to cause the following error (not sure if its a
2.9 api change or a case of not implemented).
File "ToolBar.py", line 201, in OnButton
win = TestToolBar(self, self.log)
File "ToolBar.py", line 132, in __init__
size=(150,-1), style=wx.CB_DROPDOWN
File "/Users/codyprecord/Desktop/devel/wxWidgets/wxPython/wx/
_controls.py", line 590, in __init__
_controls_.ComboBox_swiginit(self,_controls_.new_ComboBox(*args,
**kwargs))
wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at /
Users/codyprecord/Desktop/devel/wxWidgets/src/common/
stockitem.cpp(202) in wxGetStockLabel(): invalid stock item ID
5) In a RadioBox the radio button labels get cut off by 2-4 pixels on
the right side.
6) The Stock Help button shows a ? and also has the Help text
overlapping it as well.
Cody
Cody Precord
Cody Precord wrote:I think I zapped all of them.
Just out of curiosity are all the 'colour' aliases for all objects/methods/functions being removed as well? or is this just a special case.