User:NeoAmsterdam/10.1.2/Gallery
Don't let the cute façade fool you: the XO is powerful.
Contents
Sugar
Name Screen
To take screenshots in Sugar, press ♢alt+1. This, however, is one of the exceptions to the oh-so-easy rule.
Since the user's configuration has yet to be completed, Sugar can't commit a screenshot to the Journal as it normally would. The trick is to call upon ImageMagick's import command using -display :0 -window root filename.ext from the console. But if you run import from within the console, you'll end up with a blank screenshot! As a result, import needs to execute on a delay that's just long enough for you to jump back into the graphical environment before ImageMagick does the voodoo that it do so well.
Oh!, the things I'll do for a screenshot…
Home Screen
There's no place like a 16GB ~/
I may treat my XO with exceptional care (I have been known to pat it on the "head" when it's been a good lil' laptop), but I still expect it to do what "grown-up" Linux boxes do, and that takes up some space. I'm not entirely sure how to account for the 6GB in use, but it's not inconceivable: Release 10.1.2, TeXLive, GCC, Wine and DOSBox (and the associated C:\ drive contents), and so on and so forth. And since the SD card has plenty of capacity - far more than the XO's built-in storage - there's plenty of room for future growth.
The more observant of you might notice that the XO logo doesn't quite adhere to the standard color palette (most noticeably, that it's green-on-white). Previously, the XO logo outline and inline colors could be changed as desired by editing ~/sugar/default/.config; as of release 10.1.2, this information is stored in ~/.gconf/desktop/sugar/user/%gconf.xml (the XO logo itself is stored in /usr/share/icons/sugar/scalable/device/computer-xo.svg). I chose #54B948 to match the XO's case color.
It would be nice if one could chose "head" and "body" colors independently so as to match the cover of the XO (i.e.: cyan and green to match this young lady's XO), or to be able to replace XO logo with a picture of the user instead.
GNOME
G.Projector
Hey! I can see my house from here!
G.Projector is a cross-platform application which can transform an equirectangular map image into almost 100 map projections. It's a heavyweight application, and the fact that it needs a Java runtime environment aggravates the workload.
Mars24
I have a vague recollection of a song whose lyrics included something to the degree of "So I went up to the lady and asked her 'Could you tell me what time it is if we were on Mars?'". Trust the folks at NASA to have an answer.
Mars24 is a Java application which displays a graphical representation of Mars, showing its current sun- and nightsides, along with a numerical readout of the time in 24-hour format. Fortunately, Mars24 doesn't tax the XO as heavily as G.Projector does, which means that Titan24 should also perform well.
This would make a nice compliment to Moon (as long as we can ditch Java and Sugarize the whole thing).
VLC
It won't turn your XO into a portable cinema, but it's not bad performance for 433MHz. Unless you turn on features that are for the most part superfluous (like audio visualizations, two-pass equalization, and image manipulation), you'll find that the biggest (or should that be "narrowest"?) bottleneck is in the read speed of the medium. All I can say for certain is that I've had better performance reading from a NAS box over WiFi than I did reading from a 2GB USB drive.
And in case you're wondering "Why Lain?", it's because I can't help but draw parallels between the XO and the Navi .
Wine
If someone laughs at you for using an XO, this is how you shut him up.
I won't advocate running you-know-who's Office suite, nor will I condemn it. OLPC adapts to the needs of each country in which it operates, and the same applies to each XO user. But I will say this: there are better word processors, spreadsheets, slide projectors, and e-mail managers out there.
(As for the best-known open-source alternative to you-know-who's Office suite, I cannot over-emphasize the fact that the Java runtime environment in and of itself is a burden: do not compound the problem.)
Oops!
One could argue that Kile has the best balance between features, performance, and resource demands among [La]TeX editors. But none of that matters when the UI elements clogs up your workspace.
Someone somewhere knows the solution to this problem. If that someone is you, please share it - I'll be your best friend! ☺
