I suffer from the limitations of both X11 and Wayland. Some things work in one and not the other, it's a trade off. In Wayland I can use different scaling for each monitor (in exchange for a LOT of RAM). But in X11 I can use Barrier to share my mouse / keyboard with my other computer. So I use one when I have a second monitor and have to restart my session when I use a second computer :'(
It will be fixed on some Waylands with libei, but it will never be fixed on other waylands that find libei distasteful (like sway). And that's the waylands in a nutshell: many different things, never "wayland" always "waylands".
libei looks useful. But IDK why libei is necessary to run Barrier with Wayland?
For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through
And for host systems, it looks like xev only logs input events when the window is focused.
Is xeyes still broken on Wayland, and how to fix it so that it would work with Barrier?
With Barrier, when the mouse cursor reaches a screen boundary, the keyboard and mouse input are then passed to a different X session on another box until the cursor again crosses a screen boundary rule.
> For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through
You seem to be asking for kernel thing, not something Wayland. But let's assume you wanted a protocol on top of Wayland to do this:
Why can't arbitrary Wayland clients always see the mouse pointer, snoop on the keyboard, and inject keypresses? Because of security, by design.
Why is it taking a bunch of work to provide that capability in an access-controlled way? Because it's a bunch of work. For example, quoting libei: "However, the events are distinguishable inside the compositor to allow for fine-grained access control on which events may be emulated and when emulation is permitted."
I downloaded the 64bit Linux build and it has a strange executable called "payload". I moved it out of precautio and still launched the app, and it seems to work fine without this executable. What is this "payload"? Anyone know? A quick search didn't find anything relevant.
There's plenty! Try `childsplay`, `pysiogame` for collections of didactic activities. Other fun individual games are `raincat`, `colobot`. Try `rabbit escape` also. For fun (we let them play as prize) try `X-moto` and `SuperTuxkart` as well as `Supertux` platformer. We only let our kids play with libre games, so that we are able to adapt the games and learn how they are made, even reuse the assets. My kids are the same age 5 and 7.
As a practitioner of traditional amazonian spiritual tradition, I and my family drink Ayahuasca on a regular basis and find it to be invaluable, our first line of defense for disease both physical and spiritual.
Hello Alan,
In light of the poor results of the OLPC project, in reference to the Children's Machine, leaving aside commercial factors, do you think the Sugar user interface is appropriate for the task? If not, how can it be improved, what is good/bad about it?
A related question: in your opinion, what were the successes and failures of the OLPC project, what openings and obstacles contributed to that, and where do we go from here?
I've studied the Sugar design and source code, and programmed Sugar apps and widgets, including wrapping the X11/TCL/Tk version of SimCity [1] in a thin Sugar python script wrapper to make it into an activity, working on reducing the power consumption of the eBook reader, and developing pie menu widgets for Sugar in Python/GTK/Cairo/Pango [2].
My take on the OLPC project is that they were tackling so many interdependent problems at once, both software and hardware, that it was impossible to succeed at its original lofty goals. But it was also impossible to achieve those goals without tackling all of those problems at once. However, a lot of good came out of trying.
It was like the "Stone Soup" folk story [3], that brought together brilliant people from many different fields.
A great example of that effect was that we were able to convince Electronic Arts to relicense SimCity under GPLv3 so it could be used on the OLPC. [4]
One of the many big goals was reducing power consumption, which cross-cut through all parts of the system, requiring coordination of both hardware, software, and the firmware in-between.
Some of the designs were brilliant and far ahead of their time, especially Mary Lou Jepsen's hybrid display, and Mitch Bradley's Open Firmware Forth system.
RedHat modified Linux to support a tickless kernel, consolidating periodic interrupts together to run at the same time so they didn't each wake the CPU at many different times. [5]
Many of the solutions to problem the OLPC project was working on have benefitted other more successful platforms.
John Gilmore credits the OLPC in lighting a fire under laptop vendors to make competing low power low cost laptops like the Chromebook a reality.
Some of the ideas were ridiculous, like the silly crank to charge it.
Sugar had too many dependencies on all the other stuff already being in place and working flawlessly. And its was far too ambitious and revolutionary, while still being layered on tons of old legacy cruft like X11, Python, GTK, etc.
I love Python, but the OLPC came at a time when it would have been a better to implement the entire user interface in JavaScript/HTML.
Sugar app developers realized they needed the services of a deeply integrated web browser (not to mention the ability to run in any desktop or mobile web browser outside of the Sugar ecosystem), but the overhead of plugging xulrunner into Python and integrating JavaScript and Python via XP/COM and GTK Objects was just too astronomically complex, not to mention horribly wasteful of power and memory and simplicity.
You have to navigate the trade-offs of building on top of old stuff, and building new stuff. And I think Sugar chose the wrong old stuff to build on top of, for that point in time. Python and Cairo are wonderful, but JavaScript won, and Cairo migrated down the stack into the web browser rendering layer, HTML Canvas component, etc.
Also there was no 3D acceleration (or OpenGL/WebGL), which was a big disappointment to game developers, but at the time it was necessary to keep power usage low.
I'll try to specifically address your question about Sugar's appropriateness for the task and what's good and bad about it. I'll quote some stuff I wrote about it when I was porting SimCity to Sugar (prefixed by ">), and then make some retrospective comments (no prefix): [5]
>Sugar is based on Python, and uses the GTK toolkit, Cairo rendering library, Pango international text layout library, and Hippo drawing canvas, and many others useful modules. Once SimCity is integrated with Python, it will be great fun to create a kid-friendly multi-player user interface that's totally integrated with the OLPC's unique hardware design (like the hires mono/color LCD screen, which flips over into book mode with a game controller pad) and Sugar's advanced features, like scalable graphics, journaling, mesh networking, messaging, collaboration, and (most importantly) applying Seymour Papert's philosophy of "Constructionist Education" to SimCity.
Sugar was trying to reinvent far too many wheels at once.
Python was a great choice of languages, but it was in the process of being eclipsed by JavaScript. Python is strong at integrating native code (its API is easy to use, then there's SWIG, Boost, and many other ways to wrap libraries), and meta-integrating other code (GTK Objects, COM, XP/COM, etc).
But there's an overhead to that, especially when you mix-and-match different integration layers, like for example if you embedded a web browser in a Sugar interface, registered event handlers and made calls on DOM objects, etc.
On top of Cairo for graphics and Pango for text, which are two wonderful solid well tested widely supported libraries used by many other application, Sugar had its own half-baked object oriented graphics drawing canvas, "Hippo", which was written in a mish-mash of Python and GTK Objects. Nobody should have to learn how to wrangle GTK Objects just to draw a circle on the screen.
And there's this thing about universal object oriented graphics representation APIs, which is why the OLPC didn't support PEX, X11 PHIGS Extension (Programmer's Hierarchical Interactive Graphics System), and why we're not all using GKS (Graphical Kernel System) terminals instead of web browsers.
As a Sugar programmer at the time, all parts of the system were in flux, and it was hard to know what to depend on. For the Sugar pie menus, I stuck to the solid Python/Cairo/Pango APIs, with a thin layer of GTK Objects and event handlers.
As for all that stuff about journaling, mesh networking, messaging, collaboration: great ideas, hard problems, fresh snow, thin ice. As Dave Emory says: "It's food for thought and grounds for further research."
Sugar activities are implemented in Python.
What I had to do with SimCity to integrate it into Sugar was to take an existing X11/TCL/Tk application, and wrap it in Sugar activity that just launched it as a separate process, then send a few administrative messages back and forth.
That was also the way Scratch/eToys and other monolithic existing applications were integrated into Sugar.
The idealistic long term plan was to refactor SimCity to make it independent of the user interface, and plug it into Sugar via Python, then finally re-implement the user interface with Sugar.
As progress towards that goal, which was independent of Sugar, I stripped out the UI, refactored and reformatted the code as C++ independent of any scripting language or UI platform, and then plugged it into Python (and potentially other languages) with SWIG. I then implemented a pure GTK/Cairo user interface on top of that in Python (without any Sugar dependencies), and developed some interfaces so you could script your own agents and zones in Python. (As an example, I made a plug-in giant PacMan agent who followed the roads around, turning at corners in the direction of the most traffic, eating cars thus reducing traffic [7], and a plug-in Church of PacMania whose worshippers generate lots of traffic, to attract the PacMan to its neighborhood, and sacrifice themselves to their god [8]!)
As it turned out, the SimCity kernel plugged into Python was also useful for implementing a SimCity web server with a Flash web client interface, which is a much better architecture for an online multi player game than the half-baked, untested collaboration APIs that Sugar was developing.
At the high level, there were a lot of great ideas behind Sugar, but they should have been implementing on top of existing systems, instead of developed from scratch.
>The goals of deeply integrating SimCity with Sugar are to focus on education and accessibility for younger kids, as well as motivating and enabling older kids to learn programming, in the spirit of Seymour Papert's work with Logo. It should be easy to extend and re-program SimCity in many interesting ways. For example: kids should be able to create new disasters and agents (like the monster, tornado, helicopter and train), and program them like Logo's turtle graphics or Robot Odyssey's visual robot programming language!
Even if we didn't achieve those goals for Sugar, we made progress in the right direction that have their own benefits independent of Sugar.
Choose your lofty goals so that when projected onto what's actually possible, you still make progress!
I am familiar with your port and found it unplayable on the XO laptop (although I commend you on your apparently painful task of making it run in the first place!).
While I appreciate your thoughts on the OLPC, I am more interested in Alan's thoughts on Sugar.
It's great meeting you, and wonderful getting some honest feedback from somebody who's used it. Thank you! I also hope Alan has a chance to answer your question, and my four.
Could you please tell me more specifically about what made it unplayable for you? What was the nature of the problem? Did you remember to disable disasters? ;)
Please don't blame it on Sugar -- the user interface was based on a 1993 version of TCL/Tk, so it looks pretty klunky since it was designed to emulate Motif, whose widget design (according to Steve Strassman) is from the same style manual as the runway at Moscow International Airport [1].
Here's a demo of SimCity running on the OLPC [2] -- does that show any of the problems you had that made it unplayable?
Once it passed EA's QA regime, I didn't put any more effort into the TCL/Tk user interface, instead refactoring it to remove TCL/Tk and plug in other GUIs. Have you given the pure GTK/Cairo interface a try?
What was totally unplayable was the X11 based multi player feature [3], which I removed from the OLPC version, since no child should be forced to wrangle xauth permissions on the command line, and David Chapman's MIT-MAGIC-COOKIE-1 tutorial isn't suitable for children [1]. I also disabled the Frob-O-Matic Dynamic Zone Finder [3 @ 3:35], since that was a prank I played as a tribute to Ben Shneiderman [4].
Again, thanks for the feedback, which I appreciate!
Please fix this!