Re: [Visualpython-users] MacOS native version

[Bruce S. <Bru...@nc...>]

Your interest is highly welcome!

As announced in a post a month ago or so, David Scherer, Ruth Chabay, 
and I have been working on strategy to move forward with Visual 4. 
Scherer is making rapid progress, and I'm assisting, mainly in the role 
of testing on platforms other than Windows, which is the platform he's 
working on (but he has also been writing code for the other platforms, 
blind, and usually his code works).

We place very high priority on a native Mac version. A number of 
approaches have been tried, none of which has really panned out yet. It 
does look like Carbon is our only hope, and we've just begun looking at 
this (the latest experiment is with the interesting pyglet package). 
Steve Spicklemire is also starting to look at this, but he says that all 
his Mac experience has been with Cocoa, not Carbon. As near as we can 
tell, Cocoa isn't an option because its event loop is required to be the 
primary thread, which is fine for building applications but not for 
building a module that can be imported at any time from a Python program.

If you have significant Carbon experience WE WANT YOU on the team! Of 
extremely high interest to us at this instant is a proof of concept of 
the feasibility of a Carbon-based approach. As Scherer commented just 
today, "I think we need a simple Carbon example that does everything in 
a secondary thread ASAP, to confirm that it is possible!"

I did succeed in making a GTK2 version of Visual 4 for Windows, but we 
have abandoned that approach because of the unacceptably huge complexity 
of setting up the development environment (see the notes posted in the 
Developer's section of vpython.org). We've gone back to having a 
separate module that is Windows-specific for creating windows and 
handling events, and of course we also want to do this for the Mac.

The reason I built a GTK2 version of Visual 4 for Windows was that it 
appeared to me that the (non-GTK2) Windows version was significantly 
more buggy than the Linux/Unix version. As I got into this however, 
starting in November, and nibbled away at the identifiable bugs, which 
turned out not to be for the most part platform-specific, it became less 
and less likely that there was anything seriously wrong with the 
Windows-specific code. So, given the enormous complexity of the GTK2 
environment, we abandoned that approach.

What is currently in CVS at sourceforge is rapidly changing but is 
normally in working order at all times.

Bruce Sherwood

Hugh Fisher wrote:
> A month ago I started doing some work on the 3.2.9 vpython source,
> intending to first clean up various GTK glitches and make it
> build with GTK2, and then do a native MacOS X (Carbon) platform
> implementation. My reasons for doing this were that the next gen
> VPython seemed to be taking a long time to get out of beta and
> didn't include native MacOS support.
> 
> I gather than next gen VPython development may be changing
> direction. Anyone got a clear picture of what will be happening?
>