micropolisJS

ulrunner Python extension was not well supported, was extremely complex, and had lots of overhead. https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... And xulrunner itself turned out to be poorly supported by Mozilla, and never became popular, feature-rich, and well maintained like Electron. https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... Sugar was build on top of the Cairo graphics library, like xulrunner (Mozilla/Gecko/Firefox) and GTK were, so at least they shared the same 2D rendering library. Cairo (the moral equivalent of html canvas 2d context) was a great choice of 2D graphics library at the time, both for the browser and for Python, because the OLPC XO-1 hardware didn't have a 3D graphics accelerator (so WebGL was out). But Sugar then went on to use GTK via Python (using a complex GObject/Python adaptor bridge), and built a thick sweet syrupy layer of object oriented graphics and user interface gobbledygook on top of that. It was a mish-mash of way too many competing object systems (GTK objects + Python objects + Cairo objects + xulrunner objects + Sugar objects). At first, I simply ported and polished the old TCL/Tk/X11 version of SimCity to Sugar, by making a tiny Python wrapper around it to launch and kill the TCL/Tk app under control of the Sugar desktop user interface (with some metadata to give it a name and an icon on the Sugar desktop). My next more ambitious goal was to rewrite SimCity's TCL/Tk user interface in Python using Sugar, but Sugar was just not ready yet. But the PyGTK/Cairo stuff was solid and efficient. So I simply refactored SimCity into C++ classes, plugged them into Python with SWIG, and made a pure PyGTK/Cairo user interface that ran on Mac, Windows and Linux, instead of a Sugar-specific interface. So I could at least make some progress while waiting for Sugar's GUI API to gel and mature, which never really happened before I had to stop working for free and do something else to pay the rent. https://github.com/SimHacker/micropolis/tree/master/Micropol... The original TCL/Tk version of SimCity supported multiplayer, but I had to disable it for the OLPC, because it used hard-to-set-up insecure X11 networking, not suitable for kids. And the sugar mesh network invitation rendezvous stuff wan't ready yet (or worth reimplementing in TCL/Tk just for SimCity). http://www.art.net/~hopkins/Don/simcity/simcity-announcement... To implement a modern multiplayer version of SimCity (now referred to as Micropolis), instead of using X11, it made much more sense to run the simulation as a web service and the user interface in the web browser. So I develop a Python/TurboGears/SQLAlchemy based back-end web application server, plugged the C++ MicropolisCore simulation engine into the web server with SWIG, and made an OpenLaszlo/Flash/AMF based front-end user interface, because Dynamic HTML, WebSockets and WebRTC were't quite ready yet. https://www.youtube.com/watch?v=8snnqQSI0GE https://github.com/SimHacker/micropolis/tree/master/turbogea... https://github.com/SimHacker/micropolis/tree/master/laszlo/m... Now days the JavaScript ecosystem is mature enough to implement the user interface and networking without proprietary crap like Flash and AMF (in fact Graeme McCutcheon has rewritten the entire simulator and user interface in JavaScript). https://github.com/graememcc/micropolisJS ...Eventually JavaScript started running a hell of a lot faster than anyone expected, then Flash died, xulrunner withered on the vine, while dynamic HTML, canvas, WebGL, and WebAssembly finally matured, and node.js and Electron happened, JavaScript evolved, the tooling and library ecosystem expanded like a supernova, and JavaScript took over the world. But that wasn't what most people expected to happen 14 years ago in 2005, when Python was on its way to ascendency as both a general purpose language to replace Perl, PHP and Java, and an educational language to replace Scheme. In retrospect, if we could restart from scratch today, Sugar could have been written entirely in JavaScript, on top of something like xulrunner or Electron to access the operating system, and the entire system and many applications could have been programmed and scripted in JavaScript instead of Python. But then Sugar would have to compete with the myriad of other JavaScript pointy clicky user interface frameworks out there, on its merits. And while it had some great ideas and nice designs, it also made a lot of huge design and architectural mistakes and bad trade-offs. Redesigning a friendly graphical internationalized localizable user interface for children from the ground up is a gigantic fractally complex long term problem, and Sugar bit off of a lot more than it could chew and optimistically overpromised, even if it were built on top of today's software and hardware. But there are still some great long term evolutionary projects that were adapted for the OLPC and have migrated or been reborn to run in the web browser. By now, Squeak and Scratch and Snap! all run in the web browser: both in an emulated Smalltalk VM written in JavaScript (squeakjs [1]), and also Scratch 3.0 [2] has been rewritten entirely in JavaScript. Snap! [3] was originally written in JavaScript from the ground up, and has all the power and generality of Scheme, that Scratch left out. [1] https://squeak.js.org/ [2] https://en.wikipedia.org/wiki/Scratch_(programming_language)... [3] https://snap.berkeley.edu