OS X Cocoa wxPython available in trunk

Kevin_Ollivier3 · March 11, 2009, 5:20am

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!

Thanks,

Kevin

Cody · March 12, 2009, 4:54am

Hello,

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?

Cody

···

On Mar 11, 2009, at 12:20 AM, Kevin Ollivier wrote:

Kevin_Ollivier3 · March 12, 2009, 5:13am

Hi Cody,

Hello,

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

···

On Mar 11, 2009, at 9:54 PM, Cody Precord wrote:

On Mar 11, 2009, at 12:20 AM, Kevin Ollivier wrote:

Cody

_______________________________________________
wxpython-dev mailing list
wxpython-dev@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

Cody · March 13, 2009, 1:46am

Hello,

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

···

On Mar 12, 2009, at 12:13 AM, Kevin Ollivier wrote:

Kevin_Ollivier3 · March 13, 2009, 5:24am

Hi Cody,

Hello,

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.

Thanks,

Kevin

···

On Mar 12, 2009, at 6:46 PM, Cody Precord wrote:

On Mar 12, 2009, at 12:13 AM, Kevin Ollivier wrote:

Cody

_______________________________________________
wxpython-dev mailing list
wxpython-dev@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

Cody · March 13, 2009, 2:09pm

Hello,

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

···

On Mar 13, 2009, at 12:24 AM, Kevin Ollivier wrote:

Robin · March 13, 2009, 3:57pm

Cody Precord wrote:

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!

Cody · March 13, 2009, 4:11pm

Hello,

···

On Fri, Mar 13, 2009 at 10:57 AM, Robin Dunn robin@alldunn.com wrote:

Cody Precord wrote:

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.
Yes I meant ‘NamedColor’, I was just trying to state that I only had to make one minor change (due to 2.9 api changes not cocoa bugs) to start Editra. So it should be easy for others to start testing with their programs as well.

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.

Thanks,

Cody

Robin · March 13, 2009, 5:03pm

Cody Precord wrote:

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.

···

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

Cody · March 13, 2009, 5:52pm

Hello,

···

On Fri, Mar 13, 2009 at 12:03 PM, Robin Dunn robin@alldunn.com wrote:

Cody Precord wrote:

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.

Yikes, I think I confused them again when typing that, so just to be clear.

***Colour is still available

***Color is Removed

probably a good thing its going to one choice as I have already confused them twice in the last two messages.

Cody