Re: [Sugar-devel] [RFC] Better disk format for journal entries
I think it would be very useful if the datastore were less opaque to regular tools. Especially as a developer, I find the Journal sometimes gets in the way and going around it should be easier. Related to the Gnome thread, this sort of work might help in making Sugar impervious to Gnome damage, or even go towards integrating the Sugar datastore into Gnome's future equivalent of the Journal. On 27 June 2010 04:06, Michael Stone mich...@laptop.org wrote: Folks, I've longed, for quite some time, for an encoding of Sugar's journal entries that is more amenable to manipulation with standard Linux tools and APIs. I've also longed for a format that is friendly to rainbow and which can encode both the data necessary for today's journal as well as the data necessary for Eben's Journal redesign mockups. A few days ago, I wrote a little bit about what I think such a format might look like over here: http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024908.html Unfortunately, this note didn't generate much of a response -- thus, to whet your appetite further, here's a (rough!) exporter from today's DS into the format sketched in that note, available both in the the patch following this note and in my combined sugar git repo [1] in the xos branch. Already, I find it helpful both for browsing my DS with filesystem tools and for resuming activities from the Terminal. What cool things can you think of to do with it? Regards, Michael [1]: Links to my sugar git repo: http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz git://dev.laptop.org/users/mstone/sugar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC] Better disk format for journal entries
On 27.06.2010, at 05:06, Michael Stone wrote: Folks, I've longed, for quite some time, for an encoding of Sugar's journal entries that is more amenable to manipulation with standard Linux tools and APIs. I've also longed for a format that is friendly to rainbow and which can encode both the data necessary for today's journal as well as the data necessary for Eben's Journal redesign mockups. A few days ago, I wrote a little bit about what I think such a format might look like over here: http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024908.html Unfortunately, this note didn't generate much of a response Duh! Who would have expected that the actual message went on below the top-reply and quote? I have simply not seen it. Even glancing over it now it did not read like an actual proposal. -- thus, to whet your appetite further, here's a (rough!) exporter from today's DS into the format sketched in that note, available both in the the patch following this note and in my combined sugar git repo [1] in the xos branch. Already, I find it helpful both for browsing my DS with filesystem tools and for resuming activities from the Terminal. What cool things can you think of to do with it? Regards, Michael [1]: Links to my sugar git repo: http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz git://dev.laptop.org/users/mstone/sugar I like the directory layout. Could you explain why you see a need for the generality of a custom ./resume script? - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Python tutorial for Pippy
Hello everyone, I'm currently working on a Python tutorial for Pippy as part of my GSOC project. I've written several lessons and am now wrapping them in Python code to make them interactive. I've attached a prototype of what I'm trying to accomplish and I'm hoping for your reviews (it's also available in my Pippy branch). I imagined the lessons being put in /data/tutorial/ and that they are accessed the same way Pippy examples are. Each such file would just have a few lines of comments to explain what the lesson is about and how to use it, and import lessonx, lessonx.run() . The lessonx.py files would be in /library/pippy/tutorial/ or somewhere similar. Comments on ANY part of it would be greatly appreciated, even if it's just a suggestion to use a different variable name in the examples the learner will see, or to (no matter how slightly) modify the way something is explained. It's really important to teach programming as clearly as possible, IMO. Kind regards, Dinko Introduction Description: Binary data # TODO: options to quit, save progress and resume the tutorial. def run(): print Hello there, and welcome to PyTutor. Before we continue, please tell me your name. You can type it in right here: answer = no while answer == no.lowercase(): name = raw_input( ) print Your name is + name + . Did I get it right? You can answer \yes\ or \no\. answer = raw_input( ) while answer.lowercase() != yes and answer.lowercase() != no: print Please answer \yes\ or \no\. answer = raw_input( ) if answer.lowercase() == no: print Please enter your name again: # TODO: Reading the whole text without guidance. print Hello again, + name + . Before you is a set of lessons about computer programming, or just programming for short. I will present them to you and guide you through them. You can also read them yourself without my guidance. If at any time you wish to quit, just type in \quit\. You can always resume the tutorial later by simply restarting it and introducing yourself again. To continue, just press enter. if raw_input( ) == quit: quit() print So, the beginning. What is computer programming? In most cases, it is writing down a sequence of tasks that you want your computer to do, and that is what we will be doing. Fox example, you could tell your computer to make some calculations for you. Whenever you see on the screen, that means that you can type. *(TODO: explain this differently)?* Try typing print 10 + 3. exactly = True while True: user_input = raw_input( ) if user_input == quit: quit() elif user_input == skip: print Skipping this example, moving on... break elif user_input == print 10 + 3: print 13 break elif user_input[0:6] == print : exactly = False try: print eval(user_input[6:]) # This or the alternative? # exec(user_input) break except: print That won't work. Try what I suggested. else: print You don't have to use the numbers I asked you to, but you should start with \print \. print print Press enter to continue. user_input = raw_input( ) print Good., if exactly == False: print That wasn't exactly what I asked you to type, but it works as well. It's good that you're trying your own examples!, print Please - try some more! You can use any numbers and other mathematical operations (+, -, *, /, **, % ) as well. A few examples: print 5 * 5, print 30 / 3, print 1 + 2 + 3 + 4 - 5. When you are done trying your calculations, simply type done and I will continue. user_input = raw_input( ) while user_input != done: if user_input == quit: quit() elif user_input == skip: print Skipping this example, moving on... break elif user_input[0:6] == print : try: print eval(user_input[6:]) except: print That won't work. Try something else. else: print You should start with \print \ for now. We'll practice other things later. user_input = raw_input( ) print print Congratulations! If you have never done something like this before, you've just programmed for the first time and written your first short computer program. print \nThere are many examples of programs available in Pippy. If you haven't already tried to run them, you can do that now - type quit and you can resume the tutorial later. Bear in mind that most of those programs consist of over a hundred lines of code (what we've tried so far had only one line) and that it will all look very confusing to you - but that is OK. As we advance through our lessons, you will be able to understand more and more of those examples,
Re: [Sugar-devel] Fwd: Analysis help needed re: sugargame (pygame) on the 1.0XO (build 802)
Hi George, Turns out the get_window() method is indeed missing in that older PyGTK. Instead, there is a property called window. So just replace: self._socket.get_window() with: self._socket.window And it should work fine. I'll release a new version with this change. Thanks, Wade On Sat, Jun 26, 2010 at 4:27 PM, Wade Brainerd wad...@gmail.com wrote: Hi George, Thanks! I'll take a look at it this weekend to see if I can find a workaround for the missing API. Wade On Jun 26, 2010, at 12:02 PM, George Hunt georgejh...@gmail.com wrote: Hi Wade, Thanks for your offer. I've attached XoPhoto-2.xo. There is also a git repo at http://git.sugarlabs.org/projects/xophoto/repos/mainline http://git.sugarlabs.org/projects/xophoto/repos/mainline if that is more convenient. On my test machine, I reflashed to build 802. For some reason, I had trouble getting the journal to recognize my USB stick. So I copied /media/KINGSTON/XoPhoto-2.xo to /home/olpc/Activities, and then unzipped it. I found that if I commented out line 50 of XoPhoto.activity/sugargame/canvas.py, my application would come up successfully. Tomeo's hypothesis is that gtk. 2.14.2 (or pygtk) doesn't include _socket.get_window(). Without the ability to set the pygame cursor to None, as you will see, I'm not able to use the gtk cursor resources. I've tried a few things unsuccessfully to try to get a reference to the pygame window. I'd appreciate any ideas you might have George On Fri, Jun 25, 2010 at 10:39 PM, Wade Brainerd wad...@gmail.com wad...@gmail.com wrote: Hi George, Can you send me a copy of your activity? I'll try it out on my XO (also running 802) and see what's wrong. Thanks, Wade On Tue, Jun 15, 2010 at 9:40 PM, George Hunt georgejh...@gmail.com georgejh...@gmail.com wrote: To: sugar-devel@lists.sugarlabs.orgsugar-devel@lists.sugarlabs.org Date: Sun, 6 Jun 2010 16:20:05 -0400 Subject: Analysis help needed re: sugargame (pygame) on the 1.0XO (build 802) Hi everyone, I've been developing a thumbnail slide sorting activity using pygame on my 1.5XO. I've been happy with the ease of laying out the screen using pygame. Now I'm checking it out on the 1.0, and having perplexing difficulty. My guess is that it's something that I'm doing, because the test activity distributed with sugargame, and the Demoiselle demo program developed by Jim Simmons also fail in the same manner. (but I've redownloaded build 802, and reflashed my test machine, and also brought down the most recent git of sugargame) As I understand it, Sugargame puts a gtk.socket into an eventbox, and the event box is loaded into the XO's VBox by the sugar.graphics.window.set_canvas function -- which is a super of sugar.activity.activity. In sugargame/canvas.py line 41 self._socket.get_window().set_cursor(None) AttributeError: 'gtk.Socket' object has no attribute 'get_window' This is after an environment variable SDL_WINDOWID has been passed to the pygame.init() routine, (I guess pygame uses this ID to create the gtk.Plug(). What works on the 1.5 (test.activity, and demoiselle.activity, and my application) gtk.ver = 2.16.1 pygame.ver = 1.8.1 What doesn't work on 1.0XO build 802: (all three of these fail with the above AttributeError) gtk.ver = 2.14.2 pygame.ver = 1.8.0 I looked into putting the pygame 1.9.1 on Build 802, but there were dependencies more than just SDL-devel, and I've still got the nagging feeling that I'm missing something simple (the test.activity was probably tested on build 802) Any insight, advice would be appreciated, George ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.orgSugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel http://lists.sugarlabs.org/listinfo/sugar-devel XoPhoto-2.xo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC] Better disk format for journal entries
Excerpts from Michael Stone's message of Sun Jun 27 05:06:31 +0200 2010: I've longed, for quite some time, for an encoding of Sugar's journal entries that is more amenable to manipulation with standard Linux tools and APIs. I've also longed for a format that is friendly to rainbow and which can encode both the data necessary for today's journal as well as the data necessary for Eben's Journal redesign mockups. If we are to introduce a new transport format for Journal entries, I'd much rather have us try to use one that's interoperable with other software. During past discussions on this list a few candidates were named (I don't have references handy, but the list archives should help locating them). As for changes to the data model: While the Journal obviously needs to change, I believe the current data store to be generic enough to store anything we're going to need for now. The object ids are globally unique and can thus be used for inter-object references. Actions can be stored in metadata-only entries. BTW: Can anyone provide me with a JEB (Journal Entry Bundle) that was created by existing software? I've changed Sugar to support multi-entry bundles (for high-level backups) and would like to verify existing ones still work. Already, I find it helpful both for browsing my DS with filesystem tools and for resuming activities from the Terminal. You might find datastore-fuse [1] useful as well. It's still experimental, but works well enough that I use it for transferring attachments from my MUA directly to the data store / Journal (which I use for managing photos besides other things). While it's still rather basic, it provides access to the full data store content (including metadata as extended attributes) with full read/write/delete support (data+metadata). What cool things can you think of to do with it? [1]: Links to my sugar git repo: http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz git://dev.laptop.org/users/mstone/sugar Could you be convinced to move your repositories to (or duplicate them on) git.sugarlabs.org? The advantage of the latter is that anyone could clone your repo(s) and thus get a public repository they can push to. (*) Creating the project and cloning it require using the web interface, but those are just one-time actions - the repositories themselves are regular git repos accessible via ssh, so they don't get into the way of everyday work. Sascha (*) This is also half of an answer to your mail re. rainbow patches: My repo is on my home server which only has a public IPv6 address, not an IPv4 one. I don't want to create a rainbow project on git.sugarlabs.org myself because it might look like the official one. [1] http://git.sugarlabs.org/projects/datastore-fuse signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Make initial DCON unfreeze conditional on the presence of a DCON.
Presently, Sugar tries to unfreeze the XO's secondary display controller (DCON) regardless of whether or not a DCON is present. This generates unsightly error messages every time Sugar starts. To fix the problem, we test for the presence of a DCON following the advice of http://wiki.laptop.org/go/DCON_Linux_Driver by testing for the existence of /sys/devices/platform/dcon. Cc: David Farning dfarn...@gmail.com Signed-off-by: Michael Stone mich...@laptop.org --- bin/sugar-session |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/bin/sugar-session b/bin/sugar-session index cc8358c..b4a68cc 100755 --- a/bin/sugar-session +++ b/bin/sugar-session @@ -240,7 +240,8 @@ def main(): # this must be added early, so that it executes and unfreezes the screen # even when we initially get blocked on the intro screen -gobject.idle_add(unfreeze_dcon_cb) +if os.path.exists(/sys/devices/platform/dcon): +gobject.idle_add(unfreeze_dcon_cb) intro.check_profile() -- 1.7.1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC] Better disk format for journal entries
On 27.06.2010, at 05:06, Michael Stone wrote: Folks, I've longed, for quite some time, for an encoding of Sugar's journal entries that is more amenable to manipulation with standard Linux tools and APIs. I've also longed for a format that is friendly to rainbow and which can encode both the data necessary for today's journal as well as the data necessary for Eben's Journal redesign mockups. A few days ago, I wrote a little bit about what I think such a format might look like over here: http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024908.html Unfortunately, this note didn't generate much of a response Duh! Who would have expected that the actual message went on below the top-reply and quote? Only someone who knew me and my shy, tentative ways. :) I have simply not seen it. Even glancing over it now it did not read like an actual proposal. That's because it was a musing, not a proposal. -- thus, to whet your appetite further, here's a (rough!) exporter from today's DS into the format sketched in that note, available both in the the patch following this note and in my combined sugar git repo [1] in the xos branch. Already, I find it helpful both for browsing my DS with filesystem tools and for resuming activities from the Terminal. What cool things can you think of to do with it? Regards, Michael [1]: Links to my sugar git repo: http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz git://dev.laptop.org/users/mstone/sugar I like the directory layout. Could you explain why you see a need for the generality of a custom ./resume script? I chose this approach mainly, for the sake of encapsulation and ease-of-use rather than for generality. Here's what I mean: a) if an activity session is represented as directory ./Photos+of+Butterflies_1a21458b then being focused on such a session corresponds to having a shell whose current working directory is the dir in question: ~/Photos+of+Butterflies_1a21458b $ ... b) if I want to resume the currently focused activity session dir, then there are three basic things I can imagine doing: 1) exec ./resume 2) exec sugar-resume 3) use IPC to tell some daemon to do one of the above. (1) is nicely language-agnostic, direct, and easy to test in isolation of other components. however, it is very opaque. (2) imposes some helpful consistency on how resumes happen at the cost of making it hard to experiment with new ways to implement resume. (3) is, in my experience, a pain. I picked (1) for my scheme because it seems better suited to my current goals. Further questions? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Make initial DCON unfreeze conditional on the presence of a DCON.
Excerpts from Michael Stone's message of Sun Jun 27 17:27:59 +0200 2010: Presently, Sugar tries to unfreeze the XO's secondary display controller (DCON) regardless of whether or not a DCON is present. This generates unsightly error messages every time Sugar starts. Does anyone use (or is going to use) OHM with Sugar 0.88? If not, we should just throw out this code - powerd doesn't provide the OHM API. Any future support for unfreezing the DCON should try to align to the Gnome way - IIRC they discussed sending a DBus signal once the desktop is uprunning (to which powerd could be listening); maybe they have specified or even implemented that by now. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Make initial DCON unfreeze conditional on the presence of a DCON.
On 27 June 2010 11:21, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Does anyone use (or is going to use) OHM with Sugar 0.88? If not, we should just throw out this code - powerd doesn't provide the OHM API. powerd could implement it trivially, and should. (with a simple binary using dbus activation) The lack of this functionality causes the XO-1 bootup sequence to be uncomfortably interrupted with a black screen when powerd unfreezes too early. We should fix this and I think the above approach is the best way. Any future support for unfreezing the DCON should try to align to the Gnome way - IIRC they discussed sending a DBus signal once the desktop is uprunning (to which powerd could be listening); maybe they have specified or even implemented that by now. This sounds like exactly what we have already. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC] Better disk format for journal entries
Excerpts from Michael Stone's message of Sun Jun 27 05:06:31 +0200 2010: I've longed, for quite some time, for an encoding of Sugar's journal entries that is more amenable to manipulation with standard Linux tools and APIs. I've also longed for a format that is friendly to rainbow and which can encode both the data necessary for today's journal as well as the data necessary for Eben's Journal redesign mockups. If we are to introduce a new transport format for Journal entries, I'd much rather have us try to use one that's interoperable with other software. You and I may simply have different ideas of what other software it is most important to interoperate with. For me, the relevant software includes: ls, cat, head, rm, cp, du, grep, find, rsync, vim, emacs, git, *httpd, and rainbow What software are you thinking of? During past discussions on this list a few candidates were named (I don't have references handy, but the list archives should help locating them). I googled for a bit but couldn't find your references. Could you be more specific with either search terms or links? As for changes to the data model: While the Journal obviously needs to change, I believe the current data store to be generic enough to store anything we're going to need for now. The object ids are globally unique and can thus be used for inter-object references. Actions can be stored in metadata-only entries. I appreciate your skill in encoding a more complex data model into the dark corners of the current DS API but I have to say that the encoding feels forced and, so far as I can tell, the resulting human factors still suck. No? Already, I find it helpful both for browsing my DS with filesystem tools and for resuming activities from the Terminal. You might find datastore-fuse [1] useful as well. It's still experimental, but works well enough that I use it for transferring attachments from my MUA directly to the data store / Journal (which I use for managing photos besides other things). While it's still rather basic, it provides access to the full data store content (including metadata as extended attributes) with full read/write/delete support (data+metadata). Thanks for the link. What cool things can you think of to do with it? [1]: Links to my sugar git repo: http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz git://dev.laptop.org/users/mstone/sugar Could you be convinced to move your repositories to (or duplicate them on) git.sugarlabs.org? I am far from convinced but, as a favor to you and Bernie, here is http://git.sugarlabs.org/projects/sugar/repos/mstone (and if you keep pestering me, then I might even manage to keep it synced for you...) This is also half of an answer to your mail re. rainbow patches: My repo is on my home server which only has a public IPv6 address This is not a problem: I already have IPv6 access both at home and through *.laptop.org and I am considerably interested [1] in helping more people to get it. I don't want to create a rainbow project on git.sugarlabs.org myself because it might look like the official one. Sascha, you're as much a rainbow maintainer these days as I am. Therefore, please go ahead and create it, push your patches to it, and let me know when you have patches that you want me to look at. Then we'll do a release and we'll move on to the next set of patches. Michael [1]: http://wiki.laptop.org/go/Network2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sugargame v1.1
== Sugargame == Sugargame is a Python package which allows [http://www.pygame.org/ Pygame] programs to run well under Sugar. It is fork of the olcpgames framework, which is no longer maintained. http://wiki.sugarlabs.org/go/Development_Team/Sugargame http://git.sugarlabs.org/projects/sugargame Sugargame v1.1 is a bug fix release: * Fix bugs in event handling. (Pablo Moleri) * Remove reference to gtk.Socket.get_window() method, which is missing in older versions of PyGTK. See the Wiki page for usage information and examples. Best, -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [GSoC] [Patch] Sugar Smolt Control Panel Integration
I've been working on an integration of Smolt (https://fedorahosted.org/smolt/) into Sugar as part of my GSoC. The purpose of this is to help us gather information about the hardware Sugar is running on, as well as to help users filing bug reports to simplify the process of providing said information to developers. The repository lives here (http://git.sugarlabs.org/projects/sugar/repos/sugar-smolt) and there's a ticket filed for review here (http://bugs.sugarlabs.org/ticket/949). It still needs a shiny icon, though, since we're using the not-very-sugar-like smolt icon right now - maybe somebody could help with that? I marked the ticket as r?, so a review would be appreciated, too. --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] [Patch] Sugar Smolt Control Panel Integration
Hi Sebastian, On 27 Jun 2010, at 20:07, Sebastian Dziallas wrote: I've been working on an integration of Smolt (https://fedorahosted.org/smolt/) into Sugar as part of my GSoC. The purpose of this is to help us gather information about the hardware Sugar is running on, as well as to help users filing bug reports to simplify the process of providing said information to developers. The repository lives here (http://git.sugarlabs.org/projects/sugar/repos/sugar-smolt) and there's a ticket filed for review here (http://bugs.sugarlabs.org/ticket/949). It still needs a shiny icon, though, since we're using the not-very-sugar-like smolt icon right now - maybe somebody could help with that? Just went icon hunting to see what the smolt icon currently is – best I could find digging through your git rep was this: inline: PastedGraphic-1.png Can you confirm if this is the smolt icon you're referring too? I couldn't see this on the fedora smolt page you linked to so am not sure if it's the right one. If it is the current smolt icon, do you know what it is meant to represent? Bunch of smiley people standing behind a Gregorian calendar representing the year the Vikings invade England? ;-p Could you grab a screen shot or two of how the CP module looks in Sugar? Regards, --Gary I marked the ticket as r?, so a review would be appreciated, too. --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Make initial DCON unfreeze conditional on the presence of a DCON.
Excerpts from Daniel Drake's message of Sun Jun 27 18:30:02 +0200 2010: On 27 June 2010 11:21, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Does anyone use (or is going to use) OHM with Sugar 0.88? If not, we should just throw out this code - powerd doesn't provide the OHM API. powerd could implement it trivially, and should. (with a simple binary using dbus activation) The lack of this functionality causes the XO-1 bootup sequence to be uncomfortably interrupted with a black screen when powerd unfreezes too early. No disagreement here. But if we touch the code (on the Sugar side), it should be to make it more hardware-agnostic, not less. While OHM itself is XO-specific, any software can implement its API. Adding a check for a sysfs file restricts the functionality to the XO hardware. For reference: Gnome-session (version 2.30) sends a SessionRunning signal [2] to the D-Bus session bus [1]. Ubuntu 10.04 uses GDM scripts to emit an Upstart signal: r...@elaine:/# tail -n 1 /etc/gdm/PreSession/Default /sbin/initctl -q emit desktop-session-start DISPLAY_MANAGER=gdm Sascha [1] http://live.gnome.org/SessionManagement/GnomeSession#Relationship_to_D-Bus_Session_Bus [2] http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager::SessionRunning [3] http://ubuntuforums.org/archive/index.php/t-1299587.html -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] [Patch] Sugar Smolt Control Panel Integration
On Sun, Jun 27, 2010 at 8:33 PM, Gary Martin garycmar...@googlemail.com wrote: Hi Sebastian, On 27 Jun 2010, at 20:07, Sebastian Dziallas wrote: I've been working on an integration of Smolt (https://fedorahosted.org/smolt/) into Sugar as part of my GSoC. The purpose of this is to help us gather information about the hardware Sugar is running on, as well as to help users filing bug reports to simplify the process of providing said information to developers. The repository lives here (http://git.sugarlabs.org/projects/sugar/repos/sugar-smolt) and there's a ticket filed for review here (http://bugs.sugarlabs.org/ticket/949). It still needs a shiny icon, though, since we're using the not-very-sugar-like smolt icon right now - maybe somebody could help with that? Just went icon hunting to see what the smolt icon currently is – best I could find digging through your git rep was this: Can you confirm if this is the smolt icon you're referring too? I couldn't see this on the fedora smolt page you linked to so am not sure if it's the right one. If it is the current smolt icon, do you know what it is meant to represent? Bunch of smiley people standing behind a Gregorian calendar representing the year the Vikings invade England? ;-p The main smolt website is at http://www.smolts.org/ and I couldn't see a logo there at all. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Make initial DCON unfreeze conditional on the presence of a DCON.
daniel wrote: On 27 June 2010 11:21, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Does anyone use (or is going to use) OHM with Sugar 0.88? If not, we should just throw out this code - powerd doesn't provide the OHM API. powerd could implement it trivially, and should. (with a simple binary using dbus activation) i agree. i'd welcome a powerd patch for this -- i think it would take the form of a helper executable that listened for dbus control messages, and informed powerd via its usual event mechanism. The lack of this functionality causes the XO-1 bootup sequence to be uncomfortably interrupted with a black screen when powerd unfreezes too early. We should fix this and I think the above approach is the best way. in the short term the timer that powerd currently uses could be adjusted, but clearly that's not a real solution. Any future support for unfreezing the DCON should try to align to the Gnome way - IIRC they discussed sending a DBus signal once the desktop is uprunning (to which powerd could be listening); maybe they have specified or even implemented that by now. This sounds like exactly what we have already. except that the the current calls are pretty ohm-specific, aren't they? (i haven't looked at them in a while.) paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Make initial DCON unfreeze conditional on the presence of a DCON.
El Sun, 27-06-2010 a las 18:21 +0200, Sascha Silbe escribió: Excerpts from Michael Stone's message of Sun Jun 27 17:27:59 +0200 2010: Presently, Sugar tries to unfreeze the XO's secondary display controller (DCON) regardless of whether or not a DCON is present. This generates unsightly error messages every time Sugar starts. Does anyone use (or is going to use) OHM with Sugar 0.88? If not, we should just throw out this code - powerd doesn't provide the OHM API. This explains why I get this error also on the XO-1 :-) We switched to powerd over one month ago and I doubt we or OLPC will ever want to go back. In other words, a patch to throw away the OHM support would be indeed welcome! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add ds2xos conversion script to export journal entries as .xos session dirs.
El Sat, 26-06-2010 a las 23:07 -0400, Michael Stone escribió: * whose name is URL-encoded with spaces encoded as pluses Why pluses? Can't we simply leave spaces as spaces? Or convert them to '_' and use '~' or ';' as a version separator? I like the idea, but I would also like to see a Journal feature for exporting objects to removable volumes without loosing their accompanying metadata. Do we preserve metadata on file transfers? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] reschedule when? How Cellular Data can Reach *Distant* Schools [was: 5 upcoming Sunday talks/events for OLPC volunteers]
Please RSVP if you helped with Latin America's / Sugar's friendly new 3G My Settings option -- letting me know which days you can join our meeting over IRC and/or ideally phone! (As glitches canceled today's 4PM talk below, and rescheduling is a challenge with Sundays pre-booked every week with other talks below into August; but on the bright side our Canadian speaker suggests rescheduling for Sunday July 4th, 4PM -- as 4G would be a great subtopic in true celebration of that All-American July FOURth holiday :) Caryl Bigenho wrote: Hi Nancie and all... Sounds like a great device. However, here in Montana the only 3G network we have is Verizon. ATT doesn't have it here (thus an iPhone is not very worthwhile here). ATT was here, pulled out was replaced by Alltel which is now being taken over by ATT! (Which still doesn't have 3G service here much less 4G). There is no Sprint at all. I guess with under 1 million people and the largest city about 100,000 Montana doesn't rank very high with the tech companies. We have no cable TV where I am, thus no cable internet connection either. We do have a great rural company with broadcast towers for internet with antennas (antennae?) on our houses. Works great until a thunder storm causes a power outage. TV... nothing local... too many mountains. We have Direct TV no locals available. Dish Network offers Billings MT locals. I was looking forward to today's talk because I can really relate to the problems of people who live in rural areas! Caryl From: olpc.dri...@hotmail.com To: support-g...@lists.laptop.org Date: Sun, 27 Jun 2010 16:42:34 -0400 Subject: Re: [support-gang] 4PM Talk Today: How Cellular Data can Reach *Distant* Schools [was: 5 upcoming Sunday talks/events for OLPC volunteers] Hi. Sorry to hear that today's call had to be postponed. The subject is very interesting. I am happy to report that last week while traveling in the US with my XO, someone had a new wireless Internet device from Sprint. She said that with her monthly service account, she could connect up to 9 computers to the Internet. The small device just sits on the table. Soon, Sprint will have a phone with this capability built in. You can set your phone on the table and connect the computers to 3 G service. Of course I tried connecting my XO-1. It works!! I easily found her network in the neighborhood. I had to try to connect several times with different configurations for the password. I don't know which one worked, but one did. If another opportunity to use this presents, I'll be careful to note the correct settings for the entering the password. Bottom line is, yes, this technology can connect our remote small deployments to the Internet. Ha Long Bay, Vietnam, I hope the internet is coming your way soon! Nancie:) Date: Sun, 27 Jun 2010 16:19:26 -0400 From: h...@laptop.org To: support-g...@laptop.org CC: xdmc...@hotmail.com; andigro...@googlemail.com Subject: Re: [support-gang] 4PM Talk Today: How Cellular Data can Reach *Distant* Schools [was: 5 upcoming Sunday talks/events for OLPC volunteers] O dear, o dear-- 1) Our conf call service is no longer working 2) The building was shuttered due to construction. Will try to reschedule soon! Presentation attached: Hope to see you in just under 1.5hrs, in person or on the phone! /All presentations Sunday 4PM Boston/Eastern Time, unless otherwise noted. Calls should be short (15min talk, 15min QA) -- alongside any insider OLPC scoop I can possibly provide you, to help all volunteers do their very best:/ *Sunday June 27 - How Cellular Data can Reach *Distant* Schools* By Roger Glasel, CEO eeZee Communicarions Inc, http://www.eezee.ca /Clarif:/ many of us will gather 4PM (SHARP) at OLPC's office in Cambridge, Massachusetts to listen to Roger present his slides from Edmonton, Alberta. Sorry doors are locked after 4PM -- RSVP if you will attend in person! Roger will explain how you can put your school online, even if you live in a remote area just outside the reach of your cellphone's normal calling areas. The technology does not require the cellphone company advance permission, and requires only a $700-$2500 device that dramatically boosts your regular cellphone data plan's signal, using all modern protocols: http://en.wikipedia.org/wiki/3G http://en.wikipedia.org/wiki/4G *Sunday July 11 - Virtual Field Trip Realness (Classrooms ain't in Kansas Nomore)* By Laura Susan Bell, Virtual Field Trip Facilitator OLPC Support Volunteer. Laura will explain how she administers classrooms in Upper
Re: [Sugar-devel] [PATCH] Add ds2xos conversion script to export
El Sat, 26-06-2010 a las 23:07 -0400, Michael Stone escribió: * whose name is URL-encoded with spaces encoded as pluses Why pluses? Because they're nicer than %20 and python provides urllib.quote_plus? Can't we simply leave spaces as spaces? Have you got a shell that doesn't require me to escape them in order to process the resulting files? Or convert them to '_' and use '~' or ';' as a version separator? Thanks; I prefer characters which don't need to be shell-escaped. I like the idea, but I would also like to see a Journal feature for exporting objects to removable volumes without loosing their accompanying metadata. I don't understand this suggestion; could you please rephrase it? Thanks for your thoughts, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add ds2xos conversion script to export
El Sun, 27-06-2010 a las 21:53 -0400, Michael Stone escribió: Can't we simply leave spaces as spaces? Have you got a shell that doesn't require me to escape them in order to process the resulting files? Are we optimizing for shell convenience over desktop convenience? Or convert them to '_' and use '~' or ';' as a version separator? Thanks; I prefer characters which don't need to be shell-escaped. Ok, how about using _ for space and + to separate the version? I think that pluses in place of spaces really look ugly. I like the idea, but I would also like to see a Journal feature for exporting objects to removable volumes without loosing their accompanying metadata. I don't understand this suggestion; could you please rephrase it? When children copy a journal entry to a USB stick, the notes and tags are lost. Children often use USB sticks to interchange data or to preserve documents (apparently the Journal still has frequent data losses). In the future, we could think of a Journals everywhere feature: let children initialize any removable media as a secondary journal. Pie in the sky: mount your journal from the xs using fish or nfs. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add ds2xos conversion script to export
On Sun, Jun 27, 2010 at 9:53 PM, Michael Stone mich...@laptop.org wrote: El Sat, 26-06-2010 a las 23:07 -0400, Michael Stone escribió: * whose name is URL-encoded with spaces encoded as pluses Why pluses? Because they're nicer than %20 and python provides urllib.quote_plus? Can't we simply leave spaces as spaces? Have you got a shell that doesn't require me to escape them in order to process the resulting files? Or convert them to '_' and use '~' or ';' as a version separator? Thanks; I prefer characters which don't need to be shell-escaped. FWIW: shell will only expand ~ in first position; a~b is fine. using ; as a version separator has a long and distinguished history (http://en.wikipedia.org/wiki/Files-11) anyone who hasn't figured out how to use -0 options to grep, xargs, find, etc in order to properly handle spaces is living in the past filenames in spanish will look terrible with %-escapes for áéíñóú anyway, and utf-8 is not reliable on FAT (sigh). if you can get people to format their USB sticks with NTFS, whose kernel support is pretty good, you can use utf-16 and a much smallest set of bad codepoints. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add ds2xos conversion script to export
Scott wrote: On Sun, Jun 27, 2010 at 9:53 PM, Michael Stone mich...@laptop.org wrote: El Sat, 26-06-2010 a las 23:07 -0400, Michael Stone escribi=C3=B3: * whose name is URL-encoded with spaces encoded as pluses Why pluses? Because they're nicer than %20 and python provides urllib.quote_plus? Can't we simply leave spaces as spaces? Have you got a shell that doesn't require me to escape them in order to process the resulting files? Or convert them to '_' and use '~' or ';' as a version separator? Thanks; I prefer characters which don't need to be shell-escaped. FWIW: shell will only expand ~ in first position; a~b is fine. using ; as a version separator has a long and distinguished history (http://en.wikipedia.org/wiki/Files-11) Good points. Thanks. anyone who hasn't figured out how to use -0 options to grep, xargs, find, etc in order to properly handle spaces is living in the past Null-separation works well with find and xargs and not-so-well with pretty much everything else, no? filenames in spanish will look terrible with %-escapes for I've been thinking about this for a while but I don't see any easy solutions. (Other than saying screw it; let's go with Plan 9...) Is this: http://tools.ietf.org/html/rfc3987 still your recommended reading? anyway, and utf-8 is not reliable on FAT (sigh). if you can get people to format their USB sticks with NTFS, whose kernel support is pretty good, you can use utf-16 and a much smallest set of bad codepoints. My main goal was to produce directory names that are a) fully determined by the activity metadata, b) vaguely human readable, and c) shell-friendly from whatever crap I'm handed. My further thought was that smarter viewers like the Journal would use the authoritative data in the .xos/metadata.json to figure out how to render the session. Regards, and thanks very much for your comments, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
