using Xgl on SUSE at NovellFrom the Python in Education eGroup I'm on; cutting and pasting, adding hyperlinks.
If you've seen one of Miguel's demos of the new Novell desktop, you'll know we're already moving to more 3D motifs at the level of OS GUI, complete with the rotating cube between the six desktops, with a Quicktime movie able to wrap around an edge while still playing (flashing back to an OSCON).
I think we'd like to be able to call up a writing surface, able to take source code, from within a 3D world, such as by unscrolling a canvas-like object plucked from a metallic tube, textures and everything. And as we've seen in Squeak, when every graphical type object has a strong shared set of base methods, then even buttons can be grabbed and tilted (not just depressed).
Per recent Mono or .NET presentations of IronPython: so you want every button on your GUI calculator rotated counter- clockwise by 45 degrees? No problem. That's just the trend in GUIs these days, with GNOME very much a trailblazer (wow, svg screen icons!).
So the engines I'm envisioning at some level might just be the next generation OSs of choice, and their accompanying GUI session managers. If sufficiently integrated and interoperable (we have a ways to go), we might call this Squeaky clean. Think Emacs = eToy.
But I don't think we can stop there. More specialized apps, on top of the OSs, will provide their own vocabulary of 3D components (objects), be they widget type, animal type, or whatever. You'll be able to script their behaviors and interactions, oft times by typing, as the base source continues to be lexical (versus say hieroglyphic, which more characterizes the desktop icons level).
Such applications entail an event model, lots of hooks, and mechanisms for persistence across sessions. The OS offers an API for all of this, yes, but not always at a high enough level. By design. Managing some "higher level" is not really the OS's job.
A layer of "education applications" wrapped around various spatial geometry animation engines is reasonable to anticipate, plus I expect many of them will come with Python bindings, although not necessarily exclusively (any number of languages should be enabled to play, by giving them some shared target language -- precisely the intent of the .NET design, and Parrot's).
I think we'd like to be able to call up a writing surface, able to take source code, from within a 3D world, such as by unscrolling a canvas-like object plucked from a metallic tube, textures and everything. And as we've seen in Squeak, when every graphical type object has a strong shared set of base methods, then even buttons can be grabbed and tilted (not just depressed).
Per recent Mono or .NET presentations of IronPython: so you want every button on your GUI calculator rotated counter- clockwise by 45 degrees? No problem. That's just the trend in GUIs these days, with GNOME very much a trailblazer (wow, svg screen icons!).
So the engines I'm envisioning at some level might just be the next generation OSs of choice, and their accompanying GUI session managers. If sufficiently integrated and interoperable (we have a ways to go), we might call this Squeaky clean. Think Emacs = eToy.
But I don't think we can stop there. More specialized apps, on top of the OSs, will provide their own vocabulary of 3D components (objects), be they widget type, animal type, or whatever. You'll be able to script their behaviors and interactions, oft times by typing, as the base source continues to be lexical (versus say hieroglyphic, which more characterizes the desktop icons level).
Such applications entail an event model, lots of hooks, and mechanisms for persistence across sessions. The OS offers an API for all of this, yes, but not always at a high enough level. By design. Managing some "higher level" is not really the OS's job.
A layer of "education applications" wrapped around various spatial geometry animation engines is reasonable to anticipate, plus I expect many of them will come with Python bindings, although not necessarily exclusively (any number of languages should be enabled to play, by giving them some shared target language -- precisely the intent of the .NET design, and Parrot's).
