User:NeoAmsterdam/10.1.2/Gallery: Difference between revisions
NeoAmsterdam (talk | contribs) m (A few minor things that bugged me.) |
NeoAmsterdam (talk | contribs) m (Terminal and Record also balk at alt+1) |
||
Line 3: | Line 3: | ||
== Name Screen == |
== Name Screen == |
||
[[Image:NA 852 S Name Screen.png|thumb|right|The "Name:" Screen]] |
[[Image:NA 852 S Name Screen.png|thumb|right|The "Name:" Screen]] |
||
To take screenshots in Sugar, press <b>♢alt</b>+<b>1</b>. This, however, is the |
To take screenshots in Sugar, press <b>♢alt</b>+<b>1</b>. 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 <tt><b>import</b></tt> command using <tt>-display :0 -window root <i>filename.ext</i></tt> from the console. <b>But</b> if you run <tt><b>import</b></tt> from within the console, you'll end up with a blank screenshot! As a result, <tt><b>import</b></tt> 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. |
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 <tt><b>import</b></tt> command using <tt>-display :0 -window root <i>filename.ext</i></tt> from the console. <b>But</b> if you run <tt><b>import</b></tt> from within the console, you'll end up with a blank screenshot! As a result, <tt><b>import</b></tt> 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. |
Revision as of 00:56, 10 September 2010
Don't let the cute façade fool you: the XO is powerful.
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.
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.
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! ☺