micropolis

hods, copy/paste/drag/drop, and internationalization stuff, which is super-tricky, or just do without it.) I implemented multi-player cursors in SimCityNet for X11 (which opened multiple X11 displays at once), but I had to fix some bugs in TCL/Tk for tracking menus and buttons, and implemented my own pie menus that could handle being popped up and tracking on multiple screens at once. TCL menus and buttons were originally using global variables for tracking and highlighting that worked fine on one X11 display at once, but that caused conflicts when more than one user was using a menu or button at the same time, so it needed to store all tracking data in per-display maps. It doesn't make sense to have a global "currently highlighted button" or a "current menu item" since two different ones might be highlighted or selected at once by different people's cursors. And I implemented special multi-user "voting" buttons that required unanimous consent to trigger (for causing disasters, changing the tax rate, etc). I had to implement multi-user cursors in "software" by drawing them on the map manually, instead of using X11 cursors. I wrote about that earlier in a discussion about Wayland and X-Windows: https://news.ycombinator.com/item?id=19732733 And it's in the direction of multi-user collaboration that X-Windows falls woefully short. Just to take the first step, it would have to support separate multi-user cursors and multiple keyboards and other input devices, which is antithetical to its singleminded "input focus" pointer event driven model. Most X toolkits and applications will break or behave erratically when faced with multiple streams of input events from different users. >https://tronche.com/gui/x/xlib/input/XGrabPointer.html For the multi-player X11/TCL/Tk version of SimCity, I had to fix bugs in TCL/Tk to support multiple users, add another layer of abstraction to support multi-user tracking, and emulate the multi-user features like separate cursors in "software". Although the feature wasn't widely used at the time, TCL/Tk supported opening connections to multiple X11 servers at once. But since it was using global variables for tracking pop-up menus and widget tracking state, it never expected two menus to be popped up at once or two people dragging a slider or scrolling a window at once, so it would glitch and crash whenever that happened. All the tracking code (and some of the colormap related code) assumed there was only one X11 server connected. So I had to rewrite all the menu and dialog tracking code to explicitly and carefully handle the case of multiple users interacting at once, and refactor the window creation and event handling code so everything's name was parameterized by the user's screen id (that's how you fake data structures in TCL and make pointers back and forth between windows, by using clever naming schemes for global variables and strings), and implement separate multi-user cursors in "software" by drawing them over the map. Multi Player SimCityNet for X11 on Linux: https://www.youtube.com/watch?v=_fVl4dGwUrA >Demo of the latest optimized Linux version of Multi Player SimCity for X11. Ported to Unix, optimized for Linux and demonstrated by Don Hopkins. X11 SimCity Pie Menus: https://www.youtube.com/watch?v=Jvi98wVUmQA Multi-user menu tracking (added "@$screen" parameterizations): https://github.com/SimHacker/micropolis/blob/master/micropol... Opening multiple X11 displays (multiple toplevel "head" windows per screen, each with a unique id, using $win parameterization): https://github.com/SimHacker/micropolis/blob/master/micropol...

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

r/micropolis/blob/master/micropol... https://github.com/SimHacker/micropolis/tree/master/Micropol... https://github.com/SimHacker/micropolis/tree/master/Micropol... You keep going back to this mistaken belief that forking off separate processes is incredibly cheap. Or even convenient. You really should rid yourself of that misconception. Sure, there is some cost to all the glue code required by something like TCL or SWIG or COM or P/Invoke or any foreign function interface. But that's not even in the ballpark of how long it takes to fork off a Unix process. It's ironic that the strongest argument bash apologists have is that it's convenient, but once you are faced with all that mish-mashed haphazard syntax and kludgy tricks (like testing for an empty string like "x$foo" == "x"), it's actually one of the most inconvenient languages there is!

publicly demonstrate all of these elements in a single system. The demonstration was highly influential and spawned similar projects at Xerox PARC in the early 1970s. The underlying technologies influenced both the Apple Macintosh and Microsoft Windows graphical user interface operating systems in the 1980s and 1990s. http://worrydream.com/Engelbart/ >Engelbart's vision, from the beginning, was collaborative. His vision was people working together in a shared intellectual space. His entire system was designed around that intent. >From that perspective, separate pointers weren't a feature so much as a symptom. It was the only design that could have made any sense. It just fell out. The collaborators both have to point at information on the screen, in the same way that they would both point at information on a chalkboard. Obviously they need their own pointers. >Likewise, for every aspect of Engelbart's system. The entire system was designed around a clear intent. >Our screen sharing, on the other hand, is a bolted-on hack that doesn't alter the single-user design of our present computers. Our computers are fundamentally designed with a single-user assumption through-and-through, and simply mirroring a display remotely doesn't magically transform them into collaborative environments. >If you attempt to make sense of Engelbart's design by drawing correspondences to our present-day systems, you will miss the point, because our present-day systems do not embody Engelbart's intent. Engelbart hated our present-day systems. And it's in the direction of multi-user collaboration that X-Windows falls woefully short. Just to take the first step, it would have to support separate multi-user cursors and multiple keyboards and other input devices, which is antithetical to its singleminded "input focus" pointer event driven model. Most X toolkits and applications will break or behave erratically when faced with multiple streams of input events from different users. https://tronche.com/gui/x/xlib/input/XGrabPointer.html For the multi-player X11/TCL/Tk version of SimCity, I had to fix bugs in TCL/Tk to support multiple users, add another layer of abstraction to support multi-user tracking, and emulate the multi-user features like separate cursors in "software". Although the feature wasn't widely used at the time, TCL/Tk supported opening connections to multiple X11 servers at once. But since it was using global variables for tracking pop-up menus and widget tracking state, it never expected two menus to be popped up at once or two people dragging a slider or scrolling a window at once, so it would glitch and crash whenever that happened. All the tracking code (and some of the colormap related code) assumed there was only one X11 server connected. So I had to rewrite all the menu and dialog tracking code to explicitly and carefully handle the case of multiple users interacting at once, and refactor the window creation and event handling code so everything's name was parameterized by the user's screen id (that's how you fake data structures in TCL and make pointers back and forth between windows, by using clever naming schemes for global variables and strings), and implement separate multi-user cursors in "software" by drawing them over the map. Multi-Player X11 SimCityNet: https://www.youtube.com/watch?v=_fVl4dGwUrA X11 SimCity Pie Menus: https://www.youtube.com/watch?v=Jvi98wVUmQA Multi-user menu tracking (added "@$screen" parameterizations): https://github.com/SimHacker/micropolis/blob/master/micropol... Opening multiple X11 displays (multiple toplevel "head" windows per screen, each with a unique id, using $win parameterization): https://github.com/SimHacker/micropolis/blob/master/micropol...