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?
>
|
