[Edu-sig] Shuttleworth Summit

[Dethe Elza]

On 4/21/06, Guido van Rossum <guido at python.org> wrote:
> On 4/21/06, Dethe Elza <delza at livingcode.org> 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/)
>