Changes
Development Team/Almanac (view source)
Revision as of 09:45, 29 September 2008
, 09:45, 29 September 2008→How do I get the amount of free space available on disk under the /home directory tree?
== Package: sugar.presence ==
== Package: sugar.presence ==
* [[sugar.presence]]
* [[sugar.presence.activity]]
* [[sugar.presence.activity]]
* [[sugar.presence.buddy]]
* [[sugar.presence.buddy]]
</pre>
</pre>
Note, however, that assuming anything about "/home" is a bad idea, better use os.environ['HOME'] instead. Rainbow will put your actual files elsewhere,
some on ramdisks, some on flash. Be clear about which filesystem's free space you actually care about.
=== How do I know whether my activity is running on a physical XO? ===
=== How do I know whether my activity is running on a physical XO? ===
While your activity is typically going to be run on a real XO, there might be circumstances (such as for development through sugar-jhbuild) that you will not be running on an XO machine. The easiest way to tell if you are on a physical XO is to check whether /sys/power/olpc-pm, an essential power management file for the XO, exists. <ref>[http://lists.laptop.org/pipermail/devel/2008-June/015923.html reliably detecting if running on an XO]</ref> <ref>OLPC [[Power Management Interface]]</ref>
Sugar runs on ordinary computers as well as on XO's. While your activity is typically going to be run on a real XO, some people will indeed run it elsewhere. Normally you shouldn't write your activity to care whether it's on an XO or not. If for some odd reason, you need to care, the easiest way to tell if you are on a physical XO is to check whether /sys/power/olpc-pm, an essential power management file for the XO, exists. <ref>[http://lists.laptop.org/pipermail/devel/2008-June/015923.html reliably detecting if running on an XO]</ref> <ref>OLPC [[Power Management Interface]]</ref>
<pre>
<pre>
setxkbmap us
setxkbmap us
=== My Python activity wants to use threads; how do I do that? ===
Early versions of Sugar (pre-"Update.1" release) would automatically configure Python, gobject, and glib for threaded operation. Due to the overhead imposed on every activity by those initializations, Sugar no longer does that. If you are writing an activity for a later release, and you want threads to work, start off your activity (just after the copyright comments) with:
import os
import logging
# Sugar does this but only in pre-update.1.
import gobject
gobject.threads_init()
#import dbus.mainloop.glib
#dbus.mainloop.glib.threads_init()
Comment out, or uncomment, the glib threads initialization, depending on whether you need it. (I don't know how to tell if you need it, except by trying it both ways.)
Then follow that with the rest of your imports (such as "import gtk"). In my activity (SimCity), the pygame sound player would not produce sound reliably unless I did this.
In SimCity, I have tested this to make sure it works in the *old* XO software releases as well as the new ones. The documentation for these threads_init functions is really bad, and doesn't say whether you can call them twice, nor does it say how you can tell if they've already been called so you could avoid calling them twice. Apparently it's pretty harmless in release 650.
== Notes ==
== Notes ==