Re: Mini-conference schedule
I imagine it would be interesting to the devel and sugar lists to hear a summary of your observations in the kindergarten classroom as well. -walter 2008/4/2 Carol Lerche [EMAIL PROTECTED]: For the hangers-on such as myself, it wouldn't be necessary to have a video record if that's too difficult...an audio recording plus slideware might be just fine. (Personally, I am watching XOs be used in a kindergarten tomorrow and Friday, as I have been all week, and will be greatly appreciative of any record that might be feasible of these discussions.) On Wed, Apr 2, 2008 at 3:30 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On undefined, Martin Langhoff [EMAIL PROTECTED] wrote: I will join in for Friday afternoon over the phone., and will send an outline of my XS notes beforehand. Will we use the conferencing rig? I assume so; I'm checking with Kim; will send email. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Always do right, said Mark Twain. This will gratify some people and astonish the rest. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1823
Marco Pesenti Gritti wrote: On Thu, Apr 3, 2008 at 2:26 AM, Build Announcer v2 [EMAIL PROTECTED] wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1823 Changes in build 1823 from build: 1821 Size delta: -0.40M -sugar 0.75.14-1.olpc2 +sugar 0.79.2-1.olpc2 +sugar-toolkit 0.79.1-1.olpc2 -vte 0.16.9-1.fc7 And we forgot to make a new sugar-artwork package with the latest icons. I will have a look. Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs (or lack thereof)
On Thu, Apr 3, 2008 at 5:13 AM, Wade Brainerd [EMAIL PROTECTED] wrote: I wonder if the differences between Sugar and a regular window manager aren't so severe that it might be worth offering a simple desktop environment which runs within Sugar as a Activity? You would download and launch this Activity, and its interface would be a regular Linux desktop. It would support multiple windows, a taskbar, a start menu, etc. (I'm using Windows terms here). You could install and launch regular GTK+ applications in it, and they would not need to be sugarized at all. The GTK theme used by the Desktop would still match Sugar of course. If we did this, we would not be stuck with trying to shoehorn third party applications into a UI they were not designed for (one toplevel window, no menus) and would conceivably be able to launch any Linux app assuming the needed libraries were installed. I'm not an X windows expert, but does this sound like possible way to solve this issue? Someone wrapped Xephyr in an activity, so you get something similar to the Classic environment in OSX. You could run a full gnome or a single application inside that activity. But then the application would run in a different X server and wouldn't be able to copy paste, drag and drop, wouldn't be able to use hw acceleration, etc. Anyway, the problem here are not accidental incompatibilities as would be trying to run a KDE app in a GNOME-only installation. It was decided to part from the traditional desktop scheme because we aimed to offer a system that supports education, not office work. And I don't think that we should try to shoe-horn applications into activities. If an application's architecture separates the controller from the view and thus can expose a simple view component without controller stuff, then it's a relatively easy effort to wrap that view inside a widget and provide python bindings. Thus kids can modify and adapt all the python code around that black box immediately after receiving the XO. Regardless of that, I can understand how current application authors may feel frustrated by the additional effort required to port apps to activities, and of course welcome any contribution to make that easier. Apart from the debate of being easier or not to port apps with one or another architecture, I would like to point out the fact that if the project reaches its goals for the next year, there should be more developers for our platform than for Maemo or even the whole GNOME. So it's not like we are Apple, we'd have a much bigger potential in the not so long term. Also, GNOME apps are currently encouraged to provide those embeddable view widgets, as today do Abiword, Evince, Mozilla,... because of the GNOME Mobile initiative. Heard that someone was working on that for Gnumeric and I'd bet wouldn't be that hard for Inkscape. My point is that reusing all that code inside proper activities is not so hard, there are just too little hands yet. Please don't interpret my words as an opposition to increase compatibility with existing applications, take it as one more point of view on the problem. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: any drawbacks to using copy-nand and save-nand to install XO images
sorry for the week late reply, was busy w/ teacher training Michael Stone wrote: A much better strategy is to reflash an XO, boot it off of external media (like a USB key), make changes to the NAND, then save-nand, thus avoiding the first-boot configuration junk. Let me make sure my linux-n00b mind understands this correctly. I should boot off of a bootable usb of other distro, access the filesystem, make the changes I need, shut everything down, and then save-nand? sounds great, except I have always had a lousy time making usb sticks bootable. maybe I'll get it write this time. thanks again, Bryan OLE Nepal ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: quick mini-conference update.
Ok, hopefully that can be discussed at the mini-conf, which I still can't attend...good to get on the plan for the more planned one at end of may...probably best if led from the paid OLPC staff side, right? Jon On Wed, 2008-04-02 at 13:07 -0400, C. Scott Ananian wrote: Hey, folks. I've been sick for the past two days, so I apologize for not doing as much mini-conference planning as I might have. We're still on for tomorrow and Friday, at 1cc, although our mini-conference might be somewhat scaled down from its original proposal -- I certainly won't be able to do as many presentations as I might have liked to, although I hope that the rest of you have had some chance to organize your thoughts in preparation, despite my silence. I fully support the plans for a proper *real* conference, as someone proposed for the end of May, but I still think this mini-conference will be useful. We can't really afford to wait two months to decide what the 4 full-time developers at 1cc will work on, so the mini-conference will be useful even if it's just us 4 in a room. I'd appreciate help planning a real conference for later. I'll be posting another message later with a tentative schedule for thurs/fri talks. Please let me know privately (if you haven't already) whether you've got time constraints. Also, I'm not certain I've got someone who's committed to helping out with audio/video recording: I'll use Record on the XO if I need to, but we all know what that looks like; it might not be the most pleasant to watch. Also I'll need to hack out Record's time limit (trac #4983). Again, my apologies for the slip-shod organization, but I hope even informal meetings will be useful (especially if we can post recordings). --scott -- Jon Phillips San Francisco, CA CHINA PH +86 1-360-282-8624 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat, Skype: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] Projects: http://rejon.org/projects ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: quick mini-conference update.
On Wed, Apr 2, 2008 at 11:51 PM, Jon Phillips [EMAIL PROTECTED] wrote: can't attend...good to get on the plan for the more planned one at end of may...probably best if led from the paid OLPC staff side, right? No, it's actually best if we get significant community help planning events like these. OLPC has a very limited number of core developers (although we'll be hiring more in the coming months) and anything that lets them *actually code XO software* instead of doing other stuff is Greatly Appreciated. Just to be clear: PLEASE SOMEONE HELP ORGANIZE if you want a larger conference in a few months. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mini-conference schedule
No changes have been needed to the schedule (yet). I've posted it on the wiki at: http://wiki.laptop.org/go/Mini-conference Remember, the call-in number is: From the United States 866-213-2185 From Outside the United States 1-609-454-9914 accesscode: 8069698 and there will be real-time chat in #olpc-devel on irc.oftc.net. Video details in the morning. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless Congestion Management Option
On Apr 2, 2008, at 5:24 PM, John Watlington wrote: Meshes of access points don't tend to change topology over time. The laptop mesh very well might. The need to handle this is one of the problems causing congestion. Anybody find new algorithms for mobile meshes ? As well there are plenty - even to many - new algorithms out there! So, no shortage of those. But... most are not tested in practice. AFAIK the current trends go more into finding the proper metric . At www.olsr.org we currently work at implemting ETT metric (and maybe MIC). This will have a very nice effect on meshes since the routes will be chosen also on thruput and interference avoidance. That especially the last point is very very crucial with anything concerning wifi. best, a. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1824
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1824 Changes in build 1824 from build: 1823 Size delta: 0.14M -gstreamer 0.10.12-1.olpc2 +gstreamer 0.10.15-1.olpc2 -gstreamer-plugins-base 0.10.12-4.2.olpc2 +gstreamer-plugins-base 0.10.15-1.olpc2 -gstreamer-tools 0.10.12-1.olpc2 +gstreamer-tools 0.10.15-1.olpc2 -sugar-artwork 0.40-1 +sugar-artwork 0.79.1-1 --- Changes for gstreamer 0.10.15-1.olpc2 from 0.10.12-1.olpc2 --- + #4827: gstreamer 0.10.15 built against F7 by daf --- Changes for gstreamer-tools 0.10.15-1.olpc2 from 0.10.12-1.olpc2 --- + #4827: gstreamer 0.10.15 built against F7 by daf --- Changes for sugar-artwork 0.79.1-1 from 0.40-1 --- + Frame/Home redesign - Put corner stone -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New faster build 1824
http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1824 Changes in build 1824 from build: 1822 Size delta: 0.39M -gstreamer 0.10.12-1.olpc2 +gstreamer 0.10.15-1.olpc2 -gstreamer-plugins-base 0.10.12-4.2.olpc2 +gstreamer-plugins-base 0.10.15-1.olpc2 -gstreamer-tools 0.10.12-1.olpc2 +gstreamer-tools 0.10.15-1.olpc2 -sugar-artwork 0.40-1 +sugar-artwork 0.79.1-1 --- Changes for gstreamer 0.10.15-1.olpc2 from 0.10.12-1.olpc2 --- + #4827: gstreamer 0.10.15 built against F7 by daf --- Changes for gstreamer-tools 0.10.15-1.olpc2 from 0.10.12-1.olpc2 --- + #4827: gstreamer 0.10.15 built against F7 by daf --- Changes for sugar-artwork 0.79.1-1 from 0.40-1 --- + Frame/Home redesign - Put corner stone -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs
On Thu, Apr 3, 2008 at 3:45 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Perhaps, in the intervening decade, first-world computer users have convinced themselves that they cannot adapt, but they are wrong. Humans are very adaptable. A teacher who has learned one version of Sugar will not have to spend more than a few days or hours with the new version before understanding it. I'm sure they can adapt, but they need to be motivated to do so. What could happen if we don't make sure these changes are well-received? I think that's Gregorio's message. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs
Let me ad that these changes are motivated from feedback in the field. What we are trying to change are precisely the things that people are finding confusing or difficult. Let me further add that very little teacher training has in fact taken place. What we have instead concentrated on is working with teachers on how to best leverage to tool to enhance learning inside and outside of the classroom. The very features of the new interface are designed to facilitate more collaboration, which is *the* distinguishing feature of Sugar. -walter On Thu, Apr 3, 2008 at 9:59 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Thu, Apr 3, 2008 at 3:45 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Perhaps, in the intervening decade, first-world computer users have convinced themselves that they cannot adapt, but they are wrong. Humans are very adaptable. A teacher who has learned one version of Sugar will not have to spend more than a few days or hours with the new version before understanding it. I'm sure they can adapt, but they need to be motivated to do so. What could happen if we don't make sure these changes are well-received? I think that's Gregorio's message. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [sugar] Mini-Conference Proposal: Toolbars Tabs
Hi All, I'm not opposed to changing the GUI at the OS level. I can think of a dozen suggestions starting with that annoying hot corners thing. I also love a whole bunch of the design elements. All I'm saying is that any change comes at a cost. A cost paid by the teachers, students and people who train more than the developers. The cost also increases with time. I want to make sure you take that in to consideration. I'm not talking about the time OLPC has spent training people. I'm talking about the time sys admins and technicians have spent training teachers in country. Dozens of people spent days doing teacher training in Uruguay and they said it took several days of training for the teachers to start feeling comfortable with the XO. I believe new teams of volunteers in Uruguay have recently been expanding the training. Nepal also started teacher training and they reported that it's a key variable to their success. I think I heard that Peru has started training a few hundred teachers too. I'm not sure about other deployments. If the teachers and trainers know what the changes are, they want them and are not concerned about having to re-learn or re-train, then its fine with me. My point is to keep the users in the loop. If you dictate changes without user input that doesn't foster collaboration and empowerment. Sounds like you have the users in the loop and you're covered. Great! You definitely did a lot of things right in the first pass. I'm sure you'll nail it again in the next revision. My only suggestion is that once you have a new design, you show it to some teachers and trainers before you lock it down. Even better give them a range of options and see which works best for them. There's a technical, economic, cultural, urban - rural, north - south divide that we have to span here. That comes to the fore in the GUI more than anywhere else (except maybe available actvities). Let's not lose our chance to make the design process a two way collaboration which bridges that divide. Thanks, Greg S -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Walter Bender Sent: Thursday, April 03, 2008 10:07 AM To: Tomeu Vizoso; [EMAIL PROTECTED]; devel@lists.laptop.org; Greg Smith (gregmsmi) Subject: Re: [sugar] Mini-Conference Proposal: Toolbars Tabs Let me ad that these changes are motivated from feedback in the field. What we are trying to change are precisely the things that people are finding confusing or difficult. Let me further add that very little teacher training has in fact taken place. What we have instead concentrated on is working with teachers on how to best leverage to tool to enhance learning inside and outside of the classroom. The very features of the new interface are designed to facilitate more collaboration, which is *the* distinguishing feature of Sugar. -walter On Thu, Apr 3, 2008 at 9:59 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Thu, Apr 3, 2008 at 3:45 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Perhaps, in the intervening decade, first-world computer users haveconvinced themselves that they cannot adapt, but they are wrong. Humansare very adaptable. A teacher who has learned one version of Sugar willnot have to spend more than a few days or hours with the new versionbefore understanding it. I'm sure they can adapt, but they need to be motivated to do so. What could happen if we don't make sure these changes are well-received? I think that's Gregorio's message. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mini-Conference Proposal: olpcfs
On Wed, Apr 2, 2008 at 7:42 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 11:44 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Mar 24, 2008 at 5:35 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Delta-based storage is an implementation detail, certainly possible (I provided cites in the olpcfs page for how it would be done). I don't think it should be a visible part of the API. Of course it is an implementation detail, but one that is a major roadblock in the effort to implement the specified design. The olpcfs design envisions a user-space process to do garbage collection of old versions; it's not hard to do delta-compression in userspace. xdelta and bsdiff do a fine job. To transparently uncompress when the old version is accessed is only a little more difficult, you just link to libxdelta2. Wonderful. - get a saner way of passing files from activity side to the DS-managed side, My answer here: they are just files. All existing applications can open files, given a path. I was talking here about the other way, checking in files into the DS: during a Write session, what needs to do the activity in order to get a new version every time after the user clicks on the Keep button? Just close the file and open it again? Yes. Cool. In most cases, every time an activity saves the current state several files plus their metadata will be updated, can that happen atomically? Well, it's certainly *possible* in the current implementation, but I'm wary of promising too much. POSIX generally doesn't provide multi-file atomic update. Amino (http://www.fsl.cs.sunysb.edu/docs/amino-phdthesis/amino.ps) extended ACID transactions to POSIX-land via some heuristics (treat all operations by this application as atomic, etc), but I'm not convinced yet that this is necessary. Can you provide some specific use examples? I guess we only need metadata updates to be atomic. I'm thinking specifically on the journal, as it displays the entries depending on the metadata, would be good if the journal only tried to refresh its display when the update has finished. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1825
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1825 Changes in build 1825 from build: 1824 Size delta: 0.52M +vte 0.16.9-1.fc7 +python-simplejson 1.7.3-1.fc7 -sugar-toolkit 0.79.1-1.olpc2 +sugar-toolkit 0.79.2-1.olpc2 -Chat 36 +Chat 37 --- Included vte version 0.16.9-1.fc7 --- --- Included python-simplejson version 1.7.3-1.fc7 --- --- Changes for Chat 37 from 36 --- + UI Change: Merge multiple sequential messages from same author (morgs) + Updated translation: ar (pootle) + #6561: Fix RTL message alignment (Arabic) (khaled) -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] Remove Ctrl-O (the letter oh) keyboard shortcut to fix #4646
From: Martin Dengler [EMAIL PROTECTED]
---
src/view/keyhandler.py |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 82b6b1c..b14d27d 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -61,7 +61,6 @@ _actions_table = {
'ctrlEscape' : 'close_window',
'ctrlq': 'close_window',
'0xDC' : 'open_search',
-'ctrlo': 'open_search',
'alts' : 'say_text'
}
--
1.5.4.1
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] Remove Ctrl-O (the letter oh) keyboard shortcut to fix #4646
Eben are you ok with this?
On Thu, Apr 3, 2008 at 8:37 PM, [EMAIL PROTECTED] wrote:
From: Martin Dengler [EMAIL PROTECTED]
---
src/view/keyhandler.py |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 82b6b1c..b14d27d 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -61,7 +61,6 @@ _actions_table = {
'ctrlEscape' : 'close_window',
'ctrlq': 'close_window',
'0xDC' : 'open_search',
-'ctrlo': 'open_search',
'alts' : 'say_text'
}
--
1.5.4.1
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
New faster build 1825
http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1825 Changes in build 1825 from build: 1824 Size delta: 0.52M +vte 0.16.9-1.fc7 +python-simplejson 1.7.3-1.fc7 -sugar-toolkit 0.79.1-1.olpc2 +sugar-toolkit 0.79.2-1.olpc2 -Chat 36 +Chat 37 --- Included vte version 0.16.9-1.fc7 --- --- Included python-simplejson version 1.7.3-1.fc7 --- --- Changes for Chat 37 from 36 --- + UI Change: Merge multiple sequential messages from same author (morgs) + Updated translation: ar (pootle) + #6561: Fix RTL message alignment (Arabic) (khaled) -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
On Thu, 3 Apr 2008, Aaron Huslage wrote: How do currently available commercial wireless topology mappers do this? I don't have direct experiance (the brother of a friend goes around installing these things, so my knowledge is third hand) but my understanding is that they deploy their access points and they triangulate the location of the wireless devices with a minimum of three access points deployed (more if more coverage is needed). I know that calibration is needed (something like walking the building with a known laptop after it's setup) radio direction finding to get a bearing from two antennas is not bleeding edge technology. It can require specialized hardware, but not always. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
new sugar work into joyride
Hi all, the last joyride build (1825) includes a big part of the shell redesign explained in http://wiki.laptop.org/go/Designs. What you can see today in the builds is what most probably will go into update.2, but there's still lots of work to do in completing the specifications, some code refactoring and fixing bugs. So, try it if you want, but refer to the wiki for the final design. Many of the smaller pieces are still missing. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Automatic transfer/update of activities on the mesh
OK, the mini-conference happened - thanks for trying to let off-siters like me participate. Here's the Gobby doc which resulted, below are my post-meeting comments: Activity sharing: * Should we show people what the size/download time for a package is before d/l? * We might download something more readily if it's coming from a friend. * Michael: Trusting a friend isn't the same as trusting code coming from that friend. Ben: The only security question is whether it's safe to *replace* an activity with a new one. Bitfrost guarantees that running untrusted code is safe. Scott: You can always modify code, but you have to give it a new name. Michael: Making something default is a separate UI action from downloading it. Should distinguish between activities by their hashes; version numbers shouldn't be used for equality. homunq: unsigned versions should obviously not get the same preference directory. proposals for naming: * centralized registry, e.g. microsoft.com * mstone: first person to get there owns the space (and others get another version of %s) * each activity has a random guid for same activity and ... http://wiki.laptop.org/go/Talk:Activity_bundles#A_proposal_for_Activity_Signing How to put related activities together? * group by tag * add prefix in name, sort by name * group by magic sortkey tag decision: A and/or B as author decides. SJ: Attach names to the inherent identity of an activity .. okay, SJ can type what he meant ;-) I make a new activity, *E*. It gets a ¨unique¨ id, E.id and a ¨pretty unique¨ package name, ¨E¨. ¨E¨ is the friendly name you use locally to identify the activity. There is also a pretty name ued in interfaces, which is ¨E!¨ this can be translated, changed from version to versiion. when I join a larger group that has some other activity named E, I should change my public activity-name (andraelly should change the display name). Everyone can see that my ¨E¨ is differnet from the existing one, since they have different unique IDs, but to supprot simple intreface-driven updates and version selection, the friendly package name should change. aside: there is some confusion about the hisotrical and practical use of sortkeys. this is some piece of metadata that an author can acontribuet, which will help to sort a cluster of related activities with one another. similarly, which activities appear nextto which other ones in the circle view is improtnt. note - this is NOT aout ¨favorites¨. Grouping Version Identity P10 X \- P 9 O -- change in ownership N 8 X \- N 7 X Eben: Use tags to support grouping, e.g. tamtam or mamamedia or draw Scott: Localisation of tags is hard. note : having ¨signed¨ versions of activities, and the ecure model, is not necesarily relevant to lots of activities and use caes. we should support identifying versions that claim to e of the same underlying activity, and claimed merges and forks, without worrying about keys and signing. THINGS ABOUT WHICH THERE IS NOT CONSENSUS. how to bulk update a set of activities soeveryone in a room has the same version update on share? is this a good idea? how would it work in ui? push updates - is this a good idea? how would it work? My post-meeting comments: 1. for version threading, what we need for an activity is not a claim like I am a version of activity ID but My prior version was XXX and the one before that was YYY. What is the granularity of XXX and YYY? I'd say, a hash on the activity.info would be fine - that way, version changes are automatically picked up, but not every change in the source code. If, later, activity.info picks up some elements which are too volatile (thus leading to unnecessarily-long geneologies), we could filter those out before hashing. Note that this is totally orthogonal to whether an activity version is signed by the original devteam, and yet allows for forks to become independent without fighting over who is the real pippy org.laptop.XYZ1FFE3. I submit that merges are unnecessary. 2. If we get the version threads right, then the auto-update on sharing becomes safer. I still don't understand who has to sign to avoid a break in the ownership chain - I would presume a given set of maintainer/developers, and I would presume that there would be some way for the group to change over time - but those details can be worked out. 3. For push updates and school versions, I would presume you'd in some manner beyond the scope of this discussion get an xo bundle (or a bundle of bundles), the only problem here is how to install it and mark it as the official school version. Stated like that, it seems to be obviously a problem of tagging. How do you securely tag documents you receive from external sources? I'd say that only signed tags should be allowed to move from one XO to another, and that it should be possible to have a filter which automatically pushes
Re: [sugar] new sugar work into joyride
Tomeu wrote the last joyride build (1825) includes a big part of the shell redesign explained in http://wiki.laptop.org/go/Designs. I'm running Joyride 1825 now on my G1G1. The principal difference I've noted is in my use of the Home view - now that the currently running activities are depicted in the Frame, I no longer need to press F3 when I want to return to a running Activity by clicking on its icon. There is a learning curve involved with the revised Home view (F3). It took me a while to realize that NOTHING appears in the circle view of launchable Activities until I have gone into the list view and marked the star on each desired Activity. And then it took a while more to realize that if I clicked within the Home view (as opposed to on the Frame) on the icon of an already-running Activity, a NEW INSTANCE of that Activity would be launched. [The small icon (in the graphic F3) for most recent Activity is the only icon within the Home view that provides a 'Resume' option.] In the list view of available Activities, I can't press PgUp PgDn to scroll - to view the whole list, I have to laboriously click (or drag) the scrollbar. Also, in that list I can only click on the icon to launch that Activity -- it would require less positioning if I were able to select a whole line and click anywhere within it. [I dual-boot between Joyride and Update.1. It amuses me that the list of launchable Activities includes both those installed by Joyride (in /usr/share) and those I manually installed for Update.1 (in /home/olpc). If the same Activity is installed both places, seems like I get to choose which version to launch.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
Let's not forget that you need some fixed reference points. In commercial systems, the locations of the access points are well known. In ad-hoc networks the best that you can hope for is a topological map. M. [EMAIL PROTECTED] wrote on 04/02/2008 01:45:14 AM: Ryan, Like Ben said, inducing the physical layout of the network from metrics such as RSSI will give you poor results for various reasons. What Space did was to average arrival rates from direct neighbors over a long period of time (anywhere between 1 and 10 seconds) to avoid highly temporal effects like multipath and noise. Even so, the result is only a rough layout of the network. If you'd like to achieve better accuracy I thing you should combine other ideas like sound measurements, as Ben suggested. Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
On Thu, 3 Apr 2008, Michail Bletsas wrote: Let's not forget that you need some fixed reference points. In commercial systems, the locations of the access points are well known. In ad-hoc networks the best that you can hope for is a topological map. the assumption was that the measurements are being done from fixed points. either the school server antenna locations, or the known locations of specific assistant laptops. without known locations you can't do much. David Lang M. [EMAIL PROTECTED] wrote on 04/02/2008 01:45:14 AM: Ryan, Like Ben said, inducing the physical layout of the network from metrics such as RSSI will give you poor results for various reasons. What Space did was to average arrival rates from direct neighbors over a long period of time (anywhere between 1 and 10 seconds) to avoid highly temporal effects like multipath and noise. Even so, the result is only a rough layout of the network. If you'd like to achieve better accuracy I thing you should combine other ideas like sound measurements, as Ben suggested. Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] new sugar work into joyride
There is a learning curve involved with the revised Home view (F3). It took me a while to realize that NOTHING appears in the circle view of launchable Activities until I have gone into the list view and marked the star on each desired Activity. And then This is a matter of initializing a default set, which we do intend to do to make the interaction more clear up front, and to make it easy for anyone to jump in from the default home view. Though we will choose a default set of activities to show, this is also something countries may wish to customize for their deployments as well, according to need. it took a while more to realize that if I clicked within the Home view (as opposed to on the Frame) on the icon of an already-running Activity, a NEW INSTANCE of that Activity would be launched. [The small icon (in the graphic F3) for most recent Activity is the only icon within the Home view that provides a 'Resume' option.] This is true. More improtantly, the connection we hope to make is that the colored/filled icons represent instances of activities, whereas the outlines are for launching new ones. If you review the designs linked in the previous message, you'll find we do have an alternate view which gives preference to resuming over launching new. This has some dependencies on an improved datastore, but I'd like to get it working as it may even be the safer default. In the list view of available Activities, I can't press PgUp PgDn to scroll - to view the whole list, I have to laboriously click (or drag) the scrollbar. Also, in that list I can only click on the icon to launch that Activity -- it would require less positioning if I were able to select a whole line and click anywhere within it. The list view is in a primitive form. I hope that this view and that in the journal get proper keyboard support before release. We chose to make the icon the clickable button, just as it will be in the Journal, to allow other uses for the rest of the list should we need them, and to make the interaction as explicit as possible. In the Journal we intend to allow inline renaming, for instance. Thanks for the feedback on our first stab at the new design! -Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] new sugar work into joyride
The new Home frame design is cool. On Thu, Apr 03, 2008 at 10:07:21PM -0400, Eben Eliason wrote: it took a while more to realize that if I clicked within the Home view (as opposed to on the Frame) on the icon of an already-running Activity, a NEW INSTANCE of that Activity would be launched. [The small icon (in the graphic F3) for most recent Activity is the only icon within the Home view that provides a 'Resume' option.] This is true. More improtantly, the connection we hope to make is that the colored/filled icons represent instances of activities, whereas the outlines are for launching new ones. If you review the designs linked in the previous message, you'll find we do have an alternate view which gives preference to resuming over launching new. It'd be nice if the already running icons representing instances of activities were different not just in color/fill. I'm thinking of a visual element like the triangle in the OSX dock, outside of the icon pointing inward at it. Mikus -Eben Martin pgpwJp7llTD9R.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
On Thu, Apr 3, 2008 at 8:55 PM, [EMAIL PROTECTED] wrote: On Thu, 3 Apr 2008, Michail Bletsas wrote: Let's not forget that you need some fixed reference points. In commercial systems, the locations of the access points are well known. In ad-hoc networks the best that you can hope for is a topological map. the assumption was that the measurements are being done from fixed points. either the school server antenna locations, or the known locations of specific assistant laptops. without known locations you can't do much. David Lang Suppose you have your initial fixed points with known locations (server antennas and any standalone repeaters). Wouldn't you be able to identify temporarily stationary points that, after deducing their locations, could be deemed additional listening stations? Once a node is identified as such, any additional measurements it provides can be deemed credible and then used to determine the locations of less stationary nodes. As David said, some commercial solutions require calibration by walking a node around the premises. I think this has been shown to be fairly accurate for a single AP's coverage area without having to add additional APs to the network. Most of the comments have been along the lines of using single measurements to identify distances of separation. I think a better solution would be to include the mesh's routing table, packet arrival times, etc. along with RSSI measurements. If you generate one or more likely maps from each and then average them out, I suspect you'd get a fairly accurate estimation of where everybody is. Coupled with preloaded measurements from around the premises, a viable solution seems likely. Is the XS capable of installing/pushing applications onto XOs automatically? If so, that allows for a very easy way to let the XOs participate in the process without bothering users, as well as distributing some of the number-crunching to take make things easier for the XS app. Am I displaying complete naivety here about everything involved or does any of this stuff make sense to you guys? -Crawford ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
re: [sugar] Mini-Conference Proposal: Toolbars Tabs
Greg Smith wrote: I'm not opposed to changing the GUI at the OS level. I can think of a dozen suggestions starting with that annoying hot corners thing. I also love a whole bunch of the design elements. All I'm saying is that any change comes at a cost. A cost paid by the teachers, students and people who train more than the developers. The cost also increases with time. I want to make sure you take that in to consideration. Walter Bender wrote: Let me further add that very little teacher training has in fact taken place. What we have instead concentrated on is working with teachers on how to best leverage to tool to enhance learning inside and outside of the classroom. Here in Nepal we have put a ton of effort into teacher training. This has been constructivist training where we introduce the features of the XO, the teachers work together in peer-to-peer interaction, then the teachers gave us their feedback and suggestions. Our teacher training may be very small in scale compared to other OLPC deployments, but our team here in Nepal has put a lot of heart and soul into it. I simply ask that OLPC and the conference participants very carefully consider large-scale changes. -- Bryan W. Berry Systems Engineer OLE Nepal, http://www.olenepal.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Automatic transfer/update of activities on the mesh
2008/4/3 Jameson Chema Quinn [EMAIL PROTECTED]: 1. for version threading, what we need for an activity is not a claim like I am a version of activity ID but My prior version was XXX and the one before that was YYY. What is the granularity of XXX and YYY? I'd say, a hash on the activity.info would be fine - that way, version changes are automatically picked up, but not every change in the source code. If, later, activity.info picks up some elements which are too volatile (thus leading to unnecessarily-long geneologies), we could filter those out before hashing. Note that this is totally orthogonal to whether an activity version is signed by the original devteam, and yet allows for forks to become independent without fighting over who is the real pippy org.laptop.XYZ1FFE3. I submit that merges are unnecessary. I think this is overkill. A single unique tag, randomly generated, suffices to identify all applications which claim to be a version of Activity X. Let's make it As Simple As Possible. 2. If we get the version threads right, then the auto-update on sharing becomes safer. I still don't understand who has to sign to avoid a break in the ownership chain - I would presume a given set of maintainer/developers, and I would presume that there would be some way for the group to change over time - but those details can be worked out. You're still thinking that the signing key corresponds to a *person*. It doesn't. It corresponds to an *activity*. With the first version of Pippy, cjb generates a new key. The chain is unbroken as long as new versions of Pippy continue to be signed with that key, whether because cjb gives the key to a new maintainer, entrusts it to a group, or because he's making them himself. When cjb releases Words, it has its own unique signing key. Replacing an old key with a new key would be interesting, but it adds a lot of unnecessary complexity. Better (to me, for the moment) to just let the chain be broken when that becomes necessary. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs
The win-win is when this piece of Greg's advice is followed: ...Just make sure its not a surprise to existing users. Also make sure they are bought in, understand the benefit and are ready to make the move. ... Greg Smith (gregmsmi) Thu, 03 Apr 2008 06:24:10 -0700 And Bryan seems to have the perfect environment to engage the teachers in a preview/review of the contemplated improvements and fulfill the suggestion: ...This has been constructivist training where we introduce the features of the XO, the teachers work together in peer-to-peer interaction, then the teachers gave us their feedback and suggestions. ... Bryan Berry Thu, 03 Apr 2008 20:46:22 -0700 OLPC is really making history with all your great work! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] New OLPC Process and Rules for Builing Activities, Releases, and Firmware Builds
April Fool's was a good way to present what does eventually need to be done, and what is done in some other open source projects. It's a good way of doing it, and would require some work. I would set up a set of stages with the highest and easiest pay-offs first, e.g. building versions with and without activities and with and without source would be easy. I don't know how to implement some of the features, especially code coverage metrics. That said, it is likely to remain an April Fool's prank unless OLPC Foundation folk are willing to head towards tested and timely releases where experimentation takes place on branches. This change in mentality is work for some developers and impossible for others. There are some fix-ups on the proposal; the stages of water metaphor needs better explanation and the spring and summer metaphors need renaming (thanks Andrew). Does anyone believe OLPC Foundation is up to this style of change? Charles On Wed, Apr 2, 2008 at 10:29 AM, Grig Gheorghiu [EMAIL PROTECTED] wrote: I'm a bit confused at this point as to whether Charles's message was an April Fool's prank or the real deal. Charles -- you got all of us here, now can you shed some light? :-) Grig --- C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Apr 1, 2008 at 6:55 PM, Charles Merriam [EMAIL PROTECTED] wrote: New OLPC Process and Rules for Building Activities, Releases, and Firmware Builds I. Introduction It's an exciting time at the OLPC Foundation! In the next few weeks we will be releasing Update 1 and holding our first Mini-Conference for developers at 1 Cambridge Center. Also, we are announcing our new processes for streamlining the development process. Process and rules make it easier to create quality deployments to the children world wide that now depend on their XOs. We will be releasing high-quality, regularly scheduled deployments timed to coincide with the school year in most countries. These changes will help developers concentrate on high quality software and have their changes make it out to children more quickly. The major changes outlined in this document include: Time-based Release Schedules Developer Changes: Better GIT web interface standard project metrics Useful and predictable build targets II. Time-based Release Schedule OLPC is moving to time-based release schedule. A growing number of open source projects have standardized on this approach including the Ubuntu and Gnome projects. See https://wiki.ubuntu.com/TimeBasedReleases for one explanation of this system. Major updates will be signed and released on May 15 and November 15 each year. This will allow ample time for review, teacher training, modified lesson plans, and deployment. The version numbers will be in the form YY.season, so our next two releases will be 08.Spring near May 15, 2008 and 08.Autumn on November 15, 2008. This year, because of the transition, Update-1 may be released on a different date than May 15, 2008. It will still be officially called the 08.Spring version. Getting a stable build out to all corners of the globe can be hard. A branch grows in stability over time and stablity of the release and field testing the final release candidate takes time. We plan to finalize the exact schedule for 08.Autumn shortly, but expect the following: 45 days until release Feature Freeze 30 days until release User Interface Freeze, Sugar OS freeze, Imports Freeze 15 days until release Translation packages freeze, Final freeze and start final testing 0 days Release on schedule. +30 daysAnnounce schedule, priority, and tool chain changes for next release at developers conference. III. Developer Changes These changes should help developers by making it easier to get their changes into regular builds. Changes are minimal: most developers will only need to name a new GIT branch. The biggest change for developers will be to provide named branches for the stable version and for each release version. The OLPC Foundation may create a named branch for inactive and completed projects that should be a release. Also, the OLPC Foundation may create an as shipped branch when we finish a release cycle. We recommend that projects try to develop new features be in separate branches and merge them back into a 'stable' branch as they are completed; just our advice. See the wiki for the latest branch names and explanations. Another exciting change is a new look to the online GIT
Re: [Server-devel] [Localization] OT is there a Content or Curriculum olpc email list
Hello Yama, please see [EMAIL PROTECTED] for content discussions and [EMAIL PROTECTED] and [EMAIL PROTECTED] for aspects of usability (discussions about interface design are usually directed to sugar). There is no list about teacher training, though there is an educators list that was initially set up with related discussions in mind that has been dormant. SJ On Thu, Apr 3, 2008 at 11:43 AM, Yama Ploskonka [EMAIL PROTECTED] wrote: Please forgive me for this message and crosspost, but after meandering sort of all over laptop.org I cannot find an equivalent to these most excellent Server and Localization lists. Do any of you know if such a content or curriculum list exists and how I can sign up for it? Also, is there something going on about Usability? about Teacher Training besides the wiki? If there's no list yet, who are the admins and how I can contact them for those areas of the project? (if nothing else, my efforts in this have shown me that usability is a major to do...) Thanks, Yama ___ Localization mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/localization ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] OT is there a Content or Curriculum olpc email list?
Yama wrote: Do any of you know if such a content or curriculum list exists and how I can sign up for it? To my knowledge, no. But we definitely need one. I know that Bipul, Kamana, and Saurav from our team would be very much interested. myself as well. You can start one yourself. I believe you can just send an e-mail to [EMAIL PROTECTED] to request one. -- Bryan W. Berry Systems Engineer OLE Nepal, http://www.olenepal.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [OLPC Networking] RSSI value questions
On Thu, Apr 3, 2008 at 8:55 PM, [EMAIL PROTECTED] wrote: On Thu, 3 Apr 2008, Michail Bletsas wrote: Let's not forget that you need some fixed reference points. In commercial systems, the locations of the access points are well known. In ad-hoc networks the best that you can hope for is a topological map. the assumption was that the measurements are being done from fixed points. either the school server antenna locations, or the known locations of specific assistant laptops. without known locations you can't do much. David Lang Suppose you have your initial fixed points with known locations (server antennas and any standalone repeaters). Wouldn't you be able to identify temporarily stationary points that, after deducing their locations, could be deemed additional listening stations? Once a node is identified as such, any additional measurements it provides can be deemed credible and then used to determine the locations of less stationary nodes. As David said, some commercial solutions require calibration by walking a node around the premises. I think this has been shown to be fairly accurate for a single AP's coverage area without having to add additional APs to the network. Most of the comments have been along the lines of using single measurements to identify distances of separation. I think a better solution would be to include the mesh's routing table, packet arrival times, etc. along with RSSI measurements. If you generate one or more likely maps from each and then average them out, I suspect you'd get a fairly accurate estimation of where everybody is. Coupled with preloaded measurements from around the premises, a viable solution seems likely. Is the XS capable of installing/pushing applications onto XOs automatically? If so, that allows for a very easy way to let the XOs participate in the process without bothering users, as well as distributing some of the number-crunching to take make things easier for the XS app. Am I displaying complete naivety here about everything involved or does any of this stuff make sense to you guys? -Crawford ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
