On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/21/06, Dethe Elza <[EMAIL PROTECTED]> wrote: > > The Mozilla project has some of the best cross-platform widget-level > > toolboxes, including SVG (and they are looking at OpenGL support). > > The funny thing about most cross-platform graphics toolkits is that > > the ignore the platform with the best graphics: OS X. > > Isn't Mozilla big as a bus?
XulRunner[1] (the toolkit version of Mozilla) download is 6.9MB (Windows), 8.8MB (OS X), 7.9MB (Linux) . I don't know how big Tk alone is, but ActiveTCL is 18-22MB. wxWidgets doesn't list file sizes, but the zip version for Windows is 19.3MB (had to download it to find out) without including the Python bindings. On the other hand, PyGame is 0.8-1.2MB, but for that you get a hardware abstraction layer and not much else. Also, as Ian hinted earlier, doing vector work on PyGame looks terrible, it's really optimized for moving bitmaps around really fast. http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-trunk/ > Also, the goal (in an educational context) is *not* a pre-built widget > set but a fast raw graphics environment on tolp of which you can > design your own widget set. This is not particularly good application > design from a classic POV (since you're not getting native widget > functionality) but the importance from an educational POV is that it > lets students "open the hood" and see how things are implemented > (almost) all the way to the raw bitblt operations. OK. Sounds like a much bigger project than Python 3000 or PyPy. > > > The approach that seems to make the most sense to me (but I'm open for > > > alternatives) is to start out by producing a solid low-level graphics > > > package like this that can work across platforms (Linux, Windows and > > > OSX preferably); once that is settled, we could build an application > > > resembling Squeak's UI. > > > > That's a huge project to start from scratch. Mozilla-the-toolkit is > > adding support for Python in the next major version, perhaps Python > > can leverage that? > > Not clear how since Mozilla would still be on top. Anyway, I explained > above that I don't want a widget toolkit to build on. Not sure what you mean about Mozilla still being on top, but it's clear you don't want to go that route. > > More on the Smalltalk-Squeak-OS X interplay: Squeak may be > > "cross-platform" but it's always been unusably slow on OS X when I've > > tried it. > > Yes, that's a problem with their cross-platform > lowest-common-denominator approach. Perhaps they even used the X11 > emulation on OSX... No, but that's what OpenOffice and VPython did. I can ignore OpenOffice, but I miss VPython. > That's why Alan Kay suggested that Python start at a different > abstraction level, more in tune with graphics accelerator hardware > (not that I have any idea what such hardware is capable of these days, > or what type of API it has). OS X, some versions of X (and probably Vista, if it ever ships) are built on top of OpenGL, using the hardware accelerator as a low-level window manager. That's part of why you lose so much by implementing widgets non-natively, there is a *lot* going on in the native toolkit, with integration between the input, the hardware accelerator, the operating sytem, services, etc. Recent 2D toolkits have been built on top of OpenGL, but graphics chipmakers are also beginning to build 2D acceleration into their chips, first for cellphones (which adopted SVG much more widely than desktops did), but soon for desktops/laptops as well. The API is OpenGL (for 3D), not sure about the 2D stuff, probably display PDF like what Apple uses, possibly with native support for SVG. > > I'm used to building GUIs with the PyObjC bridge and native > > Cocoa widgets, which are generally as fast in Python as they are in > > Objective-C. Also, Objective-C is based directly on Smalltalk, but > > meshes *really* well with Python, and there is a cross-platform > > version of much of the Cocoa library: GnuStep. GnuStep isn't all the > > way there, but it could be a good place to start if the Mozilla > > libararies aren't chosen. > > Um, the same problem -- it's a widget library. Did you see the posts > about pygame? That's a more likely candidate. Yes, but I've used PyGame, which is why I have trouble taking that idea seriously. I guess if you want it to be Python from the metal on up you'll have to go down that rabbit-hole, or one much like it, but that's going to be a tremendous amount of work to recreate stuff that already exists in better forms. --Dethe > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
