[Sugar-devel] native HTML activity
Hi! Just to prove that it can be done, I have hacked a little bit more on the native HTML activity which can be found here: https://github.com/NoiseEHC/sugar-webkit-native I tried to create virtual pages by using WebKit1's or Soap's url rewriting callbacks but it turns out that no matter what you do, the thing wants to use the data from the TCP stream... So I turned to starting a (Soap) HTTP server inside the native activity (on a random port) and it works. Now the activity runs from localhost (/activity and /web subfolders) and there is a virtual folder called /journal. It has only one hacked file, the /journal/journal.html, which has links to all the things in the journal. It queries the journal service via DBUS. I have to tell you that working with GVariant from C is a real PITA, so I did not implement the load/store of the real journal files, but it is clearly possible... (Beware, it leaks every possible resources, it is just a proof of concept.) Now, I do not know what is the problem with WebKit1, it seems to work for me, and at least it does not crash on an XO-1.75 as WebKit2 does. On the other hand I cannot try it on my XO-1.75 as it is not possible anymore to install webkitgtk-devel on the machine as I told you last time... This whole project has the following benefits: - It is much-much faster than the python one. It does matter on an XO. - It does not depend on the WebKitGTK python bindings to be maintained, it can use all WebKitGTK's features. - It does not have a dependency on Node.js. - It does not use WebSocket, which would require using WebKit2... So now it is your decision whether you use it or not. Thanks, Andrew ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
Hi! Took some time but finally set up my git account... 2 Journal This is probably the issue we have been most aware of. I've been thinking in the per activity datastore direction too and I think it's probably the best one. Though as you say that involves UI redesign and we would need to figure out compatibility with existing activities. (Please share the webkit code, I don't know if I'll have time to hack on it but I did think to write something like that at some point, it would be interesting to look at it if nothing else). I have put the ?latest? sources here: https://github.com/NoiseEHC/sugar-webkit-native It requires a yum install webkitgtk3-devel to be able to compile, unfortunately my XO-1.75 says that there are no more mirrors to try for mesa and libdrm dependencies so I could not try it under an ARM XO... (I did try it some time ago however it just stopped working.) You may also need to create a test2/bin directory as git does not include it... The code is full of static char buffers which should be fixed and it also crashes on an XO when you compile with webkit2gtk... We probably all agree that it would be awesome to have something that integrates well with Sugar and works transparently by reusing existing web technologies. I don't think that's easy to achieve though. It has been said in previous discussions that without the close integration between activities and system, Sugar would be just yet another suite of educational applications (and likely not the best of them). I very much agree and I think it's tricky to preserve that while moving to frameworks which are supposed to work everywhere. We could have started with something more web developer friendly and incrementally integrated it into the native Sugar platform, for example by redesigning the Journal in the way you described, and somehow adapting native activities to the new design. Instead we went for something targeted at the current Sugar developers with the idea of making it incrementally more web friendly. I have been on the fence on what was the best approach and I still am. Something to consider is that we barely have the resources to maintain the existing native code. I doubt, for example, that we would be able to ship a redesigned Journal. Consider also that the people most involved with this work has all a good knowledge of the Sugar platform but are not really web developers. I fail to see why would it be bad if Sugar would be just yet another suite of educational applications. Currently the close integration between activities and system consist only of 3 DBUS methods, 4 X properties, the Journal as a filesystem and the presence service (which is desugarized if I remember correctly, you have to use Telepathy directly?). In my opinion the single most important thing would be to allow developing sugar applications directly in the PC browser (like firefox or chrome). If that would work then you could just go to a web conference and after giving a presentation about sugar-web you could ask the attended crowd to help you in the workshop by converting just ONE/person python activity into a web one and you are done with the conversion in a day... Obviously it would not make converting Write/TurtleArt/Etoys/Scratch easy but at least the rest would be done. Now, if you go standard web, then you do not need the X properties, view-source is built into the browser (DBUS HandleViewSource) and DBUS SetActive can be done with webkitvisibilitychange event and timers. The only remaining thing would be handling the DBUS Invite. Collaboration would most likely need an OT library which should have a C implementation on the XO to have usable speed. The Journal simply can be implemented by the host application by providing either some standard file API implementation (like light-swift) or just providing a virtual page with links and POST. https://github.com/bancek/light-swift So if you already run a node.js server then probably it could host the activity's html files and could provide some virtual file GET/POST service in http://localhost/journal/directory.json - this is for file list http://localhost/journal/guidcomeshere - this is for GET/POST files My plan was to support http://localhost directly from sugar-webkit-native (instead using file:// to be able to OAuth) and query/update the journal from there too but it is simpler from node.js if you are running it anyways. You can also assume that web developers have node.js running on their dev machine or already know how to install it. If you forget for a while to have collaboration from web apps then the rest can be done in no time IMHO. So that was my $0.02. Obviously it can be too late to change plans but who knows. I have uploaded the source anyway so you can use it if you want. Regards, Andrew ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http
Re: [Sugar-devel] Activity Central's Sugar related priorities.
I have put the ?latest? sources here: https://github.com/NoiseEHC/sugar-webkit-native It requires a yum install webkitgtk3-devel to be able to compile, unfortunately my XO-1.75 says that there are no more mirrors to try for mesa and libdrm dependencies so I could not try it under an ARM XO... (I did try it some time ago however it just stopped working.) You may also need to create a test2/bin directory as git does not include it... The code is full of static char buffers which should be fixed and it also crashes on an XO when you compile with webkit2gtk... Ehem, the source should be in a directory called test2 so it matches the name in the .info file... That is why it requires a test/bin subdir... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 22/10/2013 21:21, Gonzalo Odiard wrote: So that was my $0.02. Obviously it can be too late to change plans but who knows. I have uploaded the source anyway so you can use it if you want. What I really don't understand is, if is all that easy why not be involved and help? The development of the web activities stuff was done in the open, mostly by two developers, manuq dnarvaez. Then everyone who wanted help, could do it. Say now how should be done, is useless at least. Talk is easy... as always, the devil is in the details. But you already know that, if not would not talk about unconstructive criticism Gonzalo You are right. The problem is that my views are exactly the opposite of the decided path to take. I do not help developing because I totally oppose the current path, meaning that I do not believe that it can work. All the easy talk can be useful later *if* they decide to change paths. Or it will just remain an interesting viewpoint, but at least I tried. So while you are right about the Talk is easy part as well, I could only help developing by finishing the native webkit app (because I believe in it), which would be totally wasted (parallel) effort. Actually that was the plan but then I run out of time and realized that the official project went a different direction anyway. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 07/10/2013 18:41, David Farning wrote: Activity Central supports the recent HTML5 + JS work that is going into sugar .100. It has the potential to take the OLPC vision to any device which runs a browser while simultaneously *increasing* the potential activity *developer* *pool* by several orders of magnitude. This is an excellent area for community lead research. Activity Central will be doing activity side work to test the viability of the framework for client deployments. No, it won't... It already happened when Bryan Berry moved OLPC Nepal's lessons from EToys to Flash, then to HTML5 and there were not any more contributors. I mean, there are much more JS developers, so if you pay them you can get cheaper talent, but there will be not too much more contributors IMHO. The problem is that the current HTML5 work goes into a direction which I am not sure that needed by anyone other than existing Sugar developers. It all boils down to this simple question: If you are a potential contributor wanting to develop some educational activity (not a framework but some concrete lesson or stuff usable in a lesson!!!) then which one would you use? 1. A HTML5 + JavaScript activity model called Sugar Web Activity, which reaches 2-3 million children? (lets call it SWA) 2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which reaches 1 billion children? (lets call it WEB) I have not seen any compelling reason why would a potential contributor (software developer from a developed country who has/likes children) choose option 1 instead of 2... Now I will not give you constructive criticism as that would allow answering that I should not tell others what to do and it would be getting old... Instead here is some nonconstructive criticism: Some months ago I wanted to create a sample activity to present my point but I have run out of time so unfortunately I cannot show it to you. It would have been a Google Drive backed game with shared state (so the same as a typical shared activity in Sugar) called Scrabble what I try to port to SWA. It uses the following things which are trivial to use on the WEB but cannot be found in SWA: 1. Sign in. There is no authorization API in SWA so using anything than the local journal is problematic. Using Google's OAuth authentication from a file:// protocol is impossible so if you want to support existing code then you have to serve the activity from http://localhost... https://developers.google.com/drive/about-auth 2. Datastore. There is no way to access the Google Drive if you cannot authenticate. I do not see why would anyone use a new JavaScript lib which accesses only the journal when they are already familiar with some WEB technology. Like WEBDAV or the OpenStack's SWIFT API. http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html Or simply using POST for uploading: https://developers.google.com/drive/manage-uploads 3. Collaboration. Using the Google Drive Realtime API is dead simple. It is the most missing feature from SWA BTW. https://developers.google.com/drive/realtime/ I have looked at several open source Operational Transformations libraries but did not have time to test their performance on an XO... 4. Using WebSockets for simple tasks. The autosaving can be implemented by the almost standard webkitvisibilitychange event (but you have to compile webkit with the appropriate parameters) and standard timers. Activity startup is simplified with per activity data store (POST-ing to the same server is the default on the WEB). I think it eliminates the communication with Sugar so no need for WebSockets... 5. Android port. There already exists a multi-platform technology called PhoneGap. It can target 100-200 million children so it can be called option 3 if you want... It can become obsolete as HTML5 provides more and more of its features though. http://phonegap.com/ So as I see you either create a framework which mimics Sugar and no web developer will use it or create a framework which implements what a web developer is already using or at least tries to somehow emulate it. So the web developer does not have to modify his/her code and will consider porting his/her application for a smaller platform. Of course that would require OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for contributors otherwise everybody will go with Google APIs which cannot easily be emulated on an XO machine... But as this discussion already happened and I have already written enough now, I just finish here. (In the following link you can replace the phrase Per Activity Data Store with Standard WEB Storage to be relevant...) http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024589.html Thank you for your attention! Andrew ps: Now to say something constructive as well, some more words about the Journal. Recently I was watching one of Walter Bender's talks where he was
Re: [Sugar-devel] somebody deleted gst-plugins-espeak from github?
Hi! build worked as it pulled all repos. I thought that it is a connection problem because some days ago there was a connection problem. I just wanted to archive sugar-build just after pulling all the stuff as I really did not want to download ~450 megs again and again as I try different configure options for webkitgtk (as cleaning the tree does not work...). Now it fails on fedora18 with this: * Building gobject-introspection ... checking for GLIB... no configure: error: Package requirements (glib-2.0 = 2.36.0) were not met: Requested 'glib-2.0 = 2.36.0' but version of GLib is 2.34.2 Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables GLIB_CFLAGS and GLIB_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. So now I gave up building webkitgtk from sugar and will download directly from the source and will compile my little activity without sugar. Thanks anyways, Andrew On 02/07/2013 21:12, Daniel Narvaez wrote: Something else you can try is git pull. Basically your config is stuck to an old version, I'm not sure exactly why. I made improvements in that area lately but you won't get them until this is unstuck :) On Tuesday, 2 July 2013, Daniel Narvaez wrote: Try to run just ./osbuild first then pull again? On Tuesday, 2 July 2013, Noise EHC wrote: Hi! For several days I get this, and looking at https://github.com/sugarlabs/ I cannot see the repository either... Log: [ehc@localhost sugar-build]$ ./osbuild pull = Pulling = * Pulling automake * Pulling glib * Pulling gobject-introspection * Pulling pygobject * Pulling dbus-python * Pulling gwebsockets * Pulling node * Pulling grunt-cli * Pulling volo * Pulling karma * Pulling jshint * Pulling js-beautify * Pulling docker * Pulling flake8 * Pulling sugar-docs * Pulling sugar-toolkit-gtk3 * Pulling sugar * Pulling sugar-artwork * Pulling sugar-datastore * Pulling gst-plugins-espeak Command failed: git clone --progress git://github.com/sugarlabs/gst-plugins-espeak.git http://github.com/sugarlabs/gst-plugins-espeak.git gst-plugins-espeak fatal: remote error: Repository not found. Cloning into 'gst-plugins-espeak'... Retrying (attempt 1) in 1 minute Thanks, Andrew -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
The biggest finding that came from outside this thread is that if Browse is to move to pygi to access webkit, the Sugar python bits that it uses must also be gtk3/pygi. No mixing with pygtk2 is possible. So we have a prerequisite on sugar (or at least parts of it?) being moved to gtk3/pygi first. Why do not you implement the new Browse in C/C++? It would have three advantages: 1. It could reuse an existing WebKit browser's code. 2. It would not depend on incomplete/unmaintained python bindings. 3. It would be fast. At least it would not use 60M of python runtime memory per process. Of course it would require reimplementing some simple toolbar and children would not be able to look into the browser's codebase (only though the web) but I think it would be an interesting option to consider. At least the 3. point could be important enough for the most used application in Sugar... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
Unless you are proposing that all of Sugar moves to C as a base; that may have its merits but is a separate discussion, and not one I'm going to get involved with. Feel free to start a new thread / Feature page. I am not proposing anything. I just showed an option that no one considered. I mean that I thought that no one considered... :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [AC Update] We are what we do.
About pane has a psychological effect, it provides recognition and maybe a sense of ownership for developers and mantainers. I will propose it on sugar-devel and the HIG once I've implemented a design. Also it gives a starting point for eventually getting involved in the development and improvement of each activity. The idea of an About dialog (or menu) already came up on sugar-devel, not long ago. IIRC, Gary Martin was quite opposed to increasing UI clutter with non-essential information. Perhaps we could still define a few meta-tags for activity.info and _not_ display them in the UI at all? They would still be easy to find for developers. You can show this info in view source mode and in the journal. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Home button in browse - toolbar images
You could just make the new tab show the home url by default. On 2010.10.19. 6:15, Bernie Innocenti wrote: On Tue, 2010-10-19 at 03:01 +0100, Gary Martin wrote: Alternatively, the new tab button could become a small plus on the tab bar, which could be made visible at all times. For how long would it remain invisible during a normal session? Hmmm -1 from me as that would require showing the tab strip at all times, even if only one tab is in use, making the default UI more complicated and eating back into canvas space. But you missed my rhetoric question: for how long would it remain invisible during a normal session?. All UI designers seem to abhor tabs. They call them complicated and unnecessary, but all users love them, including UI designers themselves! Ok, but our users are children. Well, have you actually seen a child use Firefox? Children aren't stupid, they use tabs for browsing just like adults. Actually even *more* than adults, 'cause they get bored of waiting for pages to load much sooner. In the real world, after the first few minutes there will be so many tabs open that they won't fit horizontally. Tabbed browsing is the #1 reason why Nepal and other deployments replaced Browse with the Firefox activity. 1) Just because in your builds you decided to disable the screen hot corners from triggering the frame doesn't mean that it is now free space up for grabs ;) Ouch... Forgot about that. (still, we have way too much space on the sides. It could fit an entire button. 2) Corners are used by the notification system. Ok, but those last only a few seconds. 3) Using that space for more buttons does not solve the feature creep, and spiral towards complexity. If we were to remove the least useful feature, I'd pick the home button :-) Even if we don't add any button, we could use the extra space just to enlarge the URL bar... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Since I spent quite a bit of time analyzing the Python runtime here is my conclusion, maybe it will make wasting all that time less painful. First, most of the memory consumed by an activity is the process heap. While the Python runtime and native libraries are shared among processes, the heap is not. Even if you fork processes it will not work because reference counting will dirty the shared pages and my instinct tells me that just loading a Python source file will reference almost all the shared pages because they are mostly used to store already loaded modules. What I finally did not do is to actually check the hypothesis that most of the heap is filled by strings which are the identifiers in the loaded Python modules. My goal was to somehow make identifiers constants and just readonly-mmap them into the process (replace the pathetic .pyc loading mechanism). Note that my plan was just a little subset of the .jar - .dex converter. Second, Python has a special memory manager which works with buckets so there are separate heaps for different object sizes. Somehow this special memory manager is turned off in release mode and it uses the standard C heap for some reason. Either it is a bug or just it turned out to be faster (more work was put into glibc) I do not know, but handling the linked free list can dirty shared pages as well or I am just mistaken... Third, the fact that Python is a dynamic language does not help any prefetching or memory sharing. I am not too convicted either that this dynamic nature is used at all in the Sugar codebase but you know I cannot program in Python and frankly I do not feel the need to learn another language. Just now, at my age of 34, I finally gave up and learned LISP (more specifically clojure) and I hope that it will be the last programming language I will have to learn (other than assembly languages of course)... :) Now this point is interesting because if you thought that the Dalvik VM could run the Sugar codebase via Jython then it just will not work. The Dalvik VM just cannot load .jar files and Jython just generates them on the fly because of the dynamic nature of Python. Fourth, moving Python (theoretically) to a GC environment (instead of reference counting) also would not work if the GC is compacting because it would also dirty the shared pages. So a mark and sweep nonmoving GC with separately stored visited bits is the only feasible solution. Now guess what the Dalvik VM does? For more info (45 min + questions): http://www.youtube.com/watch?v=ptjedOZEXPM So *my* conclusion is that solving this sharing problem is *very* hard. I am not sure that simply translating all activities from Python to Java would take more time. Another interesting thing is that meantime the unladen-swallow project progresses (just more slowly than planned). Their plan is to make it the default Python runtime so if it will happen (I cannot comment on that) then the Python VM will use even more memory (though it will be faster) so Sugar will be even less interesting on the myriad of low spec cheap ARM tablets which will flood the market soon. I think that is all I can say about this subject so I just finish it here. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep confusion -- round N+1
After making tests [1] in deployments for start new vs. resume we concluded that the way activity starting works on the iPhone would probably work well in Sugar, too [2]. Hehe, this is exactly the thing you would get with per-activity datastores. Guess what, Android does this too. :) Not to mention that an object chooser for pictures could be totally different from an object chooser for ftp sessions for example. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
Besides, the assumption that VCS-style deltas will work well with the binary files stored by most Sugar activities is... wishful at best. A design working in real-world scenarios would probably require ad-hoc deltifiers for each file format, making it very complex, slow and fragile. Whether a generic versioned filesystem could ever become feasible, remains a fascinating research subject for the next decade. Perhaps we could slightly enhance the current datastore design to store full copies of each version without any attempt to deltify them. This is also how git started. Actually these are the exact same problems that could be solved much better with some kind of per activity DS (not the Android one, which would be a little bit overkill). I mean that even making or not making deltas is dependent on the object the activity stores and the deltifier is also activity object dependent. Also the single file or multi files thing is activity dependent and so on. So you can implement every possible feature in a global glorified DS but I personally do not think that you will reach a really usable general DS ever. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
It seems that I cannot stop myself killing some kittens: As I see the problem is that the DS wants to solve a lot of problems in a general way. I think that this is simply impossible. A lot of companies tried to create some general storage abstraction other that files, but all of them failed (even M$ tried that for decades...). My prophecy is that you will fail as well. Another way to solve those problems would be to have every activity have its own journal with its own user interface. The activity then could use plain files for storage or an SQLite database or just append a text file. The point is that the storage would be activity specific, with activity dependent optimizations if necessary. The activity would also show a list of existing documents/objects when started and have a New... button to start a fresh one. It would also eliminate the troubled activity start mechanic from the activity ring. Of course SUGAR should have some very good library support to enable creating the default DS user interface in several lines of code. Of course for activities which does not save objects this would be optional. Now because the DS storage would be scattered between activities, they should have to implement a backup/restore API, lets call it BackupAgent: http://developer.android.com/guide/topics/data/backup.html A simple activity could just mention in the MANIFEST that it has a data directory to be backed up and that would be all. Of course the user should be able to use full text search so there should be a either a central index or the activities should implement a search API, lets call it SearchRecentSuggestionsProvider: http://developer.android.com/guide/topics/search/adding-recent-query-suggestions.html Of course SUGAR should have library support to ease creating this search functionality. Now to allow activities to share data they should implement some API to be able to provide content to other activities, lets call it ContentProvider: http://developer.android.com/guide/topics/providers/content-providers.html Of course a flag in the MANIFEST could just allow SUGAR to index the data automatically. It would need some primitive OLE (Object Linking and Embedding) capability which is currently missing from SUGAR, lets call it AppWidgetProvider: http://developer.android.com/guide/topics/appwidgets/index.html The remaining piece would be a dead simple Journal which would just list the recently launched activities. Now why would it be cool? 1. Searching among contacts, mp3 albums and picture bundles can be totally different from the end user perspective. 2. It can be efficient, does not need copying large amounts of data. 3. Activities could be launched from GNOME. 4. It could be backwards compatible (if the APIs are set in stone). 5. The DS code (the library) could be developed when there is a need in an activity, there is no need to redesign the whole thing over and over again. 6. And I am sure that I could find some more... Why it is just a pipe dream? 1. Python does not have anything like the DALVIK virtual machine so every Python process consumes a lot of memory. Because of this, implementing the above infrastructure would consume all available RAM and so would not work. Of course the DS part could be C++ code as well but unfortunately children could not look at the source. 2. It is already implemented so why bother? Now, you should not take this message too seriously but you could seriously consider a per activity DS if you have some free time. Martin Langhoff wrote: On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ and they get little testing and I've seen extremely light thinking about what is _actually_ needed. That's a very polite way of saying that you disagree with the extensive thinking that's been done about datastore design and implementation for No. _It says exactly what it says_. People have been thinking lots about the fun part of the problem, thinking superficially about what they'll have fun implementing. Not about the complete problem space. Not about what hits users. Not about what we need for a saner implementation. even just a list of use cases that you believe have been overlooked. Ah... - ENOSPC? - Backwards compatibility? (Horrendously broken ATM on 0.84 -- I have a bad patch for that...) - Integration with GNOME? (for those dual desktop OS builds) - Some reasonable degree of atomicity? - Sensible backup/restore? - Smarter handling of bundle filetypes... = so together with the Journal, it can expose the many images or videos in a 'Record' = so the Record file format gets untangled - Re-thinking of the Journal / Datastore interactions to access the normal filesystem so that Gnome's ~/Documents directory can be browsed -
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
You are not explaining why this will happen, so this point is moot. The reason is that it seems that it is impossible to do. I just extrapolated historical data. So we're indexing the data automatically, but we still don't have a datastore? Please explain how that would work. The Search activity's data is the generated index. And we want users to have to start other applications to find there stuff *why*? From what I can tell, the trend in the mobile space has been to unify searching across formats, a la the iOS's Spotlight. Exactly. Launch Pictures to handle pictures and launch Write to handle documents. You can have unified search across formats just not unified object handling (display, delete, etc). You'll be breaking backwards compatibility with every previous Sugar version (from what I can tell by your description), and rather than requring us to rewrite the Journal every so often in Sugar, each activity maintainer will have to rewrite it themselves. Now here is the interesting part. You already break compatibility. If there is shared code between these activities (since most cases involve similar models of data storage) we'll have to patch each individually, rather than a shared library. That is the point, to not have shared DS code other than some library what would be included in every activity which would provide some data to search or other activities. Most activities will not have such data. The few activities which would have such DS could be updated individually without breaking compatibility. They could be developed individually *when* *the* *need* *arises*. Now all that said, the Android model is overkill. Something much-much simpler could work IMHO. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Assessment in Karma
Okay, a little holiday happened with me and then had to read through 100+ olpc emails and then realized that there is a spam filter on my email which blocked sugar emails since july so it took some time to catch up but here I am... :) Martin Langhoff wrote: 2009/8/19 NoiseEHC noise...@freemail.hu: - Automatic assessment is snake oil, Bryan is well intentioned but deeply wrong. See the earlier email at http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05584.html Or you are wrong. I may well be wrong, but to explore that you will have to talk about what I am stating :-) So I was wrong too... :) We could rephrase it as - Computer-based automatic assessment / grading is only passably accurate for a tiny *tiny* subset of relevant human skills. I am 98% sure that automatic grading (if you mean assessment == grading here) is absolutely not possible at all. (And it is a different issue that as far as I know grading in class 1-4 is totally pointless and harms children.) Most of the problems are that those tests which would in theory differentiate children in a 1-5 grade scale are high stake tests which are inherently unreliable. - However, it's very spectacular, and people are drawn to it... so much that they are drawn to it even when it *clearly does not work* for the skill being tested. It's so easy (for the teacher) and so flashy, that people use it regardless of whether it works. I say this after 9 years of work in the field -- I have seen interactive SCORM objects, Moodle quizzes lessons, HotPotatoes activities, LAMS assessments, lots of other standalone assessment tools. Have worked with teachers, watching their use. What did I see? See the 2 points above. There is a 3rd part... because these tools are cool, easy to use, they do a lot of damage. In large part because they replace the I don't know how my students are doing with hey, I have all these scores are numbers... nevermind they are inaccurate and only cover about 3% of what these kids should know. So an inaccurate view of a tiny slice of the skillset -- but hey, we have a number representing what this kid knows! Let's use it! The link that follows is from the Asttle project, which I was briefly involved in several years ago: http://www.tki.org.nz/r/governance/consider/steps/analyse_e.php Even worse, the Asttle project promotes the idea that you can get a form of 'dashboard' of what kids know. Looks like an airplane dashboard, lots of dials, full of inaccurate data _about a tiny subset_ of what matters. I can feel your pain (especially seeing the Asttle project) so thanks for the warning! What more interesting is that there is some research in Hungary [1] about the prerequisites of learning certain skills which are based on each other. Sure, that is interesting. Now how amenable to computer-grading are those skills? What automated computer tests can assess them with a decent accuracy? It is not about computer-grading at all!!! It is about well tested low-stake tests (children must reach 80-90%) which can reliably measure whether a child for example reached finishing or optimal level in reading (I am talking only about basic skills). If a child does not reach those levels then no matter how constructivist your education policy is in the higher grades (4-8) because this children simply will not be able to gain any information from books. Currently teachers can only deduce missing basic skills from the simple fact that the children fail biology or geography tests (because they cannot read reliably) and nobody tests reading skills continuously. The computerized assessment cannot be worst than that can it? ... Automatizing at least some of those tests are probably the biggest thing since sliced bread in education in my humble opinion Are any of those tests automatizable? With what accuracy? If it turns out some can be computer assessed... _how do we keep the non-automatizable tests in the map_? Teachers forget them *immediately*. If the school decides to run this little research then I will let you know about the automatizabledness of the relevant tests, I promise! :) And I am sorry but I will not be able to solve those other social problems (non-automatizable tests) with computers that is sure... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Candidate paper cut bugs for a new 8.2.x release?
Hi! I do not know what was the conclusion about this _completely hypothetical_ case but does fixing the Geode VGA driver match the paper cut criteria? Since I am porting (very slowly since 2 months ago I did not know anything at all about the Linux boot process for example) Android to the XO-1 there were some display errors. Android uses FBIOPUT_VSCREENINFO to flip (and not blit!!!) between two frames in video memory and without a patched Geode FB driver it causes a very awful flicker since the Geode FB driver turns off the video output then sets params then turns on the video output. Similar flicker can be seen on the XO when Sugar wakes up from a frozen DCON so possibly my fix would be applicable here as well. If fixing the driver is desirable then probably I could fix the other Geode driver bug, the video overlay fuckup during wakeup. My little question is this: does anybody know how and where the sleep happens? Is the video output turned off in the FB or the X driver? Is the FB driver used at all when the X driver takes control? ps: The attached file is not a patch but a VERY ugly fix for trying... :) Of course I will create a normal patch which can be pushed upstream but only if it is needed... Martin Langhoff wrote: In the _completely hypothetical_ case that I had some time and chance to spin a 8.2.x release aimed at fixing the paper cuts[1] and low-risk bugs that hinder XO-1 deployability _today_ in the field - have *you* got any candidates? Tell me about them :-) I am specially hoping to round up bugs that have patches that have been tested in the field. So low low risk stuff that makes life easier and better for those that really matter: kids and teachers in the field. No promises for now, but I sure want to find a way to do this. Daniel's piled up a few good patches I am aware of, but I am sure there are more (from him and others). cheers, martin 1 - https://wiki.ubuntu.com/PaperCut geode_fix.tar.gz Description: application/gzip ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Assessment in Karma
- Automatic assessment is snake oil, Bryan is well intentioned but deeply wrong. See the earlier email at http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05584.html Or you are wrong. Since you did not define exactly what you have meant by assessment in your message, I assume that you were talking about something like automatic grading or creativity assessment versus something mechanical and mind-numbingly trivial. (Any other assumption makes your message meaningless in my eyes but correct me if I am wrong...) Now I will not talk about that you have just presented us a false dichotomy since it is not too interesting (and can be that I just have misunderstand and misrepresented what you have been said). What more interesting is that there is some research in Hungary [1] about the prerequisites of learning certain skills which are based on each other. (So for example reading fast - whole word reading - requires to be able to read words letter by letter which requires reading out certain letter combinations which requires knowing the letters which requires differentiating vowels and so on... Since I do not know these things in English I did not try to be precise in this example.) The point of this research is that it is clear now that if a child does not reach a certain threshold in those skills then he cannot progress in other skills (these are the critical skills). Here lies the bane of the Hungarian education system that children go to school at the age of 6 and they can be +-2 year apart in mental and physical development. So some children are like 8 year olds and some are like 4 years olds. Unfortunately this mental/physical difference is usually totally different across subjects so for example if a child is totally lame in writing (because he cannot control his small muscles adequately) but is an ace in math then it is normal and repeating the class is not an option. In Hungary (and probably a lot of other countries) the problem is that teaching these basic skills goes according to the national curriculum and there are no tests which measure them so if a child is left behind then game over for him. For example if he cannot reach optimal or finishing level in reading then he will not learn from books normally since he cannot read fast enough. Because teaching of reading skills stops at grade 3 or so these children leave the elementary school at advanced, beginner or sometimes preparatory level (40% of people in Hungary!!!) and they grow into functionally illiterate adults who cannot learn anything from books or read newspapers (or watch films with subtitles so they cannot learn languages in that way). Now there are some good news that there exist tests which can measure the level in those basic skills and these are low stake tests. Usually optimal level means 90% and finishing level is 80% (in some skills these are around 80% and 60% respectively). The problem is that measuring those takes a LOT of time and energy and no teacher wants to do that. Automatizing at least some of those tests are probably the biggest thing since sliced bread in education in my humble opinion. So it will not help teachers giving a mark at all because you know ALL the children should pass those tests sooner or later. Of course it will not measure creativity either. What it should do is to measure some mechanical and mind-numbingly trivial skills what are not measured without computers because it is mind-numbingly boring for a teacher. Now the questions is: which basic skills can be measured with a computer and which cannot? Calling assessment snake oil because it cannot give marks automatically is at least strange to me... [1] http://www.staff.u-szeged.hu/~nagyjozs/#res ps: As the subject becomes more advanced it becomes much more painfully obvious that my native language is not English. I am sorry for that. ps2: Of course this is not the most important aspect of OLPC but giving these assessment tools to children in Ghana probably cannot hurt can it? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Karma IRC meeting - August 11
Hi! It could be a little bit off topic and can be totally irrelevant because of the difference between education systems, but have you considered a possibility to generate lesson plans, examples and questions from a wiki? I mean that it is a lot of work to create a coherent lesson structure but after that filling it with simple data (examples and questions) can be crowd sourced. Handling hundreds of participants each only adding several sentences can be best handled with a wiki is not it? (It can be that it is just my fantasy and does not fit the group dynamics or the lesson structure you have in Nepal but what is your opinion?) Christoph Derndorfer wrote: Hi all, here's a preliminary agenda for tomorrow's IRC meeting on #sugar-meeting: http://wiki.sugarlabs.org/go/Karma:Meeting_11_Aug_2009 Time permitting OLE Nepal's Roxan (in CC) will also be joining us at some point so we can discuss his involvement regarding the teacher's note and lesson plan. Here are some early notes regarding the teacher's note and lesson plan: * in html * images allowed (even encouraged?) * a lesson can potentially have multiple lesson plans ** for different languages ** for different learners ** for the lesson / exercise / game part of the unit * lesson plans should contain an introduction which gives a very brief overview (1~2 sentences) of what exactly the lesson will teach the pupils ** this information can be used to identify interesting lessons in a given library * should be easy to navigate ** e.g. question of whether very long documents should be split into several pages for on-screen (target 1024x768) consumption ** should also look half-decent when printed * templates should be provided Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com http://www.olpcnews.com e-mail: christ...@olpcnews.com mailto:christ...@olpcnews.com ___ 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] Karma IRC meeting - August 11
Mmm, I'm not sure how realistic it is for people to be interested in providing that kind of data... But I could be wrong. When I was visiting my elementary school there was a biology teacher who took teaching biology very seriously. Computer technology was in its infancy at that time so he used an overhead projector and has drawn a lot of slides (plastic foils) with colored markers. It could have taken a LOT of time to draw all those materials and because copying plastic slides was (and probably is) very expensive he could not even share it with other teachers. What is clear to me that at least in his mind the materials were much higher quality than the books we used in class otherwise he would not have been working with them so much. Now my feeling is that approximately 1% of the teachers can be like my biology teacher. Also approximately 5-10% of the teachers would spend 5-10 minutes per day to fix learning materials (like fixing spelling, fixing examples kids did not understood in that day, etc). Even in small countries like Nepal this 1% can be more manpower you have in OLPC Nepal. Not using their helping potential is not too wise, I think that if you make contributing easy then people will start doing it. Of course this is just my speculation. Having said that I certainly believe that such a feature would be overkill at this point, there's a bunch of much higher priority tasks that we need to tackle before and it's important not to lose focus of our main goals. Now that is what I agree with 100%. However at least planning for the future cannot be a waste of time (unless it takes more time than can be saved later). So probably the following two things would be enough preparation: 1. Do not use fancy lesson plans (like pdf or formatting) so creating some some wiki - karma converter will be possible. Then you will be able to crowd source. 2. Do not wire questions/examples into the karma lesson. (It is mostly done because of internationalization issues.) It is only relevant for text only or mostly text only lessons because Karma is for programmers and the potential contributors will be teachers and nonprogrammer people cannot modify the code via a wiki I think that is obvious. They also will not be able to draw via a wiki. I think that you should consider at least the 1. point since it is basically do not do anything... :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Read 71
So accessing the frame in ebook mode - is probably not something you do in your ebook workflow (at least on an olpc without touchpad support). Correct - and dedicating a frame button on the tablet mode is probably something I would not do (we don't have too many buttons accessible in tablet mode) Incorrect. Since I use the XO-1 for reading ebooks while traveling with public transport regurarly, I can clearly see the need for not only frame support but for handling the laptop from the keyboard even in ebook mode. What important is that volume/brightness level and magnification (and anything activity specific) should be available from ebook mode at least via some menu (and no submenus please). You should not dedicate a full button to this menu, probably holding the rotate screen button for 1 sec is the correct method activating this menu (which would take over cursor keys and the 4 game buttons), and while the menu is on screen, pressing the rotate screen button would hide it. (It also requires to activate screen rotation when the rotate screen button is released, not when it is pressed. Also it could have some delay so pressing 3 times fast in a row would rotate to the other direction, no need to reflow and redraw the screen 3 times.) See, developing this functionality will be hard (because Sugar does not have framework support for it) and probably you have some better things to do now but at least putting this functionality on the roadmap would be cool. ps: Note that the Frame is an usability problem what is evident if you want to use it via the keyboard (and will be even more problematic when the XO will have touchscreen support). Of course it is only my humble opinion and we all know how much opinions worth :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Karma's Chakra - 2 views on lessons
Exactly what is the problem that this solution wants to solve? I mean that is not the teacher who selects from the lessons depending on her personal lesson plan? (Of course we could provide a default lesson plan but in the end it is up to the teacher what she wants to teach and in what order.) So is it important at all to select from a predetermined date or country specific grade? Can it be that I do not understand at all how those lessons would be used in the classroom? Or is this mega bundle (what bundles a lot of lessons from different subjects) solves the deployability problem and creates a selection problem? Christoph Derndorfer wrote: Hi all, I spent some time toying around with Chakra in the past 24 hours. As a preliminary result I have concluded that we should initially support two different views of the available lessons. (1) What I call E-Paath style (see the attached chakra_epaath_s.jpg) as it follows E-Paath's current flow in terms of choosing Grade - Subject - Week before being presented with an overview of the available lessons. (2) List style (see the attached chakra_list_s.jpg) which is a simple list of lessons available for that Grade and Subject (of course one could make it even simpler by listing all lessons for a given Subject, regardless of Grade) (Please ignore the lack of reasonable design and color choices in these screenshots;-) Now the question is how to generate these Chakras for a given set of lessons (which are stored in sub-folders)... In general the issue is that with the currently proposed Karma bundle layout (http://wiki.sugarlabs.org/go/Karma/Bundle_layout) the only information we have about a lesson is it's name. This is of course too little data to create a nice Chakra with Grade and Subject choices. Subsequently I believe that we should find a way to include some additional information with lessons. The way that OLE Nepal currently handles it during E-Paath development is that lessons are stored in sub-folders named Grade_Subject_Lesson Name_Week (e.g. 6_English_RajuAndTheWolf_1). Based on that information a support scripts then builds the Flash menu structure. Now I was thinking that one approach could be to include some sort of .info file in each lesson that contains the information. While Subject probably will be fairly consistent between various countries the Grade information is highly country-specific and could be put into the respective .po files for each locale. What do you think, does that approach make sense? What are other possible solutions to deal with this? As always, all comments, feedback and suggestions are much appreciated. Thanks, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com http://www.olpcnews.com e-mail: christ...@olpcnews.com mailto:christ...@olpcnews.com ___ 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] Assessment in Karma
In June I was talking with the headmaster of a school which does education research. There are two things from that discussion that seems relevant for this question: 1. Karma could measure the time it takes to finish a task in a compound exercise. If it is statistically relevant then it could give some hint to the teacher which parts of the curriculum are hard for the given child. If I will be able to persuade the headmaster then there will be research (hard data) which hopefully will find out whether this measurement is meaningful or pointless. 2. There is a VERY HARD to develop exercise model where the child can follow multiple paths to the solution. In this case the possible choices the child can follow makes a graph with most of the leaves ending with does not compute. If this exercise model proves to be useful (which will be determined in the mentioned research) then Karma should store the way the child solved the exercise and not only the end result. So what I wanted to say is that it is possible that the wrong steps can give more informations to the teacher about the knowledge of the child than the fact whether the child was able to solve the exercise or not. Because the 2. point can be a little bit hard to understand, here is an example: The problem is this: If we used A amount of paint to fully paint a little picture with sides B and C, how much paint do we need to fully paint a room with sides D, E and height F? This is an exercise with 3 steps. The child has to calculate the area of the picture (P=BxC) and the walls' (W=(D+E)*F*2) and has to calculate A/P*W. Now the graph looks something like this: from the beginning the child can calculate either area or can do something like B*E which does not compute. If he has P and W then he can do either A/P or W/P then either A/P*W or W/P*A respectively. In every step the program should graphically show what the child just have calculated (what can be impossible if he uses D*E*F*B for example). Now I do not insist that you develop this 2. point since it is a HUGE task (and needs some research to know whether it really help children understand complex relationships) but moving Karma into this direction (just a little bit) would help a lot if the headmaster would decide to do this research. In this case we will translate the resulting exercises to English, probably you will be interested in that. ps: I intend to use Karma for interactive curriculum development for reasons Bryan Berry talked about a lot. ps2: By research I mean try out with kids while somebody from the University measures the outcome. Christoph Derndorfer wrote: As previously mentioned by Bryan in his Automated Assessment is the Killer App blog post (http://karmaproject.wordpress.com/2009/07/06/assessment-is-the-killer-app/) student assessment is an important component of Karma. While toying around with the lesson UI I realized that the assessment area is still very much an empty space (which kinda reminds me of the group view in Sugar;-) as we haven't really discussed how it should look, what kind of data will be kept (which is of course heavily dependent on the type of lesson), how the data will be stored, etc. To keep the efforts required to do that in check I think that it might make sense to start by offering a handful of templates - both on the UI and storage backend side of things - to fit the most common use-cases in terms of different lesson types (e.g.inserted words into sentences, doing calculations, etc.) Now I was wondering whether anyone here had specific suggestions on how to address this or pointers to how other e-learning solutions (regardless of whether stand-alone applications or Web based) solve this interesting challenge. Thanks in advance, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com http://www.olpcnews.com e-mail: christ...@olpcnews.com mailto:christ...@olpcnews.com ___ 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] Assessment in Karma
ps: I intend to use Karma for interactive curriculum development for reasons Bryan Berry talked about a lot. Awesome! How can we involve you more? is it time to for us to open a mailing list specific to karma? like sugar-ka...@l.s.o ? u can find christoph, myself, and the ole nepal team on #olenepal or #sugar Mon-Fri 03:00 -- 11:00 GMT (day time hours in Nepal) The whole point of this project is that this school developed a curriculum that works. The plan is to use the inevitable transition to digital learning materials to push this working curriculum onto other schools. However it is not my project but the research school's project so until they decide that they start this project I cannot do anything education related since I am just a coder. I will talk with the headmaster in August next time so then I will be able to tell you something more concrete. What I see is that in order to win the curriculum battle the following things must be met: 1. It has to be cheaper than paper books so parents will want it. As it seems the XO is already cheaper (200$/4years = 50$/year what is already spent on paper books). 2. It has to be wanted by children. The XO 1.5 (or maybe the ChromeOS or Android based smartbooks, we will see next year) will be able to run flash/youtube/web so it is OK. 3. It has to be wanted by teachers. So it has to ease teaching. Like automatic assessment. 4. It has to be developed on the cheap. Like reusing the skill set of thousands of existing web developers. So it seems to me that it will not be much different than what you are doing in Nepal so we will have the same problems what you had and will need the same tools what you use... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Book bundles and Read
A possible solution for 2. The catalog file should be a .html file with file:// links to the USB drive. If the kid opens the .html file in Browse and clicks on the link then it will be copied to the Journal and opened in Read. The .html file can have pictures. The only criterium is that the links shall point to /media/BOOKS/bah.pdf where the USB drive's label is fixed. Jim Simmons wrote: All, In my own emails when I refer to content bundles I am not referring to anything that Sugar Labs has proposed as a standard. I was just thinking about how to deal with the Children's Book Library project, how would I deal with the problem of distributing 2,000 books to children without access to the Internet or even a local web server, knowing the limitations of the Journal Activity as it exists in .82. I came up with the idea of: 1). PDF books stored in zip files along with gif files representing their book covers plus a catalog file. 2). An Activity, possibly an enhancement to Get Internet Archive Books that would browse this catalog file and create a user interface allowing the books to be browsed and copied to the Journal one at a time. I suggested that the catalog file be in Dublin Core format because that seems to be trendy but truthfully I'd be happy with a catalog of delimited lines like this: The Innocents Abroad|Mark Twain (Samuel Clemens)|Travel, Humor|innocents where innocents.pdf is the name of the PDF and innocents.gif is the cover page image. I've been a professional programmer for over thirty years so my method tends to be: 1). What do we have? 2). What do we want to do with it? 3). What is the simplest (not necessarily the most generally useful) way to get there? I certainly can understand the value of a good standard approach to this kind of problem but I wasn't trying to propose one. James Simmons ___ 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] need a better name for starting page of karma than MenuStage
Could you please name those items in English? I suggest this because probably Karma is one of the most important things from an educational viewpoint because it will allow developing curriculum in a totally open way. I mean it will allow teachers to avoid locking teaching materials even into Sugar so no matter what will happen 10 years from now, will Android or ChromeOS (os something totally unpredicted OS) take off, or will Sugar spread to hundreds of millions of machines, or will Windows dominate in on portable machines or whatever, the curriculum will still be usable because there will be some browser in the future that is sure. So most likely most of the programmers developing curricula will use Karma so it would be wise to name things that will be understandable for the widest international audience. Just name it as table of contents or directory. Bryan Berry wrote: what should we call menustage? it is a horrible name. it is just not descriptive: http://www.pustakalaya.org/external-content/static/epaath/MenuStage.html I don't want to call it the frame because that word already has a meaning w/in sugar. i also don't want to call it anything w/ a religious connotation since karma is named after Rabi _karma_charya and not for the religious concept. Words that come to mind are mandala -- which literally means circle in Nepali but sometimes has a religious connotation (ugh) dhoka -- this means gate in Nepali. I like dhoka but everyone outside of Nepal will mispell it I like mandala the best so far . . . ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
I think you do not get what is so special with Android. 1. They killed the braindamaged X driver model and put the driver where it belongs, the kernel. Just like Windows NT and OS-X already did. Finally it is fast and really supports hardware acceleration! Did I mention that it has redraw profiling tools? 2. Python is already available on Android: http://www.damonkohler.com/2008/12/python-on-android.html The porting is not about running Python Sugar on Android but to implement the parts missing from Android in java. a. Activities store their data into a per activity file area and an SQLite instance. A common data publishing interface should be defined. The Journal should became just an aggregation. b. There is no peer to peer networking. I should be written. 802.11s will be dropped in XO 1.5 anyway. c. There is no common document format defined to share data between activities. Work is already happening on this one. d. There is no printing support. Hmmm, I have heard this before. So IMHO the job would not be to port Python since the lame Python VM would be just as lame on ARM. If you really want to port things then here is the thing: http://arstechnica.com/open-source/news/2009/05/canonical-developers-aim-to-make-android-apps-run-on-ubuntu.ars Of course this is just the (easier) technical side. The people side is a totally different beast. Currently, as I see, both OLPC and Sugar developers spend a massive amount of time fighting platform problems when the solution is already available. This time could have been spent on learning activities. Desktop application compatibility does not exist on the XO so probably it would not be a deal breaker. The next big thing which will be reimplemented is touch screen support in XO-2. I hope that the result will be just as usable than the next Android GUI for smartbooks which will be tested for years by then. Of course it will not happen overnight but can it be that this is the most future proof investment? Is not the goal putting education into children's hand rather than reimplementing the desktop paradigm over and over again when there is an alternative backed by Google, the ARM vendors and millions of $? Elena of Valhalla wrote: On Mon, Jun 15, 2009 at 11:33 PM, NoiseEHCnoise...@freemail.hu wrote: The real deal is that Android will be pushed by all the carriers and ARM vendors. In my humble opinion it will be the dominant phone OS in the future with even more hardware support the good thing is that android is based on the linux kernel, so most of this hardware support will be available to every linux system; the only significant exception will probably be the graphics subsystem, where google's work will stop at the framebuffer, while a standard linux system may need X. (just try out the Android SDK, it is multi platform with an emulator). Jumping to this massive smartbook bandwagon could push the OLPC idea further without any hardware development. It is probably feasible to jump on the smartbook bandwagon even without a full port to Android: a proof of concept port of sugar to ARM is already available from the work of Bernie Innocenti in OpenEmbedded, and in my free time I'm trying to update it to 0.84; another (untested?) port is available in debian, where the sugar packages are built for every supported arch, including ARM and other embedded ones. Installing such systems on an android phone is generally feasible, requiring skills broadly comparable to those needed to jailbreak an iphone; of course deployment will need support / permission from whoever is going to sell the hardware, to be able to preinstall gnu/linux + sugar instead of the standard system. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
Technologically the phone and the computer are quickly converging. They are just coming at the problem from different points of view. Phones focus on power consumption and size. Netbooks focus on screen size and general use computing. If the new ARM technology is as good inside devices as it is on paper the convergence is going to happen sooner than many of us expect it. If you look at the Nvidia Tegra video made by Charbax then it is clear that it will converge next year. Google and the ARM companies pushed millions of $ into quick web browsing and hardware accelerated video and flash (something even Bryan Berry defines as the future of educational software development). Android implements the following things (the next version will support smartbooks): 1. Its Dalvik VM works in very limited resource environments. It is something Negroponte talked about but nothing happened (with Python memory comsumption), Google did not talk about it just fixed it. 2. The applications are separated like in Rainbow. OLPC will even loose Rainbow with the transitioning to stock Fedora. 3. There is an usable programming environment targeting Android. I can debug programs from Eclipse running on Windows!!! 4. All the activities on Android can be used by the cursor keys only (so they ARE easy to handle). Something Sugar lacks even now. 5. There is a massive army of programmers targeting Android. It is only my really humble opinion, but could that be that probably the most sane way would be porting the relevant parts of Sugar to the Android platform and ditching the rest? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
My major concern against porting to Android is that Java is a horrible language, even with the nice Android libs. Google have said that they will add more languages, though. Yes, java sucks. IMHO it does not matter though since mostly activities consists of 1000 lines of code. A more long term solution would be using PyPy, since it has significantly lower memory usage and better optimisation prospects. Switching to PyBank for bindings should also help. Or retargeting Python to the DEX format. The real deal is that Android will be pushed by all the carriers and ARM vendors. In my humble opinion it will be the dominant phone OS in the future with even more hardware support (just try out the Android SDK, it is multi platform with an emulator). Jumping to this massive smartbook bandwagon could push the OLPC idea further without any hardware development. ps: If you did not see the video then the current plan is to sell those smartbooks for 0$ via G3 phone carrier subsidy. It can became a HUGE market. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
There is a project doing a bit of that, http://code.google.com/p/jythonroid/ Jython just got a new compiler though, it should be possible to retarget it. Google seems to love Python, maybe they will help? Perhaps OLPC could get them to at least say whether they're working on it? http://code.google.com/p/unladen-swallow/ It is Google's Python plan. Unfortunately it is not about reducing memory consumption, it is for servers. The problem with the Sugar path is that it has no hardware vendor backing. Android has. The new 1.5 XO makes the memory pressure bearable with 1G of memory just it also has no hardware vendor backing (in the sense of at least 10 million units per year category). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] cool animation w/ all-javascript space invaders
Bryan Berry wrote: http://static.boundvariable.com/space-invaders/ does most of the animation that we need using raphaeljs, which uses svg and not canvas http://www.raphaeljs.com Have you tried it on an XO? I just had this experience. Seems to me that we will not do animation with js ever... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
There are 3 different ideas when we are talking about Journal vs Directories: 1. Whether we are limiting the user to use exactly one filtering category for his/her documents (and lets call them Files and the filter the Files' Directory) or we allow multiple filters (and call them Tags). 2. Whether we are showing the user a open/save dialog which has a Directory tree and File list or we just ask for a name and some tags for save and let the user filter open. 3. Whether the document store is a filesystem or a database. so remembering these points, answers are inlined: Albert Cahalan wrote: In graphical environments alone, directories are over 25 years old. Since 8 is less than a third of that, there is only one safe bet. It'd be way more than 25 years, except that we didn't even have graphical environments much beyond that. Directories go back about 40 years. 8 years is just another 20%. I am sure that 100 years ago when the car was invented, because humanity has been used horses for 5000 years and the next 100 years is only 2% of that, people predicted that we will still ride horses now This isn't the Microsoft Windows XP Service Pack 2 feature set. This is a concept that is pretty fundamental in computing. It crosses platforms, it's in our network protocols, and it's even required for all the programming languages that implement Sugar. Having a filesystem does not conflict with that the user will never ever see one (3. is a differ idea than 2.). The following things unfortunately cannot be done with a flat filesystem view: 1. Revision based view. 2. Tagging. First, I think you didn't mean flat. That's the Journal. Second, both flat and tree systems can handle that. I meant flat filesystem so I have written exactly that. I meant a filesystem which can be drawn on a 2D surface in a tree (where the files are leafs). Contrast it to a multidimensional filesystem where a File can have multiple Directories and which stores all the versions. See I do not want to argue over semantics so if we will have some system which can handle this multidimensional storage then we can call it a filesystem if you insist. After all a filesystem is just a database which maps names to disc block numbers (and the canceled WinFS was marketed as a filesystem after all). What is sure that this future filesystem will have a completely different access semantics that for example ext2. It is a totally different problem that the current Journal barely implements those things but dropping it in favor of time-tested solutions is a mistake IMHO. (Note that no filesystem solves those problems I have mentioned.) No filesystem should! It looks like GNOME 3.0 will get you those features on top of a plain old UNIX-style filesystem tree though, without making the filesystem incompatible with both software and humans. Have you noticed that as the world evolved, filesystems gained unimaginable capabilities like resource forks, extended attributes, access control lists, transactions? Is your point that we should drop the Journal just to be compatible with those softwares that possibly no child will ever use? I would vote to make the Journal more usable rather than trying to stop the world. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Developer MINUTES
I hope this anwers your question, Simon Unfortunately it does not. What I wanted to know whether I will be able to use the latest Sugar on my XO-1 ever. It boots the kernel with 802 so it is a working Linux distribution. If somehow I copy the latest Sugar over the old Sugar (0.82 I think) will it work? If it does not work then will anybody port it? What I see is that OLPC has very few developers so probably this porting work will be out of question but will Sugar people make any effort or would it be just wasting their time where the XO-1.5 is almost finished? ps: If overwriting the old Sugar works on an XO-1 then an unzippable distribution what could be applied to 802 would be just fine... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Announcing Snapshot 2009/05/24
I have tried the appliance image on VirtualBox. On the registration form it crashed with some python? error (will look the exact error if it is not a well known bug). It could be caused that I clicked more than once to the Next button. After that I only have an Automatic login user to choose from. It asked for my XO username correctly. Speak does not work, the sound output is garbage, changing languages kills the sound completely (but it does find the audio output). Browse has the same bug as in soas2-20090416.vmdk: 1. Go to Sugarlabs page (not the default page in Browse but sugarlabs.org) 2. Click on Activities 3. It will open the page in a popup window (what is different that using the default page in Browse) 4. Download an activity (I used Speak repeatedly) 5. There is no download notification and when you switch to Journal you can see that the download never finishes. Probably the notification at the end of download crashes. Sebastian Dziallas wrote: Hi folks, after a short break, there's a new snapshot ready for you. It incorporates the latest packages from the upcoming F11 release, as well the Colors activity. Please report any bugs or issues you encounter and list them appropriately for the soas_linuxtag milestone in trac, if needed. Our roadmap is located here: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap The current list of bugs for the RC can be found here: http://www.tinyurl.com/soas-rc-tickets The image can be downloaded from here: http://download.sugarlabs.org/soas/snapshots/2/Soas2-200905241902.iso The appliance image has been made available here: http://download.sugarlabs.org/soas/appliances/soas2-20090524.zip Thanks and happy testing! :) --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] Sugar Developer MINUTES
Are there any plans to port Sugar to the XO-1 or will it be the job of OLPC so it will be effectively abandoned? Simon Schampijer wrote: Attendees: Tomeu, Aleksey, Walter, Sayamindu, Simon Retrospect: We have been brainstorming on the Goals of the 0.86 release. The Output can be seen at http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86 Feel free to add items you feel important to the roadmap - have in mind that it is a short release cycle and therefore we have only a certain amount of things we can do. Prospect: Next week we will iter over the points and find owners for the them. The time to propose items ends the 5th of June after the developers meeting in two weeks. By then each feature item needs a concrete plan. Examples: http://wiki.sugarlabs.org/go/Activities/Library or https://fedoraproject.org/wiki/Features/DeviceKit See you next week - a reminder will be send out. Regards, Simon PS: The schedule have been updated as well: http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Schedule ___ 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] Simplifying sugar-jhbuild
Bernie Innocenti wrote: On 05/20/09 23:29, NoiseEHC wrote: When I tried jhbuild what I found strange that it does not detect the Linux distro so I had to manually enter commands as it was specified on the wiki. Can we get rid of that? (I have no idea how to detect the distro or how to automate that just to let you know this fact...) You mean for installing dependencies? This requires root privileges, so jhbuild can't do it on its own. Besides, we used to have some distro-specific dependency check in the past, but I someone (marcopg?) ripped it off, probably because it was a pita to maintain. I am talking about this: http://wiki.sugarlabs.org/go/Development_Team/Jhbuild/Fedora As I told I do not know how difficult can it be to automate so if it would be a lot of work then of course you should not put too much work into it. BTW text like the dependency check will fail if you don't have a DISPLAY set does not mean too much for Windows people like me (I did manage to google the answer so it was not a question). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Simplifying sugar-jhbuild
Tomeu Vizoso wrote: On Thu, May 21, 2009 at 12:40, Bernie Innocenti ber...@codewiz.org wrote: On 05/20/09 23:29, NoiseEHC wrote: When I tried jhbuild what I found strange that it does not detect the Linux distro so I had to manually enter commands as it was specified on the wiki. Can we get rid of that? (I have no idea how to detect the distro or how to automate that just to let you know this fact...) You mean for installing dependencies? This requires root privileges, so jhbuild can't do it on its own. Besides, we used to have some distro-specific dependency check in the past, but I someone (marcopg?) ripped it off, probably because it was a pita to maintain. Wasn't ripped off, but improved, we check for system dependencies in the supported platforms like this: ./sugar-jhbuild depscheck This will tell you which packages to install with yum/apt-get/etc. How can we make this more obvious? Regards, Tomeu For example by autodetecting the Linux distro, it could create a full command line. Of course, if it could be automated then it should just say something: The following dependencies are missing: long list here. To install them, type in your root password: type here. Of course if it would be a lot of work you should not waste your time in it. And why shall I run jhbuild 3 times anyway? It could have a default option when it does an update then depscheck and then a build... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Simplifying sugar-jhbuild
Bernie Innocenti wrote: Today I've kick-started a newbie on building Sugar to fix a small bug and submit his first patch. It was just painful. jhbuild has plenty of rough corners and we could easily make things easier with a few changes: 1) Stop checking out random unstable versions of external projects. They break very often, and we cannot fix them. Let's instead upgrade manually every once in a while after some testing. 2) Do not build C modules that is already available (and recent enough) in popular distros. Specifically: abiword, matchbox, hippocanvas... 3) Let's move etoys away from the base set of components: the repository is often offline, building it breaks very often, and it takes a lot of time. You don't need it in order to test Sugar, the same way you don't need TamTam and TurtleArt. 4) We could check for prerequisites before starting the build. Some configure scripts are stupid enough to fail tests silently and proceed anyway using no as a command name in make :-) If there's consensus on implementing one or more of these points, I can provide patches (or just go on and commit them). When I tried jhbuild what I found strange that it does not detect the Linux distro so I had to manually enter commands as it was specified on the wiki. Can we get rid of that? (I have no idea how to detect the distro or how to automate that just to let you know this fact...) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)
I think most of those effects can be just as easily be done by the 2D engine (like what the Geode has). Of course it would need a LOT of coding, like killing the stupid X driver model with the X server process, using a compositing windows manager, rewriting GTK+ to use some form of retained rendering mode (like a super optimized Cairo library with some scene manager functionality) and finally fixing all of those GTK applications which became buggy because of this rendering change. Oh yeah, almost forgotten that moving to OpenGL would need just the same amount of work. So not only would it chew trough the XO 1.5's battery like crazy but it would not run on the XO 1.0 so does it really worth that effort? Martin Langhoff wrote: On Tue, Apr 21, 2009 at 1:42 PM, Martin Dengler mar...@martindengler.com wrote: Imagine if it actually looked like the demo: http://www.sugarlabs.org/index.php?template=gallerypage=media_01 Exactly my thoughts. There are a couple of things we have to be mindful of as we step into the wild 3D world... - memory footprint -- those smooth transitions count on having various full-screen buffers, one for each screen you might want to slide smoothly into. - batery burn -- the OpenGL API was originally designed for high end workstations, and has some battery-depleting features such as a hi-res timer event that triggers all the time and prevents sleep The iPhone uses these smooth UI tricks (to a fantastic effect), and its battery life is a fraction of every other phone -- I'd say that the 3D niceness is part of the reason why. cheers, m ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)
Actually, GNOME 3.0 is moving into that direction (requiring OpenGL): http://lwn.net/Articles/327845/ Hehe, seems like that I have just invented Clutter... :) More seriously, it seems that Sugar just runs ahead of Gnome and reinvents almost everything which will be created by Gnome people (or will not be created since that article was just a plan). Do you feel comfortable that your efforts will not go into Gnome 3.0, or is there something I do not know about? Journal = GNOME Zeitgeist Karma = Clutter minus the OpenGL acceleration Sugar = social desktop etc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
Every help on the UI side welcome. What I do not get is why there is that navigation bar under the toolbar? It consumes a lot of space and has just that one button which was on the toolbar before. (I just checked the last SoaS image so it appeared in 0.84 I guess). Also the old layout shows a back button which looks like the one in Browse for the same purpose as in Browse. It is clearly a bad design IMHO. ps: Just booted my XO and 801 has this navigation bar (I do not remember it from ~760). So either way can we get rid of it? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Idea for SOC
Since my name was called: I think this would be a very nice feature to have. However, I do not think it is very likely to happen. 99.9% of Sugar users use Sugar on an OLPC XO-1 (maybe even more). In general, Sugar is designed to target low-powered devices. Blender will not be usable on these computers, because they do not have enough disk space, enough memory, or any hardware 3D acceleration. As far as I know Blender was ported to the XO but somehow it was not hyped too much. Probably it was slow (but wireframe mode should have been OK) and the small XO screen is not too well suited for that UI I guess. The main problem could have been that probably they had to use Mesa3D and it provides approximately 1-2 frame/sec speed as my test showed. You should ask them how that stuff turned out. Some people (like NoiseEHC) have discussed writing a fast, simple 3D library for low-powered devices like the XO, but this has not happened yet, so 3D development is not likely to work well. Yeah, I tried to design this 3D library before I had a real XO and my design tried to utilize the Geode documentation which turned out to be a little bit sparse... So after I got an XO and realized that I had to scrap all my designs I turned to existing software rendering libraries (I have tried almost all of them). The conclusion is that writing a 3D app is a lot of work so probably just porting an existing app is the most sane. The best way of providing software rendering support for an existing application is probably to port a software OpenGL renderer to the Geode. Unfortunately it is a LOT of work so when I tried it (the winner was the OGL ES software renderer for the ARM by the way - formerly it was called Vincent 3D) I did not finish before my free time ran out last year. The problem with all of this is that I do not see too many education programs for children which _really_ need 3D. If you take this route then at least use this and do not reinvent the wheel: https://gna.org/projects/softwire/ If you can demonstrate a 3D modeling program that runs in this limited hardware, then people will be more interested, but without such a demonstration I think it this project is unlikely to be accepted. Just to be a little bit negative I have another problem with 3D design software is that probably children will not be able to handle them. What little research I did in this area showed me that something like this is the most likely to be used (browsing the remnants of the site is recommended to everybody, good research there): http://web.archive.org/web/20071016055856/http://www-ui.is.s.u-tokyo.ac.jp/~takeo/java/smoothteddy/index.html It is java so good luck! :( So my (uneducated) opinion is that only some voxel models could probably be drawn and painted by small children. I can imagine a program which offers a set of templates like human/horse/dragon which have animations like two legged walking/four legged walking/walking and flying and then children could modify (like widen the legs or drawing horns) and paint those skeletons. My big-big problem is that currently I do not see any sound educational activities which would really need 3D figures to animate. Of course I would like to be proven wrong. BTW if somebody could post a video on YouTube which shows children using the Story Builder or Cartoon Builder on the XO I would be very happy. HTH! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
