Re: [Sugar-devel] badges for collaborative activities
On 12/13/2011 01:37 PM, David Van Assche wrote: I've got a sort of halted project which I really want to make collaborative, but am unsure how to move forward and include... I guess I was asking for some pointers towards really good documentation to make this a reality. You might like http://bemasc.net/~bens/groupthink/ a library I wrote for Sugar-GSoC 2009 that (under some circumstances) makes it easier to write collaborative python activities. It's currently used by Pippy, Stopwatch, and possibly a few other things. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] badges for collaborative activities
On 12/13/2011 01:57 PM, David Van Assche wrote: Played with that, wasnt quite what I was looking for. It basically skins an app (lets say a gtk app) and makes it look like its a part of sugar... but it doesn't really gie u access to how the collaborative functions work... Uhh, nope. Maybe you're thinking of Sugarize? (as documented on http://wiki.sugarlabs.org/go/Running_Linux_Applications_Under_Sugar) Groupthink is a python module for writing collaborative Activities. It works by providing data structures that automatically share themselves over the Tubes, synchronize their state, and even serialize to disk. No relation to Sugarize. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add-view-source-for-sugar-toolkit
On 08/23/2011 12:29 PM, Simon Schampijer wrote:
-self.sugar_toolkit_title_text = _('View Sugar toolkit source')
+self.sugar_toolkit_title_text = _('View source: %r') % 'Sugar
Toolkit'
So 'Sugar Toolkit' is untranslateable?
--Ben
signature.asc
Description: OpenPGP digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Article on Why files need to die
On 07/15/2011 05:54 AM, Christoph Derndorfer wrote: Please also see this article (http://blogs.gnome.org/mccann/2011/06/08/new-pony/) which Tomeu Vizoso (one of the early Sugar developers) just shared on Google+, well worth a read! I see this movement, along with Gnome-3's work on tablet compatibility, as a reason why the next generation of Sugar (or OLPC OS) should be based on Gnome 3. We have neither the need nor the ability to duplicate this effort. Better that we shape Gnome to serve the children. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] copy files to/from server
On 05/17/2011 03:42 AM, Sridhar Dhanapalan wrote: How can XOs copy files to/from their Journal with a server? The simplest solution is probably HTTP. Set up a little local website with an upload/download form. Moodle, or even a generic CMS like Drupal or Wordpress, would work, but the very simplest option is probably something like http://www.net2ftp.com/ combined with an FTP server on the same host (and configured for automatic login on the local network). --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar, PyGTK and Threadings
On 05/15/2011 01:01 PM, laurent bernabe wrote: in my application i'm developping using PyGTK, i want to use a separate Thread to do some stuffs on the application canvas To a first approximation, you should never use multiple threads in a PyGTK application. There is almost always an easier solution. It is possible to write stable, correct multithreaded software with PyGTK, but it is not easy, and there are very few people who know how to do it reliably. PyGTK is designed principally for single-threaded use. But i wonder if i still need to call *gobject.threads_init() *in the main module of my bundle (the one that is declared in the activity.info http://activity.info) as it is inherited from sugar.activity.activity.Activity class That is : does the sugar.activity.activity.Activity already does the work for me ? Or where should i call threads_init() (as i don't call gtk.main() myself) ? I believe that you do have to call threads_init() yourself. As I remember it, Sugar does not make this call for you. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH sugar-toolkit] Insert activity root path in front of the reset of sys.path
On 02/06/2011 09:39 PM, Aleksey Lim wrote: In my mind, the situation when modules that come with activity have higher priority than system ones is more natural/predictable. I attempted to do the reverse with Watch Me. Watch Me includes binary python modules that are not installed by default in OLPC's builds, so Watch Me includes binaries, but the binaries only work on Fedora 9 (OLPC 8.2.*, I think). Therefore, it also includes a shim layer that ensures that the bundled binary modules always have lower priority than system-installed modules if they are installed. So I recommend not assuming that the priority only goes one way. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] customizing olpc-os-builder image
On 11/02/2010 05:13 AM, javed khan wrote: can anybody tell me how to accomplish the following using olpc-os-builder 1: install new fonts 2: change the keyboard layout and default language 3: change the boot animation sugar-devel@ is not really the right mailing list for this question. You should ask on de...@lists.laptop.org (cc'd). The people on that list are more likely to know about olpc-os-builder. I don't know anything about olpc-os-builder, but just by searching wiki.laptop.org I found http://wiki.laptop.org/go/Fonts#Installing_fonts http://wiki.laptop.org/go/Tweaking_the_boot_animation http://wiki.laptop.org/go/Customizing_NAND_images#Language signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Edit/audit wikipedia activity
On 10/21/2010 12:06 PM, Martin Langhoff wrote: Unfortunately, there is a clear need to organise a facility to audit/edit the wikipedia snapshots we have and repack the archive. Do we have any easy way to do this? I'm the wrong person to answer this question, but the activity's archive production system does already have support for an article blacklist (and indeed many articles were excluded from the current bundles). I don't know who is in possession of this list, or exactly who took responsibility for producing the most recent version. Nonetheless, excluding articles is easy. Actually editing article text is not something we have attempted AFAIK. Ideally, I think, we would fix textual problems upstream as they are discovered. The most recent available snapshots for English and Spanish are 10-14 days old, so this strategy does create a delay, during which time things can continue to change. In general, I believe that auditing wikipedia is a fool's errand. There are 3.5 million articles in English Wikipedia, growing by over a thousand a day. Spanish wikipedia has 650,000 articles. If people want to create snapshots containing only whitelisted articles, that's fine, but many of the links will be broken and the amount of information will be much reduced. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
On 09/30/2010 06:33 PM, Art Hunkins wrote: The files also need to be renamed and placed in the FileMix.activity folder. Don't do this. Among other reasons, you shouldn't assume that the activity has write permissions to its .activity/ folder. There are a hundred other reasons why this is considered bad form. The Record activity is a natural for recording audio, and I had thought it would be the appropriate vehicle. I've recently discovered that it only produces Ogg Speex files, not the higher-quality Ogg Vorbis variety. Unfortunately, Csound and libsndfile handle only Ogg Vorbis - not Speex. (It would be very nice if Record *could* output Ogg Vorbis.) Making Record output Vorbis is a trivial one-line change. Presumably you would be best served by copying that portion of the Record code into FileMix, with the alteration to record in Vorbis. So, my question: can someone please explain how to get eToys sound files isolated and copied to other folders, and/or which other activities might meet my needs at least as well as (or better than) eToys and Record? Surely the activity that will suit your needs best is your own. I recommend you add the sound recording functionality there. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Mesh networking not working in my XO's
On 09/28/2010 08:53 AM, Harpreet Sareen wrote: Hi, I was discussing here about using Telepathy Framework with DBus bindings i.e collaboration on XO's using C#. If I am able to do that, will the solution be the same for Mesh networking and Ad-hoc networking Yes. The Telepathy interface works identically over all kinds of networks. You do not need to worry about which kind of network is in use. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #2141 UNSP: Memory and CPU status indicator for the frame.
On 09/15/2010 10:48 AM, Anish Mangal wrote: Here's how it works. 0 memory free 100 0 cpu free 100 0 mem + cpu free = 67= unhappy 67 mem + cpu free = 133 = serious/normal 133 mem + cpu free = 200 = happy I don't think this is a good enough heuristic. 1. CPU usage is not an indicator of impending failure. All programs should use 100% CPU when they are running, and 0% when they are idle. Metaphorically, your computer should be _happy_ when it's running, say, a fractal generator, because it's doing what it was built to do. Also, the kernel's scheduler ensures that one activity can't lock up the rest of the system. 2. I think we need a better heuristic for memory-happiness. On systems with large amounts of memory, 3/4 in use may still mean 1 GB free, so everything is perfectly fine. The reverse is true on small systems. My suggestion would be that the system is memory-unhappy if we estimate that there is not enough free memory to safely launch another activity. Once some activities are open, I think we can compute a good estimate for this very easily. A good heuristic should probably also contain a small adjustment to lower the unhappiness threshold on swapless systems. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feedback about ticket #10122
On 09/10/2010 09:54 AM, Gonzalo Odiard wrote: Hi Ben: I am trying to resolve the ticket http://dev.laptop.org/ticket/10122 Can you review it? Could you test it in XO-1.5? I've been following the discussion, but I haven't looked at the patch yet. I've had a rather busy week. I can't easily test changes because my XO-1.5 is broken, but maybe I can fix it this weekend. There are changes I did based in my tests, but I need to know if you agree. I'm concerned about any making Distance change the volume settings. This might make sense for the microphone amplification setting, but I would prefer to leave the speaker volume under the user's control. The appropriate volume to use for Distance depends on how long a distance one is trying to measure, the level of background noise, whether other people might be disturbed, etc. The changes in delay constant could make sense. I'll need to look at the changes and see if we can find an explanation for the changes. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] video conversion tools
On 08/25/2010 10:44 PM, Sean Linton wrote: Can anyone comment on the best video conversion tools for Sugar, and how best to install them? If I understand correctly, you want to install a tool on your normal desktop computer than will convert videos to a format that is easily played by Sugar. The appropriate video format for Sugar is Ogg Theora, and there are many tools that can produce it. Maybe the easiest is Firefogg: 1. Start Firefox (install it if you don't have it already) 2. In Firefox, go to http://firefogg.org/make/ This website will prompt you to install the Firefogg extension. Once it is installed, you can convert your videos by going to http://firefogg.org/make/ --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Browse-webkit] Changing its bundle_id
On 07/22/2010 12:18 PM, Lucian Branescu wrote: In order to better test Browse-webkit, we'd need to package and distribute it. If it isn't heavily tested and known to work perfectly, definitely don't call it Browse, and definitely don't use the same icon. Browse is by far the #1 most important activity, so we cannot accept _any_ regressions. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Browse-webkit] Changing its bundle_id
On 07/22/2010 12:26 PM, Lucian Branescu wrote: If bobbyp agrees, I'll rebrand it to Surf until it gets merged to master. Would that be ok? I think that's a good solution. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Missing Jacket
El Tue, 06-07-2010 a las 07:32 -0400, Samuel Klein escribió: Bernie -- I meant to send this to you earlier -- you will be pleased to know that I got to know someone devoted to the demoscene when I was in Oxford the other week, and he is bound and determined now to get modern demos working on XOs. I think this would make a really fantastic collection to ship... and a nice language-free encouragement to learn to hack (or make art and music :-). I would love if one of these demos (running in, say, 2% of CPU time) could replace the boot-time animation. Should much more interesting than our present incredibly staid bootup. Bonus points, of course, if the same demo is available in some Activity for students to dissect. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. --Ben P.S. This cross-posting is getting ridiculous. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] MP3 to ogg converter
I don't know why mp32ogg doesn't work for you, but there are other options. Maybe the easiest is to download the ffmpeg2theora executable: http://v2v.cc/~j/ffmpeg2theora/ffmpeg2theora-0.27.linux32.bin You'll have to use chmod +x to make it executable. ffmpeg2theora can produces audio or video. You only want audio, so you should use the --no-video flag. Another options is to decode your MP3 files to WAV, and then encode the WAV files with oggenc, which is in the vorbis-tools package (and might already be installed). --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Read PATCH] don't break if HAL is not available
On 06/16/2010 06:22 PM, Sascha Silbe wrote: +except dbus.DBusException: +pass It might be worth logging an explanation like NOTICE: Battery tray icon not displayed because HAL is not available. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Displaying the current status of system resources (such as memory, cpu)
On 06/15/2010 05:48 PM, Anish Mangal wrote: Sugar presently lacks a means to display the current status of system resources such as free memory, CPU load, etc. I'd like form an opinion as to what should be the ideal way to make these numbers available to the user. That's a great question! The original Sugar design specifically called for the Home View's Activity Ring [1] to display the memory usage of every running activity, and there were even test implementations of this. It proved difficult to measure memory usage well, and the Activity Ring was dropped with the Sugar 0.82 interface redesign. However, tools for measuring memory usage in Linux have improved since then. I think showing the memory usage of each activity would be very useful. Showing per-activity CPU usage would also be interesting, although I think it is both harder and less useful than memory usage, because it changes so rapidly. Perhaps an icon (or a set of icons) could be added to frame to graphically display real time data, their context menu revealing more detailed information. I personally think that per-activity numbers are often more interesting than system-wide numbers. As such, I would associate the resource utilization statistics with each running activity's icon in the taskbar (top frame bar). The problem is how to display the information in a way that is discoverable but not intrusive. --Ben [1] http://wiki.laptop.org/go/Activity_ring signature.asc Description: OpenPGP digital signature ___ 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.
On 06/12/2010 10:49 AM, Bernie Innocenti wrote: Besides, the assumption that VCS-style deltas will work well with the binary files stored by most Sugar activities is... wishful at best. It is one thing to say that we need a new datastore, and another to say what the new datastore should look like. I believe we have consensus on the first part, and I'm fairly sure we don't have consensus on the second. For the record, I am pushing a proposal in which no deltas are computed. Files are stored as whole files. Instead, I want each datastore object version to consist of an entire directory. To save space, files that are identical inside multiple objects would only be stored once on disk. This allows us to store and launch Activity Bundles directly from the journal. It also allows slight modifications to objects (including activities) to be stored efficiently if the object consists of multiple files and not all of them are changed. This is the de-duplication approach that was favored over three years ago [1]. I think Martin has listed some important use cases, and we should consider them carefully. One way to do that might be to try to reach a consensus on design. I believe the last attempt at this was over two years ago [2] ... and produced many good ideas but ultimately not much code. --Ben [1] http://lists.sugarlabs.org/archive/sugar-devel/2007-April/002344.html [2] http://lists.laptop.org/pipermail/community-news/2008-January/95.html , section 10. --Ben signature.asc Description: OpenPGP digital signature ___ 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.
On 06/10/2010 11:48 AM, Martin Langhoff wrote: - 0install and Vala are controversial, risky and not focussed on pressing end-users' needs. Yes there are some benefits and potential to both (otherwise Aleksey would not be working on them! :-) ) but they also break lots of toys. In my view, OLPC's ARM announcement creates a pressing problem of avoiding total confusion and fragmentation between different CPU architectures. 0install is, in my view, the most promising candidate solution. (I think the mention of Vala here is a red herring. The Vala sugar-toolkit effort is deliberately independent of Sugar version. It merely provides a new executable that activity developers may opt to include in their activity bundles.) - 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 the past three years. Perhaps you should publish your thoughts on DS architecture, or even just a list of use cases that you believe have been overlooked. We need _a good, polished DS that covers many aspects sanely_... a new DS is unlikely to do so. Do you think our current datastore meets your criteria? The consensus among the developers seems to be that our datastore does not live up to our goals for data management. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Enhancements to Pippy UI
Looks good to me, though I haven't tested it. A comment on if not self.initiating, to explain the intent, might be nice. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] stopwatch activity
On Tue, 27 Apr 2010, Sameer Verma wrote: I noticed something interesting with he stopwatch activity on the XO 1.5 C2 with build 120. When the XO goes into suspend, the clock stops display, but upon resume, will show actual time elapsed (clock keep counting). Mark also works correctly, displaying the time when the Mark button is clicked, irrespective of the display. I'm not sure what the behavior should be, though. I think that's fine behavior. Most stopwatches don't stop running by themselves, so I don't see why ours should. Should the activity prevent suspend? My philosophy is that suspend should be _absolutely transparent_ to the user; i.e. its effects should not be detectable, in the same way that processor voltage scaling is undetectable. This suggests that Stopwatch should inhibit suspend while it is visible onscreen. I'm reluctant to do this, though, because it feels like an ugly hack. The right solution would be for the suspend system to recognize that Stopwatch has a timer set to expire in 100 ms, and postpone suspend. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove the keep button from the default activity toolbar
Sascha Silbe wrote: On Wed, Apr 21, 2010 at 07:35:44PM -0400, Chris Ball wrote: The Activity toolbar with the Journal entry title, sharing, - Keep and Stop buttons + and Stop button Nitpick: please remove the comma after sharing. http://en.wikipedia.org/wiki/Comma In English a comma may or may not be used before the final conjunction (and, or, nor) in a list of more than two elements. A comma used in such a position is called a serial comma or an Oxford or Harvard comma (after the Oxford University Press and Harvard University Press, both prominent advocates of this style). In some cases use or omission of such a comma may serve to avoid ambiguity: Don't complain about the comma. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] nuevos idiomas
Kevin Mauricio Benavides Castro wrote: Hola como estan a todos los de la lista actualmente se entregaran XO en las dos regiones autónomas de Nicaragua la cual el lenguaje natal de ellos es miskito la cual me gustaría saber la forma de integrar este lenguaje a Sugar Mas información [http://en.wikipedia.org/wiki/Miskito] Kevin: Necesitamos añadir Miskito a http://translate.sugarlabs.org/. Imagino que quieras http://en.wikipedia.org/wiki/Miskito_language y no http://en.wikipedia.org/wiki/Miskito_Coastal_Creole. Sayamindo puedo añadir el idioma en ese sítio. Despues, necesitamos traductores que pueden hacerlo por su browser. Sayamindu: Kevin wants to translate Sugar into the Miskito language of Nicaragua (links above). I'm not sure if the Miskito native language or the Miskito-English Creole is the target. Neither is presently available in the translation system. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSOC 2010: Speech Recognition in Sugar
I think your proposal is very interesting. It contains a number of different ideas. One major division is between Voice Commands and Speech Recognition. Each of these contains many other possibilities. My biggest suggestion is to specify further which possibilities you want to work on. I recommend you schedule the _easiest_ thing first, before moving on to the hard things. Most GSoC students are too ambitious and never produce anything useful. Some specific ideas: Voice Commands: - integrate with a text-command system like Gnome Do [1], so that the commands are accessible through the keyboard as well as microphone. Also look at Perlbox [2]. (Note that neither Gnome Do or Perlbox can be used directly.) - integrate with GnomeVoiceControl [3], which already uses PocketSphinx and should be highly compatible with Sugar. This could allow voice control of unmodified Activities. Speech Recognition: - supply text to any unmodified activity - control input language easily for multilingual users [1] http://do.davebsd.com/index.shtml [2] http://perlbox.sourceforge.net/ [3] http://live.gnome.org/GnomeVoiceControl signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: change to XO sleep behavior
Paul Fox wrote: now: in the new scheme, the idle sequence has changed: after a fairly brief period of inactivity, the system will suspend, leaving the screen on. (the user may not even know this has happened.) assuming there is still no keyboard activity, a little later the screen will dim, and sometime after that, the screen will blank. Why will the screen blank? Why not just deactivate the backlight? Is the DCON's power draw sufficiently high that blanking the screen represents real savings? --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] Sugar Browser
Lucian Branescu wrote: I am inclined to choose the second for a few reasons. First, current webkit is much faster and uses less memory than current gecko, which has been especially visible on XOs. I'm not willing to accept this as proven. As for faster, see http://weblogs.mozillazine.org/bz/archives/020434.html As for memory usage, see http://dotnetperls.com/chrome-memory Webkit may be faster (although... with which javascript engine? on what graphics hardware? with which bookmarks/awesomebar system?) but I don't think it's so obvious. Previous comparisons on the XO have been deeply flawed because Gecko was scaling up all fonts and images, while Webkit was not. While gecko has superior extendability (XUL extensions), Browse isn't compatible with Firefox extensions, so anything would need to be rewritten anyway. Userscripts (Greasemonkey) serve most needs for now and if needed, an extension API akin to Mozilla's Jetpack or Chrome's extensions could be implemented. This sounds like an argument for staying with Gecko and adopting Greasemonkey and Jetpack. Second, webkit is being used by a lot of projects and has the backing of several companies. Gecko is far more widely deployed (~30% of all internet users). Furthermore, it is packaged more consistently across platforms/distributions. I'm not sure what this means, but it doesn't seem critical. Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not to diverge unless necessary) and it should be possible to not depend too much on any one of them. A thin abstraction layer could be written on top to handle most differences and it should only rarely be needed to go beneath this abstraction. While this would most likely not result in a browser than can switch engines at runtime, it should make any future porting much easier. I'm certainly not going to complain about an abstraction layer of this sort. As I've said before, I think a lot of developers would enjoy an engine-agnostic browser widget. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hi; GSoC?
Isaac Dupree wrote: I wonder if this Zero/Sugar project could use some GSOC support, or if there are more useful/important things to work on? I think 0install+Sugar integration would be a very valuable project. The Sugar Labs Oversight Board recently approved a statement that Sugar needs a mechanism for supporting access to non-Sugar dependencies. I think 0install fits the bill well. There are many Sugar developers who are skeptical of 0install's utility for Sugar. I think a GSoC project to add deep 0install support to the Sugar core would be a great way to resolve this issue. If the GSoC project produces a compelling result, then perhaps more developers will be convinced, and the project's code can be committed to Sugar mainline. There are many aspects to 0install, so you might want to focus your efforts on some subset of the 0install system. Some examples: Enable 0share for local sharing of Activities. Use 0install's cryptographic identifiers as indices in a commenting system (This activity is super-fun and never crashed for me.) Add 0mirror support to the school server (XS), possibly integrated with ASLO mirroring. Use 0test to improve Activity reliability across different Sugar versions, distros and hardware. Add 0compile to Sugar for running on unusual architectures (e.g. MIPS) Add 0publish support to the Develop activity, so that users can easily create and publish Activities. Add 0install support to the Journal. and many more --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] multiple IM accounts
Tomeu Vizoso wrote: But if someone has good ideas about how to expose contacts from mutiple accounts, here is the thread. I think there are lots of interesting ways to do that. For example, Bitfrost specifies that each user is identified by a cryptographic public key. To certify that an account is mine, I could include a tag somewhere in the buddy properties that displays my public key and signs the identifier with my Sugar private key. Then Sugar can safely merge any two buddies with the same public key (after verifying the signatures). Really, though, I am strongly in favor of implementing, stabilizing, and releasing network switching _before_ implementing concurrent network logins. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
Aleksey Lim wrote: * the major issue here that ASLO is not particalr deployment oriented portal, e.g. in OLPC case, mentioned issue is mostly means nothing since OLPC can effectively add/remove any component they think is useful for their users I don't understand this claim. ASLO is seeing literally millions of downloads from OLPC deployments. Probably 99% of ASLO traffic is from OLPC's users. As for the rest... I think .xo bundles should be absolutely free of binary executables, or anything else that depends on more than the Sugar Platform. We should then introduce a different (better!) bundle format that supports such dependencies, based on 0bundle, 0install, etc. As a temporary codename, call it .x0. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
Aleksey Lim wrote: what ASLO is, in my mind it was deployment agnostic thus if we have packages for 0.84 on bunch of distros, ASLO activities that are stated 0.84 ready should just run. I agree. OLPC needs this as badly as anyone. OLPC already supports users on a mix of Fedora 9- and Fedora 11-based systems. For all I know there might still be a few running Fedora 7 and Sugar 0.82. The situation is only likely to get more mixed in the future, and OLPC appears to be moving seriously toward ARM-based laptops, so even individual OLPC schools will be running a mixture of different CPU architectures. As for the rest... I think .xo bundles should be absolutely free of binary executables, or anything else that depends on more than the Sugar Platform. We should then introduce a different (better!) bundle format that supports such dependencies, based on 0bundle, 0install, etc. As a temporary codename, call it .x0. well, and it was the main purpose of SLOBs request, to know how sugar should move forward. And once more it is not my idle curiosity, in my mind ASLO turns to be a garbage heap of blobs when there is no chance to know will particular blob run in particular environment or not I don't think SLOB can help much here. I think we are already approaching consensus. Part of that consensus is: we can't afford to just drop all the incomplete .xo's that require external dependencies or include non-portable executables. Before we can clean up the current mess, we need a solid, supported solution for those Activities. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
Bernie Innocenti wrote: My only concern is that 0install seems to be itself another prototype packaging format, with plenty of crucial features still missing. For example, Aleksey was telling me last week that people build binaries on their personal desktops because there's not yet a real build cluster like Koji or Suse buildservice. 0install is just a specification and some tools. It's not even a distro. Of course there's no central build cluster. If we want to target many different distributions, then we will have to provide our own build machines... many of them (possibly VMs). Meanwhile, distros are repackaging our xo bundles into native rpms and debs... Are we sure we couldn't just sit and let the distros do their job? No distro packager in his right mind would offer packages for 90% of the activities on ASLO. They're crap. This is as it should be. If Sugar is working as intended, 99% of Activities will be crap. This is because the purpose of Sugar is to invite novices to engage actively in software development. Novices make bad stuff, and we want to install and run that stuff. This means we can't rely on any transmission medium that requires human approval. James Simmons has written a book about how to write Sugar Activities. I want novices to read his book and make new, bad Activities. I want to install those Activities as soon as they're written... may even before they're totally written. This is the nature of open collaborative development: you run other people's pre-alpha software. I also want novice developers to be able to install each other's bad activities without having to learn how to produce distro bundles and then shove them into their system package manager. I don't want the developers to have to learn three different bundle formats, and then build six different bundles for different versions of different distributions. I definitely don't want to make them submit their software to five different distro bureaucracies, and then fight through QA five times. I don't want to wait six months before I can try their Activities. I'm convinced that the unprivileged installation issue is easy to overcome once we agree that native packages don't stink and are not more complicated than they need to be. Native package systems are highly tuned for their purpose, not for ours. It's not even really the formats that are the problem. It's the software that processes them, and the bureaucracies that control the repositories. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] universal reference to datastore objects
Walter Bender wrote: This topic comes up now and again (e.g., http://cscott.net/Publications/OLPC/ufrgs-talk.pdf). I raised it in the context of wanted to create SVG files with embedded image data. Yep, we've had this discussion many times. My first was April 2007: http://lists.sugarlabs.org/archive/sugar-devel/2007-April/002342.html walterbender silbe: is there a way to find the actual path to, say a png file in the datastore, that I can then reference, or do I need to copy the data to the filesystem in order to reliably refer to it. What happens when that png's datastore entry is deleted? How is the datastore, or the user, supposed to know which objects should not be deleted because other entries depend on them? This is the dependency tracking problem, and so far every time it's come up the conclusion has been that we would rather force an explicit copy than invent a dependency handling system. Ideally, the datastore can be structured so that duplicates are actually only stored once on disk, thus recovering the efficiency advantage. To achieve this, we must make datastore objects be not a single file, but a directory of files. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] multiple IM accounts
Tomeu Vizoso wrote: as part of the effort to make Sugar a more normal Telepathy client, Sugar should become able to deal with more than one IM account active concurrently. I think this is a good goal, but it creates some incredibly tricky UI/interaction problems. I think an important first step is to allow using more than one IM account _non_-concurrently. Right now, Sugar provides no user interface for showing available accounts and switching between them. Getting such an interface would be very useful. I think it would provide 70% of the utility of concurrent accounts, with only 25% of the effort. Once we have account switching working (and maybe even released), then we can try to figure out how to expose multiple simultaneous accounts. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] webcam images and control
Aleksey Lim wrote: On Thu, Feb 25, 2010 at 03:39:26PM +0100, Emmanuel Di Folco wrote: I would like to be able to : - control the gain or integration time of the camera (mode Photo, not video) in order not to saturate (this is obviously feasible, since the images taken during the day are not saturated !) - eventually restrict the size of the screen window that is considered by the 'automatic gain adjustment algorithm' (where I would insert the moon) The automatic gain adjustment is performed in hardware, not software. In the standard mode, the CPU has no control over the camera's gain/exposure time. It may be possible to put the camera into a manual mode, where the CPU can control gain and other parameters, but I do not know how to do this. The best person to ask is Jonathan Corbet, who wrote the camera's driver. However, the camera's interface has proven difficult to work with and poorly documented, so many advanced functions have not been implemented in the driver. On the XO-1.5, even basic camera functionality is still not working correctly. - gather the raw images, not the JPG compressed ones. I did manage to do this on the XO-1. You can try the instructions from: http://lists.laptop.org/pipermail/devel/2008-February/011029.html This code also controls the integration time by acquiring many images and averaging them. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] webcam images and control
Jonathan Corbet wrote: All of the standard parameters are controllable through the normal V4L2 interface; that includes gain, saturation, etc. It all works. Fantastic; thank you. That sounds like big progress since the last time I looked at this ... two years ago. I guess it's time to take another look at a high-quality photography activity. On the XO-1.5, even basic camera functionality is still not working correctly. I'm looking at the flip issue today. What other basic functionality is not working correctly? I haven't been involved with this, so I can only speculate. #9853 suggests that the automatic gain control on XO-1.5 is not functioning as well as on the XO-1. I'm sure you know more about this than I do. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Video Chat, Video Editing and VOIP activities for Sugar
Manusheel Gupta wrote: Dear friends, 6 developers working at SEETA http://seeta.in will be spearheading the design and development of video chat, video editing and VOIP activities in Sugar starting Feb. 15. Great! 1. Video Chat - Pidgin (http://www.pidgin.im/) 3. VOIP activity - Shtoom (http://divmod.org/trac/wiki/ShtoomProject) I think you'd be better off starting from Empathy (http://live.gnome.org/Empathy), which already provides both features and is built on the same communications platform (Telepathy) that Sugar already uses. 2. Video Editor - PiTiVi (http://www.pitivi.org/) Yes. PiTiVi is the ideal starting point. Wish to have your feedback on issues, implementation strategies and external dependencies that we might have overlooked. Definitely talk to the Telepathy developers (on their mailing list and #telepathy on freenode). They are very helpful. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] 'Resume' vs 'Start a new' Activity
Simon Schampijer wrote: When they resume a previous activity, and they wanted to start a new one, I have seen learners erasing the previous content and keep on working in that activity. This is the purpose of resume-by-default. The idea arose in response to feedback from Uruguay, where students routinely filled their disk. The situation became so severe that, infamously, children in Uruguay began to memorize the shell commands required to erase the Journal by force. If you are working on systems with larger than 1 GB disks, or students who do not use the machines full-time, then you will of course be far less likely to encounter this problem. This is not to say that I know what the right solution is; I'm not at all sure. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Activity
Mark DeMayo wrote: I am in the olpc class at RIT and I was looking for some feedback on an idea that I had for an activity. Here is a link to my wiki which includes an example of the activity. Any feedback will be appreciated. Thank you. I think it's great. Three points: 1. Users probably don't want to play many games of the same operation (e.g. x+y=10), and the teacher probably doesn't want to create a new game for every operation. You should allow users to select a range of operations (e.g. numbers up to 12, + - and *) and have the game select a random operation from the set for each game. 2. There are some interesting possibilities for using network collab between users and teachers, but work on that last. To start, users should just punch in the operation (or range of operations) when the activity launches. Teachers can just tell the students what settings to use, and then look at the screens to verify. 3. The visual structure of the game seems almost identical to Gnome's Tetravex. In the spirit of Open Source, you should consider reusing the Tetravex gameboard display code. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
Aleksey Lim wrote: So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. -1 1. Fragmentation is bad. We should instead attempt to unify our development sites under an interface that is both friendly to novices and efficient for experts. Fragmentation prevents questions from reaching people who know the answers. 2. Without a much more detailed description of the website, it is impossible to judge whether it is worth building. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
Aleksey Lim wrote: collab.sl.o shouldn't be development site but central point there devs, users, doers, educators meet. Thus it shouldn't dublicate sites like wiki/track/etc. What do you mean by meet? Are you proposing to run a forum? (We already have http://en.forum.laptop.org/) --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
Sayamindu Dasgupta wrote: This feature would add a sugar.gettext module, which, if used by activities, will search an alternative path (configurable via GConf) for translations before looking into the activity directory (where the translations present in the original release bundle exist. Can't we do this with unmodified gettext by setting the LOCALEDIR envvar? --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
Benjamin M. Schwartz wrote: Sayamindu Dasgupta wrote: This feature would add a sugar.gettext module, which, if used by activities, will search an alternative path (configurable via GConf) for translations before looking into the activity directory (where the translations present in the original release bundle exist. Can't we do this with unmodified gettext by setting the LOCALEDIR envvar? s/LOCALEDIR/TEXTDOMAINDIR/ --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
Sayamindu Dasgupta wrote: On Tue, Jan 5, 2010 at 11:03 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Benjamin M. Schwartz wrote: Sayamindu Dasgupta wrote: This feature would add a sugar.gettext module, which, if used by activities, will search an alternative path (configurable via GConf) for translations before looking into the activity directory (where the translations present in the original release bundle exist. Can't we do this with unmodified gettext by setting the LOCALEDIR envvar? s/LOCALEDIR/TEXTDOMAINDIR/ Ideally it would, but I don't think all programs/libraries honour this. Sure. The question is whether python's gettext module respects this. If it does, we don't have to make a python sugar.gettext module, and we don't have to modify the activities. If python's gettext isn't susceptible to environment variables, we can do it using a one-line call to gettext.bindtextdomain. We might even be able to hide that call inside import sugar.activity to avoid modifying the existing activities. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
Sayamindu Dasgupta wrote: What I'm looking for is some sort of fallback mechanism in gettext, which would look for .mo files in the custom location first, and then in the usual location (as supplied to, say bindtextdomain()) I'm inclined to provide fallback by having Sugar synthesize a new directory of symlinked .mo files, as a composite of the available translation sets according to whatever rules we decide to employ. The activity can then be pointed to this directory with a single bindtextdomain call. I like this solution because (1) it minimizes the changes needed to activities, (2) it avoids forking gettext, and (3) it leaves the very tricky translation precedence logic in Glucose, which is where I think it belongs. This is especially important due to the complex interaction with security/containerization. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Star Chart Activity
Daniel Castelo wrote: Hi! In Uruguay we use Star Chart (http://wiki.laptop.org/go/StarChart) and the director of the astronomical observatory of Montevideo have some ideas to improve the activity. Speaking with the Autor (davewa) we found that our improves are in the roadmap of activity. If someone wants to help davewa great!!! davewa: would you consider putting StarChart into a publicly visible change-control system (e.g. git.sugarlabs.org)? This would make it a lot easier for potential contributors to play with the code. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release StopWatch-4
James Cameron wrote: On Wed, Dec 23, 2009 at 09:24:51AM -0500, Sugar Labs Activities wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4263 ASLO doesn't say ... but is there a git repo for this code and how are contributions handled? Thanks for the reminder. I just added in the link to the git repo, which is http://dev.laptop.org/git/activities/stopwatch/ If you have a better idea for how to list developer resources in ASLO, then the ASLO folks would probably be happy to hear it. As for how contributions are handled, I'm the maintainer, and so far no one's offered any contributions. If you'd like to add something, well, we should talk. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Zero Sugar
Aleksey Lim wrote: So, I have strong intension to switching development focus from core team, which develops sucrose - glucose(core) and fructose(some core activities) to wide range of developers/doers thus some kind of decentralization of development process. I agree. I think this has been a central part of the Sugar design philosophy from the beginning. I think your message is very much on the right track. [snip] * I hope to see many shell forks with implemented features like new sugar themes(wallpapers support, new icons etc.), Actions view implementations from non-core development/doers. The benefit they will have after 0install integration is more useful method to share these forks - just a regular entity on Activity Library that brings new shell to user environment I don't think this part will work as a regular entity on Activity Library, for security reasons. Any Activity that hooks so deeply into the shell is no longer safe to run. It is running with the full authority of the user and can violate the user's privacy or interfere with the user's actions. In orders to encourage users to become doers, Sugar is designed to make sure that Activities are always safe to run (thanks to Bitfrost/Rainbow protections). I would of course support an effort to wall off parts of the shell in a secure fashion, but so far almost no work has been done in that direction. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to enable activities
Bert Freudenberg wrote: On 14.12.2009, at 15:57, Walter Bender wrote: Did you check to see if they are in the List View (a opposed to the Circle View)? IMHO a small but really helpful interface addition would be binding F3 in home view to switch between List view and regular view. I support this. Also, F4 should cycle through activities, F1 should toggle the Neighborhood list view (once it is created), etc. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scrollbar width
Eben Eliason wrote: I think that retaining the functionality via some other mapping or shortcut would be nice (especially to offer the functionality as designed on the XO hardware itself), but I don't see reason not to improve the usability of Sugar on all platforms by increasing the scrollbars to a more manageable width. I think we need Sugar's appearance to adapt to the hardware it's running on, and this is a good example. On the XO, the small screen makes every millimeter precious, and the grab keys make the scrollbars of secondary importance. On large screens with no grab keys, maybe scrollbars should be wider. On small capacitive touchscreens, maybe there should be no scrollbars at all, etc. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] adding 3G devices support to sugar
Eben Eliason wrote: I'd be happy to sketch some icons. This is not so easy. Users care about whether a connection is wired or wireless. They care about how fast and reliable it is. They care about who they can talk to on it. They care about how much it costs to use. They don't care whether it's WiFi, EDGE, EVDO, GPRS, WiMAX, UMTS, LTE, HSPA+, CDMA2000-1x-RTT, or something else. I think the right way to go is to show an iconic representation of the wired or wireless nature of each step in the connection chain. i.e.: Internal wireless adapter: show classic outgoing radio waves. External USB wireless adapter: show a wire to a device with radio waves External USB wired ethernet adapter: show a wire to a device with another wire coming out External Bluetooth wireless adapter: radio waves to a device emitting more radio waves. This approach deliberately regards all through-the-air communications as being of a single type. For iconic representation, I think that's about the best we can do. We can, and should, show more in the detail palette. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
Aleksey Lim wrote: +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? The standard term is minor version number, so minor_version seems appropriate. --Ben http://en.wikipedia.org/wiki/Software_versioning#Change_significance signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sharing in Terminal
Sayamindu Dasgupta wrote: Hello, While going through Ben Schwartz's Shared Term feature proposal discussion page (http://wiki.sugarlabs.org/go/Talk:Features/Terminal_Sharing), I started to wonder if we could somehow implement readonly mode for sharing in the Terminal activity. After a weekend of hacking : I have managed to come up with the following: I like it. A read-only mode is definitely useful, albeit in a very different way from a shared interactive terminal. I couldn't figure out a way to grab the text from the terminal, so I ended up implementing Watch Me, which provides the same functionality (and much more general functionality), but in a much less efficient and integrated way. There are some UI things that will need to be worked out. Most obviously, the hidden split-screen is currently totally non-discoverable. I also think that N-to-N sharing might be more generally useful. For example, it could use the Terminal's tabs mechanism to show one tab for each user to all users. Perhaps both modes could be subsumed into one by providing a button for each user to show or hide her terminal. I can't tell from your e-mail what is working, exactly. I think it's important that TUIs like nano and less work properly, as far as possible. For users with different screen or font sizes, some difficulty is inevitable. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...
Martin Langhoff wrote: On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche dvanass...@gmail.com wrote: moving to mission control 5 and letting go of the admittedly antiquated sugar presence now ... If you play with a major component replacement - test it for scalability stability over wifi before doing a lot of integration work It's worth noting that moving from the Sugar Presence Service to Mission Control 5 would not alter our network protocols. This is purely a change in how the client software is organized. Neither regression nor improvement in wireless network performance should occur. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Mesh
Cecilia Abalde wrote: I think I understood salut ytelepathy gabble telepathy. My question now is: to salut telepathy works there must be some established network? for example a mesh network or a wifi network Yes. All of the Telepathy protocols require that there be a working local network connection. They operate on top of a network such as wired ethernet, wifi, or mesh. Of course, the interesting thing about mesh networks (and also ad hoc networks) is that they are very easy to create, because all you need are the laptops. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...
Martin Langhoff wrote: On Tue, Nov 3, 2009 at 2:41 PM, Gary C Martin g...@garycmartin.com wrote: Other activities that support some form of collaboration like Chat, Browse, Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't care who started the activity first, or who goes away. Are you positive about this? I don't meant to troll -- but I am seeing issues (with Chat for example) where if the leader goes, 3rd parties cannot join anymore. That is remarkable, and worth investigating. The Chat activity in particular is designed to survive loss of the initiator, and has been since the very first release. One related issue is http://bugs.sugarlabs.org/ticket/934 . Once the initiator leaves, the initiator can no longer re-join due to an issue in the GUI. That bug contains a patch, but it's unclear to me whether that patch was ever applied. Maybe Tomeu can clarify the situation. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] XO-2 canceled, replaced by XO-1.75 and XO-3.0
The ever entertaining Prof. Negroponte surpasses all expectations in his latest performance: http://www.xconomy.com/boston/2009/11/02/negroponte-outlines-the-future-of-olpc-hints-at-paperlike-design-for-third-generation-laptop/ The usual OLPCNews analysis at http://www.olpcnews.com/people/negroponte/negroponte_xo-175_goes_arm_xo-2_is_cancelled.html --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Terminal.xo patch: do not die if the cwd is gone
Martin Langhoff wrote: use GNU Screen! :-) -- now that would be something: GNU Screen integrated with xterm. Not to toot my own horn, but GNU Screen + OpenSSH + Terminal.xo = ShareTerm : http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014165.html Doesn't help you with persistence, though, unless you really want to leave Screen running forever. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Error in watchme client side
Dave Bauer wrote: I am testing watchme. I am consistently getting an error in the client ImportError: libgnutls.so.13: cannot open shared object file: No such file or directory. Tested on soas-strawberry. The server part is not reporting any errors in the logs. I believe the problem occurs because of binary incompatibility between Fedora 9 and Fedora 11. Watch Me is self-contained on Fedora 9 systems like OLPC-8.2, but on other distributions it is not self-contained, and may require the installation of additional dependencies. In the case of Strawberry, it appears that you need to do yum install gtk-vnc-python because Watch Me's built-in version of gtk-vnc-python no longer functions on Fedora 11. I apologize for the inconvenience. I hope that Sugar's handling of binary executables in activities will improve in future versions. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On Zeroinstall and Sugar packages
Sascha Silbe wrote: On Mon, Oct 19, 2009 at 11:42:32PM -0400, Benjamin M. Schwartz wrote: 0compile, combined with Zeroinstall's support for source bundles, enables us (1) to approach true platform-independence and (2) to provide users the opportunity to modify the source code of a package and rebuild it in a natural way. So unless the sender and receiver architecture match, the receiver needs to build the package from source and requires the usual tools (gcc, autoconf, etc) for that? How much space would those take up on the XO-1? I'm not arguing against it, BTW, quite the contrary: I've suggested a similar scheme [1] in the past. I think my answer is sometimes. There are many possible scenarios. For example, if there is good internet access, and the package maintainer has compiled the package for many platforms, then the sender only needs to send the package's name (which is a URL) and then the receiver can install the arch-appropriate bundle from the internet. If there is no internet access, but the sender has kept binaries (and all dependencies) for both architectures, then the receiver can get all needed binaries from the sender. If there is a school server, it can act as a 0mirror [2], maintaining a cache of many Activity packages, including their dependencies, for all the school's architectures. If there is no school server, and the sender does not have the arch-appropriate packages, the receiver may use 0share [3] to see if there is anyone else on the network who has them. Bundles are GPG-signed for security. Only after all those things fail do we need to talk about compiling from source. Then we have interesting questions like whether it's worth the space overhead to require all bundles to include source, and whether to include things like compilers that are needed to rebuild them. My feeling is that all Activity bundles should probably come with source code, but automatically downloading all the build-time dependencies should be a configuration option that can be disabled on systems with constrained disk space or bandwidth. [1] http://wiki.sugarlabs.org/go/Activity_Team/Packaging_Ideas#combined_Source.2BBinary_package Yeah, what I'm describing is very much like that ... except somebody already did all the work for us! [2] http://0install.net/0mirror.html [3] http://0install.net/0share.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] On Zeroinstall and Sugar packages
I have long argued that the only way to achieve reasonably bundle behavior in Sugar is to restrict ourselves exclusively to carefully selected interpreters. After speaking with the Zeroinstall developers, especially Thomas Leonard, I have changed my mind. Zeroinstall's tools and design are extremely closely aligned to Sugar's goals for package management. They have anticipated almost every use case that we have described. Their solutions are not perfect, but they make the best available compromise when compromises are necessary. A month ago I wrote: I really do believe we _could_ implement a highly usable system in which Activities are completely self-contained portable bundles. For example, see Android. I don't believe that we _have_ implemented such a system. I do believe that we _should_, because it maximizes the ability of users to predict how their system will behave, and predictability is the core of usability and security. My principal reason for wanting Activities to be highly restricted and purely interpreted was to enable users to push bundles between machines and have them just work without worrying about whether the dependencies are installed or what CPU architecture is in use. Zeroinstall can solve the dependency problem with 0export [1] and 0compile [2]. 0export is a tool to produce a bundle for a given program that contains all needed dependencies for all target architectures in a single file. 0compile, combined with Zeroinstall's support for source bundles, enables us (1) to approach true platform-independence and (2) to provide users the opportunity to modify the source code of a package and rebuild it in a natural way. My epiphany is: the alternative to a system like Zeroinstall is not an idealized purely interpreted bundle type. It's the mess we have now, where bundles contain all sorts of bizarre binary blobs, and make a variety of fragile assumptions about the rest of the system. We have no way to prevent Activity authors from doing this, and this is likely to remain true. Even I am guilty of including binary blobs, in Watch Me [3], because there was no other way to make the Activity work. This means that I've distributed binary code without the source. This is counter to our educational goals, and counter to our goals of building a reliable, predictable system. We need to bring native-code Activities aboveboard, and Zeroinstall is by far the most promising avenue I've encountered to make that happen. --Ben [1] http://0install.net/0export.html [2] http://0install.net/0compile.html [3] http://activities.sugarlabs.org/sugar/addon/4205 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] friendview.py
Tim McNamara wrote: Naturally, people will probably want to click on that question mark. Would we be able to have a dialogue like Search for activity %s? % name, which if accepted opens up Browse and searches http://activities.sugarlabs.org to download it? That would be about ten times better than the current behavior. This would be easiest if you can p2p file share activities... I've played around a bit, but it doesn't look especially obvious. Yes, that would be, by far, even better. It shouldn't be incredibly difficult, since Telepathy provides us with a high-level file transfer operation, but there's still some code required to (1) request the transfer, (2) create a bundle if necessary, (3) transfer the bundle, (4) install the bundle, and then (5) launch it. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] friendview.py
Wade Brainerd wrote: Yeah, P2P activity sharing would be awesome. http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles says Activities are meant to be shared between children. If a child doesn't have the activity, it is automatically transfered to the child when he or she joins the shared activity. but I don't believe this was ever implemented...? That's correct. Automatic activity sharing has been the plan for years now, but has never been implemented. For a while this was because there was no good way to transfer large files over Telepathy, but this has now been resolved, and it is simply waiting on someone willing to dive in. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Mesh
Cecilia Abalde wrote: Hi, I have read a lots of documents which explains what kind of packages the mesh has got, for example, beacon, probe response, probe request, the ones for discovery the path. But i can't join all this information and understand how one XO can see another XO in its neighbourhood. I hope you can understand me and help me. The connection you are looking for, between the wireless mesh network and the graphical representation in the Neighborhood View, is the Presence Service [1] and Telepathy-Salut [2]. These pages are in English, but we can help you with translation if language is a problem. This is a complicated subject, so please feel free to ask more questions. --Ben [1] http://wiki.laptop.org/go/Presence_Service [2] http://wiki.laptop.org/go/Telepathy-salut signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
Michael Stone wrote: In the circle view, I'd like to see the layout algorithm expanded to lay out arcs of smaller option icons each with the same prelighting and saturation behavior as partial halos around the exterior perimeter of the activity icons. It took me a while to get this, but now that I understand it, I like it. The basic idea is to make the current palette appear with no delay on rollover, but not directly under the cursor. The user is not dissuaded from clicking on the primary icon, which remains accessible, but the secondary options are also immediately visible. The obvious problem with this is that the palette may cover another nearby icon, preventing the user from accessing it. A simple solution, in the circle view, would be to make the palette always pop out, away from the center. Michael proposes a more aesthetic solution, changing the geometry of the palettes to curve around the outside of the circle. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Mentor request for PyDebug Activity
From: George Hunt georgejh...@gmail.com I'm very excited to hear about this project, and I hope you'll keep us updated with your progress. Anything that makes Sugar a better self-hosting development environment is tremendously valuable for us. At this point I'm debating whether to substitute gedit for the functionality of abiword. IMHO, your best option is to use gtksourceview [1]. This is the GTK source code editing widget that is used by gedit. gtksourceview provides syntax highlighting, line numbers, and undo/redo functionality. You can see it in use in Sugar in the Pippy source code [2]. Unlike gedit, gtksourceview is guaranteed to be present in any Sugar installation. Good luck! --Ben [1] http://projects.gnome.org/gtksourceview/ [2] http://git.sugarlabs.org/projects/pippy/repos/mainline/blobs/master/pippy_app.py#line123 signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-pippy dependencies
Bernie Innocenti wrote: Questions: 1) are there lighter-weight alternatives for the most popular uses of numpy? No. It has no competition, and is used by virtually every program that uses python and performs array manipulation. I think it would probably be part of the python standard library except for political issues (now mostly resolved). 1) how many of the existing activities actually depend on numpy? Many. I know that Distance uses it for FFT, for example. I believe Calculate requires it as well, because it uses matplotlib for plotting, and matplotlib requires numpy. 2) would it be hard to remove this dependency from them? Yes. Numpy provides high-speed math for python. 3) Should we define a policy for deprecating components of the Sugar Platform in new revisions? All evolving standards need to find a balance between new features with old feature removal to avoid unbounded bloat. Maybe, but numpy is not a good example. Virtually all science-oriented programs using python make use of numpy. 4) Even if numpy is going to stay around for the Sugar Platform, could we remove it from Pippy and other core activities to save resources and allow shipping lighter weight live distros? Only if you don't mind that many Activities will mysteriously fail to launch. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-pippy dependencies
Michel Alexandre Salim wrote: I seem to recall several Python apps moving from numpy to numarray in the past, so it should be doable. I strongly suspect you are backwards. Numarray is the deprecated predecessor to numpy. http://www.stsci.edu/resources/software_hardware/numarray/numarray.html numarray is being phased out and replaced by numpy. ... we expect to stop supporting numarray entirely in the middle of 2008. If you have a choice (i.e., you do not depend on existing software that uses numarray), we strongly recommend starting with numpy instead of numarray (or switching as soon as possible). signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] SoaS: Searching for Decision Panel volunteers.
Tomeu Vizoso wrote: On Fri, Sep 25, 2009 at 15:37, Peter Robinson pbrobin...@gmail.com wrote: I presume there's a defined amount of people on this panel. When and where is the chosen panel announced? It's being discussed right now in the SLOBS meeting in #sugar-meeting. Oops. I seem to have missed the meeting, and a decision panel was formed. For the record: I regard the formation of this Decision Panel as entirely unnecessary, because I feel we have reached consensus on all the relevant issues here. In my opinion, our consensus includes: 1. We greatly appreciate the work of those who have contributed to SoaS Strawberry and Blueberry. We regard these products as valuable, critical distribution mechanism for Sugar, and we will do what we can to ensure their continued development. 2. We have historically recommended Sugar distribution systems based on their suitability to the person to whom we are making the recommendation, and we will continue to do so. We will not attempt an artificial impartiality. For example, we would not recommend the Ubuntu Sugar packages in versions of Ubuntu where those packages are buggy, unless the person to whom we are making recommendations has a pre-existing preference for Ubuntu that outweighs the bugs. 3. We will support the work of the SoaS Strawberry team by providing them with assistance in marketing, hosting, and engineering. We would provide such support to anyone making a credible effort to distribute Sugar. If the creators of SoaS Blueberry or future versions decide that they require less of our assistance in these areas, as might happen if they find a new home under the auspices of a Linux distribution, we will gladly continue to support them in areas where they still require support. 4. We will entrust the marketing team with labeling products in a way that is amenable to all parties, including the users and creators of Sugar-based systems. The Marketing team is, and has been, responsible for ensuring that we choose names that do not harm the mission by creating confusion. 5. We will not declare official long-term strategies based on uncertain technical assertions. In particular, we will not declare that any particular distribution mechanism for Sugar is and will always be preferred. As per point 2, our recommendations are always made in a specific context. As far as I can tell, this is more than enough consensus for everyone to work productively on the things they need to work on. I don't see any way in which an Official Decision would be helpful in this matter. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Daniel Drake wrote: 4. Sharing of activities between hugely varying systems: The only real solution to this that I have seen proposed is for *all* activities to switch to some kind of cross-platform VM platform (e.g. Java) ... I feel that the one available solution is not realistic or sensible, We're already doing almost everything in Python, which is essentially cross-platform unless you start shipping things that aren't Python. Java is a similar story. This is not unrealistic. and I feel this is of very little interest to deployments, who control and synchronize the systems (all running the same Sugar version on the same distro on the same architecture) and have good distribution mechanisms for their users. It's something we'd invest a hell of a lot of time into fixing, without benefit in the field. It's a huge benefit in the field when OLPC starts shipping XO-2, or when Lemote wants to compete for a contract, or when Intel starts putting 64-bit CPUs in their Classmates, etc. Even without architecture switches, distribution upgrades (e.g. F9 to F11) can and will break binary compatibility, so any deployment with different distro versions will begin to see a degradation in reliability. If you want to represent the interests of large, centrally managed, perfectly homogeneous deployments that never want to collaborate over the network with other deployments, then that's fine, but this is by no means our only target type. 5. Modifying activities: A noble and interesting goal but unlikely to happen in the field (remember, 6-12 years old users!). 0. When did 6-12 become Sugar's target age range? OLPC's documents typically said 6-16 ... and actually, there were negotiations with the AARP for use with elderly people. 1. Modifying activities is the reason for Sugar's existence. Everything else is just icing. The system is in Python to encourage user modification. The datastore is structured as a version control system so that it can be used to version control the source code. The application security architecture (bitfrost) exists so that users can safely share their modified programs. The collaboration system is designed to allow users to spread their improvements to the Activities. OLPC put a view source key on the keyboard. To me, OLPC is a trick to raise a generation of software engineers in developing countries, because software engineering is the one kind of serious industry that can be initiated without a huge capital investment, and performed from anywhere. It can therefore be used to bootstrap third-world economies. If you don't care about modifying Activities, and constructionist learning through software engineering, then I really don't see much appeal in Sugar. Surely Moblin, for example, is far more compelling. I certainly wouldn't call modifying activities unlikely to happen in the field, though, when Bill Kerr has his students modifying SVGs directly as XML in text editor. 6. Ease of creation of activity packages Moving to distro-based packaging will not effect the difficulty of developing activities, since packaging is something you do after development, not before. It will affect packaging and distribution. My suggested model (as employed all over the open source world) is that the developers would release source distributions and let distributions do the packaging and distribution. ... In many cases it will be enough just to point out to distros that you've developed an awesome new activity Most new activities are not awesome. They are very basic, because they are developed by novices, myself included. In Sugar, software development is a social endeavor, where people with only a little bit of experience make small things and pass them around, and quality improves bit by bit. Only a handful of our Activities, the ones developed under contract by OLPC, have reached any level of polish that would typically warrant distro packaging. There are already hundreds of Activities, many that we have never even heard of because they are just passed around within deployments such as Uruguay's. I haven't even mentioned the language and connectivity barriers between the users creating modified activities and the packagers who could add them to some repository. Activities are considered untrusted code, potentially malicious and likely insecure, so I would be even more averse to installing them in system directories, ready to be run by any user. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Michael Stone wrote: Consequently, I want to make using activities more like web pages. That's why I work on rainbow and on networking design. ... In my opinion, ideally, they click a URL and the software they clicked runs most of the time. They don't care what version is underneath. If they want to change it, they hit view source and edit. If they want to share it, they share the URL, however they like. Thank you for this perspective. I think this is a very helpful way to think about our software behavior goals, especially if we imagine our URLs as being a bit content-addressable. Lastly, about the idea of shipping everything in Python, or Java, or Smalltalk: Give up -- this works for mobile phones, not for things to think with! Programming languages are prime examples of things to think with. We're trying to provide people with lots of these, and with the best ones that we can find, remember? Hmm... but surely web pages are the prime example of a medium that contains an extremely limited variety of languages? I have come to accept that we should provide people with lots of languages, but I think we can, and should, choose our interpreters to retain independence of platform, and isolation from distro issues. Even x86 assembler can be such a language, given an appropriate interpreter [1]. For a particularly strange glimpse into the future: http://www.codebase.es/jsgb/ [1] http://www.qemu.org/qemu-doc.html#SEC69 signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Michael Stone wrote: As for interpreters -- I absolutely agree that they should be chosen carefully. I just think that the interpreter that we choose carefully should be the one that prepares to run a program (e.g. by fetching and installing it, or by caching it, etc) rather than the one that runs it. Does this distinction make sense? I'm not sure I understand you. My feeling is that the most important thing we can do in this area is to make it easy to write Activities that are intrinsically cross-platform. To borrow a phrase, one way to do this is to choose languages, and interpreters, that are incapable of expressing platform dependencies. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: What could be achieved with the .xo bundles that couldn't be achieved with an rpm? Let's not talk about .xo. .xo is just the JAR bundle format. What can you do with JAR that you can't do with RPM? 1. Produce them easily on any platform. 2. Tell the unpacked manifest at a glance without unpacking. 3. Be sure that no untrusted code needs to be run to perform the installation. There are many more things, mostly related to the dramatic simplicity of JAR. I don't understand how switching bundle formats for Activities would win us anything. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: El Mon, 21-09-2009 a las 19:13 -0400, Benjamin M. Schwartz escribió: 1. Produce them easily on any platform. At OLPC, I head this argument made many times, but it's moot: (1) one could create a bundle on Windows, but not test it. I'm not thinking about Windows. I'm thinking about Linux. I don't use an RPM-based distro, so I don't have the RPM tools lying around. I'm not especially comfortable with RPM or cpio archives, and I'm not sure how to inspect or create them. Same with .deb. 2. Tell the unpacked manifest at a glance without unpacking. All package formats support this. RPM does not, because of the pre/post scripts. The scripts may generate additional files. 3. Be sure that no untrusted code needs to be run to perform the installation. All package formats support this. I did not say support sometimes. I said be sure. Simplicity, so that it is possible to reason about the installation process, is a virtue. Using some restricted subset of the features of some existing format is certainly possible, but also creates enormous potential for confusion. rpm and deb optionally allow executing pre/post-installation scripts, which are not necessary for the majority of applications and can also be disabled. Actually, the ability to run scripts on installation is often requested by authors of content bundles. And this request should be denied, as should dependency handling. There are many more things, mostly related to the dramatic simplicity of JAR. Anyone likes simplicity, but jar files with no dependencies are really a *simplicistic* solution that doesn't work even in the most common real-world scenarios. We are not going to solve the common real-world scenarios. It is impossible for us. For example, we wish to operate on many different distributions. You know better than I that this means that we cannot rely on dynamic linking with dependencies, which is the most common real-world scenario. What we can do is to create new, special, highly restricted scenarios, and then demand that people package for them. One such scenario that I believe we can support with confidence is Activities written exclusively in Python, using only functions from a static list of blessed modules. I don't understand how switching bundle formats for Activities would win us anything. As I explained a few messages ago, using one of the existing package formats would enable us to use the existing package tools. Which we need in order to support a number of common features such as inter-package dependencies, multiple architectures, system upgrades, package signing... way too many to list them all. I agree, switching bundle formats would gain us a lot of these features. However, I don't think features such as dependency tracking are of much use to us, because we can't trust system package managers, and we can't afford to maintain our own complete distro and package database. The closest I can come to agreeing with this claim is to suggest 0install [1]. 0install is a completely user-side package management system, with support for multiple platforms, building from source, decentralized storage, cryptographic bundle identification, and unprivileged installation. It also comes with its own bundle format. The result is almost as bad as maintaining our own parallel-installable distro, but at least it's all already working. [1] http://0install.net/ signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: The use cases that work now would continue to work with any package format. That's definitely not true. One option (the one I thought you were advocating) is to make Activities just like any other software installed by the distribution package manager. That means they'd be RPM on Fedora and DEB on Debian. Two Sugar 0.84 x86 installs, one on Debian and one on Fedora, can currently push Activity bundles back and forth with some probability of success. If Activities in Sugar-0.88 on Debian are packaged as .deb, then clearly Fedora will have no idea what to do with them, and so pushing Activities over the network would no longer work. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Activity bundle format (was Re: Long-term support for Sugar)
Bernie Innocenti wrote: A fixed platform with infinite backwards compatibility is a dream even for an interpreted language. Java. Right now, we're just closing our eyes pretending that we are immune from the dependency problems and that the .xo package format will suffice. Do you really believe this? It depends what you mean. I really do believe we _could_ implement a highly usable system in which Activities are completely self-contained portable bundles. For example, see Android. I don't believe that we _have_ implemented such a system. I do believe that we _should_, because it maximizes the ability of users to predict how their system will behave, and predictability is the core of usability and security. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: Either we declare that there exists only One True Sugar Distribution running on One True Hardware Platform -- which is exactly the opposite of expanding the base for Sugar -- or we accept the increased complexity that comes from a real multiplatform scenario. Or, we bless a small number of completely self-contained virtual machines (e.g. etoys squeak, mozilla javascript, Sun Java, perhaps a restricted python), and then run them on any hardware. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity bundle format (was Re: Long-term support for Sugar)
Bernie Innocenti wrote: El Wed, 23-09-2009 a las 14:03 -0400, Benjamin M. Schwartz escribió: Bernie Innocenti wrote: A fixed platform with infinite backwards compatibility is a dream even for an interpreted language. Java. Java is just a marketing lie ;-) The official JVM did not even run anywhere, but on 3 specific systems until very recently, when it was open sourced. These days, there are plenty of Windows only, Linux only and Symbian Only applications written in Java. Besides, Java is not really an interpreted language: it can be statically compiled, and even the JIT can approximate the performance of C. Python, which is 10-20 times slower, must depend on C libraries to perform all the computationally non-trivial work. Moreover, we cannot control the evolution of Python. If you look at its past history, you'll see that, unlike Java, it's a language that likes to break backwards compatibility from time to time for the sake of cleaning up its grammar and runtime libraries. This is true. When Python was selected as the language of Sugar, there was a single vendor and a single hardware target, so VM opacity was not considered an important quality. Python certainly lacks it. Java, however, has excellent VM opacity, unless explicitly configured otherwise. It depends what you mean. I really do believe we _could_ implement a highly usable system in which Activities are completely self-contained portable bundles. For example, see Android. I don't believe that we _have_ implemented such a system. I do believe that we _should_, because it maximizes the ability of users to predict how their system will behave, and predictability is the core of usability and security. This is a noble goal, but much, *much*, *MUCH* harder and much, *much*, *MUCH* more constraining than just adopting a real package system with full blown dependency checking. It is certainly very constraining. It's also the only way I can think of to achieve the kind of universality that I desire. The motivation for offering a JVM on smart phones is definitely *not* vendor interoperability. In fact, some of them are intentionally not interoperable. I believe the design goal is creating a proprietary platform where only approved applications are allowed to run and perform only approved actions. The overhead in terms of performance and flexibility is significant and the consumers pay the price. We too are trying to create an environment in which applications' actions must be approved ... by the user. Also, Android is a nice example of a smartphone environment in which users are free to run absolutely any App that they choose. Because we're not in the business of creating a locked-down consumer platform, we don't have to castrate ourselves this way! We are trying to do something much more challenging: to build an operating environment that is usable, reliable, predictable, and educational, despite running in the Worst Case Scenario of computing: poor children in poor places. We can have 3D fractal zooming activities for Sugar that would run decently fast even on the XO. As you said yourself, Java is quite fast. Even C would be an acceptable language, if a compiler can be configured to provide an opaque environment. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: It's still too restrictive for external developers who would like to do more ambitious things, like Karma and Physics. Those would have to come and beg us to approve their dependencies. Karma is HTML+Javascript, for which we have an approved interpreter on the list, so it's not an issue. Physics uses Box2D, which would have to be rewritten in Java ... e.g. JBox2D [1], written in part by Eric Jordan, one of the brothers responsible for the Physics activity. [1] http://www.jbox2d.org/ signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Yamandu Ploskonka wrote: I for one had hoped that the utterly painful performance problems with Sugar were a price we were paying for total cross-platform compatibility though Python. I'm having my innocence crushed as I follow this thread... We would do well to clarify this. For the record: 1. It is easy to write totally cross-platform programs in Python. A simple program written in pure Python, using only the libraries that we provide, will typically be perfectly cross-platform. 2. Very complex programs using python are often not pure Python. They may rely on an unusual GTK widget written in C, or an image manipulation library written in C++, or some other external code that is imported into python as a module. This external module is typically a platform-specific binary blob that requires significant effort to rebuild for each platform, and potentially for each distribution. Such external modules are particularly necessary because Python isn't fast enough to do heavy computation in pure python. Some programs only use a little bit of python, and have most of their functionality in a separate platform-specific executable. For example, the Watch Me activity uses a bit of python code to configure collaboration, but most of the functionality is provided by a binary for x11vnc and libgtkvnc, which are written in C. 3. Java (and also C#/Mono) is different here because (a) it's fast enough to write just about anything, so people don't need to use external modules (b) the interface to native code libraries is extremely inconvenient so very few people use it (c) it's easy to disable the native-code interface entirely, ensuring that programs are fully portable. HTML+Javascript doesn't offer any native-code interface, and I believe the same is true of typical eToys. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Peter Robinson wrote: On Tue, Sep 22, 2009 at 12:09 AM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Bernie Innocenti wrote: Why would we care to have concurrent versions of the same activity for different user accounts? Our computing model is inherently single-user. LTSP. NFS with shared clients. Our computing model is not just OLPC. Surely for a LTSP style of install with thin clients you'd want something like RPM so you can centrally manage all servers and make sure they're running the supported version of the Activity. My experiences in that sort of env its much more locked down and centrally managed as that's one of the major advantages of such an environment. I have no interest in supporting lockdown. Sugar is explicitly exploratory, designed to ensure that every user has the ability to install, inspect, and modify the system as they choose. This is an important component of our educational mission. Without this feature, we provide precious little advantage over XFCE and Google Docs. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: Why would we care to have concurrent versions of the same activity for different user accounts? Our computing model is inherently single-user. LTSP. NFS with shared clients. Our computing model is not just OLPC. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: How does, for instance, Gimp manage to work perfectly on *all* Linux distributions? And how do all the other 19K packages in my distro manage to find *exactly* all the dynamic libraries they need when they are installed? By having distinct packages built separately for each distribution by experts. This is incompatible with our (or at least my) goal of allowing users to throw packages around as atomic objects, without internet access and without having to understand anything beyond my friend has Sugar, so it will work. It is also incompatible with allowing novices to generate first-class Activities. This is also incompatible with your proposal to choose RPM. The equivalent here would be to choose RPM on Fedora, DEB on Ubuntu, ebuild on Gentoo, tarball on Slackware, etc. We don't have to do anything special, either. Some Sugar activities have already been natively packaged in the main Linux distributions. They work as well as any other packaged application, and none of the original authors need to be concerned about how this magic was performed. What we can do is to create new, special, highly restricted scenarios, and then demand that people package for them. One such scenario that I believe we can support with confidence is Activities written exclusively in Python, using only functions from a static list of blessed modules. Sorry, I find this horribly restrictive. My favorite educational application, XaoS, would not even be possible in this scenario. Neither would Firefox, GCompris and many of the most popular activities that we offer on activities.sugarlabs.org today. With such a limitation, Sugar would be a really sad educational environment. I agree, switching bundle formats would gain us a lot of these features. However, I don't think features such as dependency tracking are of much use to us, because we can't trust system package managers, Why not? Because there is no way to build a single binary that will safely link with all the different distros' libraries and we can't afford to maintain our own complete distro and package database. Why would we have to? Several good distros already exist... just pick one. No, actually, let's pick many! We can't pick one, because we wish to run on them all. We can't pick many, because then users cannot share Activity bundles. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] SoaS: Searching for Decision Panel volunteers.
Philippe Clérié wrote: I don't quite understand this decision panel stuff. Is a different decision panel elected every time there is an undecided issue at hand? Or do we elect one group that remains in place for all unanswered questions, present and future? I sympathize since I'm also a bit confused. This is what I would call a policy decision. It's not an administrative or a technical problem that needs to be resolved. It's a choice between several, possibly equally valid ways of going forward. It's *policy* and that belongs to the board I would think. (Caution: I have not read the rules of engagement! :-)) The Decision Panel stuff is in Sugar Labs's Constitution, and the wording is fairly clear. The way I think of it, 1. The Oversight Board's task is to do all the routine administrative drudgery to keep Sugar Labs running, especially in regard to keeping our paperwork in order with the Software Freedom Conservancy. They should be elected for their diligence, not their insight. 2. In general, when decisions need to be made, they will be made on the mailing lists by rough consensus, running code, and sheer force of action. 3. When a question arises that causes the mailing list to deadlock in disagreement, and the issue must be resolved in a timely fashion, the Oversight Board may convene a Decision Panel. The Decision Panel must reach a conclusion on the issues in question, and write up a report on their decision. The purpose of the report is mostly to smooth the feathers of those who disagree, so that they can at least see that the decision, even if it was wrong, was at least made based on a process of careful reasoning with good intentions. 4. Everybody goes back to business, and because the Oversight Board was not responsible for the decision, those whose opinion was overruled do not have to feel that the project's management is somehow hostile to them. When people are threatening to fork the whole damn project, this is a good indication that it might be time for a Decision Panel. On the issue of who can say what SoaS is ... I think we can afford to flame a little more on the lists. --Ben Schwartz signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Mel Chua wrote: Friendly. Is there a one-stop shop I can go to where my problems will be fixed immediately? ... Consistent. ... And the support experience needs to be consistent. As explained above, teachers need to know that no matter what their problem is, if they spend 2 minutes reporting it at this location, it will be fixed N days later. And as soon as they've spent 2 minutes reporting it, they need immediate feedback and reassurance that yes, it's going to be fixed N days later; you were heard. These two things sound pretty much the same to me. They also sound absolutely impossible, taken strictly. Taking a more relaxed interpretation, you seem to be describing, in effect, a full-time professional support staff. In the first world, such staff are not uncommon. The public high school I attended maintains both an in-house sysadmin team and a standing contract with Sony for advanced admin work on the special Sony-built multimedia clusters. If a school can afford that, then it's great, and that school could probably also afford a similar support contract for a Sugar deployment. No one is advertising such contracts at the moment, but there seem to be several companies keeping an eye on that market. In OLPC-land, there are many such professionals. For example, there is a full-time repair shop in Birmingham, AL devoted to fixing up children's broken XOs. We can try to encourage these sorts of services to spring up around SoaS as well, but it's important to remember that the students for whom we are most concerned do not live in school districts that can afford professional services. I don't think we will ever arrive at a situation where teachers in poor schools can expect any real assistance with Sugar, or any other computer system. Therefore, I think the most important thing we can do, on this front, is to devise deployment mechanisms that will degrade gracefully when operated by inexpert users in challenging environments. SoaS attempts this, with easy re-imaging of nonfunctioning sticks and no reliance on school infrastructure. There is certainly much more left to do. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] SLOBs Position on SoaS
Peter Robinson wrote: 2009/9/16 Philippe Clérié phili...@gcal.net: 1) You need a product to market. The comparison with Gnome does not hold. There have always been distributions that made Gnome their official desktop environment, even very early on. That is not the case for Sugar. Whether in Fedora, Debian or Ubuntu, Sugar will always be a secondary desktop at best. That is in fact completely incorrect. KDE is not the primary desktop in Fedora but there is a team that makes it a first class Desktop in Fedora. OK. We just have a terminology problem on the definition of distribution. Is Fedora 11 KDE Desktop Edition a different distribution from Fedora 11, or is it the same distribution? Is LUbuntu (LXDE Ubuntu) a different distribution from standard Ubuntu? The answer doesn't matter; it's just a definitions problem. Having an official Fedora 12 Sugar Desktop Edition, making Sugar a first-class alternative to KDE and Gnome in Fedora, would be a great thing, and I suspect it would satisfy most of Philippe's concerns. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] directly browsing compressed content in the datastore
S Page wrote: I sent Viewing compressed content using jar: protocol in Browse ! a while back, no one cared :-) To repeat, the XULRunner engine can directly browse files in JAR and ZIP archives using Sun's jar: protocol. Regardless, I've been playing with it some more in 8.2.1. Cool. I think jar: has a lot of potential, and we should definitely be thinking about how to get it working. Lucian experimented with jar: for browsing offline webpages, but ultimately rejected it after determining that webpages using javascript would not function properly. Instead, his modified browse just decompresses the archive and uses file://. This works, but loses the significant efficiency advantages of jar:. Possible avenues to rectify this: 1. Make javascript work from JARs. I don't understand the exact problem, so I cannot say precisely what is needed. 2. Identify bundles that don't require javascript. For example, we could declare that objects with a Mozilla MAFF mimetype (application/x-maff) will be fully decompressed, but all other zipfiles will be processed via jar:. A metadata key could also be used. 3. Implement a runtime heuristic for whether javascript is needed. For examples, zipfiles containing no HTML can safely be loaded via jar:. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Problem rejoining a shared Write
J.M. Maurer wrote: While testing with salut, I now seem to be running into sugar bugs: 1. Start an activity 2. Join the activity 3. Close the activity on the initiator side 4. Click on the activity from the donut on the initiator side to rejoin it Could you clarify step 4? Why didn't you go to the Neighborhood View to rejoin? Did you create a fresh instance or did you resume a saved instance? = This 'creates' a new activity instead of joining it, as self._shared_activity is not set to true. Is it set to False? self._shared_activity can take on many non-False values. It DOES however reconnect to the tube that was still there. This results in my case in having 2 Writes on the same tube who both think they are in control. It seems likely to me that this is a problem with Write being unable to handle an instance that is both resuming from the datastore and joining an existing shared session. I know this is possible to handle, because SharedTextDemo does it. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Remove the naming alert in 0.86
Tomeu Vizoso wrote: I also think that improving the default texts will improve greatly this issue. Anybody wants to tackle it? Maybe for a reduced number of activities at first? Ah, but what should it say? How about Change this title to a description of this Write Document!? signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] query
deepanshu arora wrote: yes Benjamin..u are right. I am trying to make an interface that would allow users to edit programmable tools while inside paint. OK. I think that's a great idea, and it should not be too hard to implement. You will need to provide a GUI for editing, but this is easy with gtksourceview. You also need a way to save and load the user's code. If you are targeting Sugar 0.84+, then the easiest way to do this is to add the programmable tools to the datastore object's metadata as a string. See, for example, http://wiki.laptop.org/go/Sugar.activity.activity#How_do_I_implement_a_write_file_method_for_my_activity_in_order_to_persist_my_activity_in_the_journal.3F This method is very easy to use (probably one or two lines of code) and has the advantages that (1) it only creates a single Journal entry, and (2) the Journal entry it creates is still a standard PNG file, so it retains excellent compatibility. However, this method will only work reliably on Sugar 0.84 and newer. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] query
deepanshu arora wrote: Is their any way that in paint activity only, a tab(button) should be inserted I think this is the right idea. You should be able to click on a tab or button that changes the view from the image to a text editor. This is not hard to do using Activity.set_canvas(), and there are also other ways. which when clicked will take user directly to desenho.py (inside pippy activity)...such that user will simply add his/her tool(code) over their. There is no way to edit the main python code of a running activity. Instead, you should have the user provide some python code in the text editor, which you read in and accept as a string. You can then execute the contents of the string with eval() [1]. [1] http://docs.python.org/library/functions.html#eval signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] query
deepanshu arora wrote: But i need copy_to_journal.py script for the same which m not able to access(and cant find it on internet). Please help me for the same. Also please comment on the approach. This is not a very good approach. I can't offer very good advice, because I don't know exactly what you would like to do. It sounds like you are building support for programmable tools in Paint. Are you trying to: 1. Allow users to edit programmable tools while inside Paint? 2. Allow users to export programmable tools for editing with other activities? 3. Allow users to import programmable tools that have been edited with other activities? I would recommend option 1, both because the user experience is better and because it is easiest to implement. What do you have in mind? signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: [Bug 419240] [NEW] Need instructions on how to set up a cluster of computers so they collaborate.
Mike Lee wrote: I can go buy the 5 and 8 port models tonight to try. If one of these works, then we'll at least have a basis for moving forward in the classroom. So far, I don't think we have any confirmed working devices. As I said in another email, I've tested the Linksys 5-port Workgroup Switch with no luck. It is hard for me to believe that the problem is with the choice of switch. Switches are commodities; they're interchangeable and virtually identical in functionality. Your earlier description suggests that your laptops are not configured for local collaboration at all. In particular, it's possible that Avahi is not running. Whether the Avahi daemon is initiated by default, and how to start it, varies between distributions, so I can't advise you on that without knowing more about your configuration. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: [Bug 419240] [NEW] Need instructions on how to set up a cluster of computers so they collaborate.
Caroline Meeks wrote: The same sticks collaborate locally at the GPA. That's certainly very strange. I still think it's more likely to be a software problem than a hardware problem. The only relevant difference I can think of between GPA and a switch like this is that at GPA, there's a DHCP server handing out addresses. On a simple switch with no internet connection, the computers have to adopt link-local IP addresses (169.*). One possibility is that, in the absence of a DHCP server, the computers are not correctly acquiring link-local addresses. Bill can confirm this on Monday, I guess, by looking at the IP addresses shown in ifconfig in the no-internet configuration. Note that not seeing anyone in the neighborhood, and seeing people but not having all shared activities work all the time are probably two different bugs. We do sometimes have trouble with seeing activities at the GPA, but we always see the other people. Agreed. These are different issues. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: [Bug 419240] [NEW] Need instructions on how to set up a cluster of computers so they collaborate.
Bill Bogstad wrote: On Tue, Sep 1, 2009 at 3:20 PM, Sascha Silbesascha-ml-ui-sugar-de...@silbe.org wrote: On Tue, Sep 01, 2009 at 02:57:57PM -0400, Mike Lee wrote: As I said in another email, I've tested the Linksys 5-port Workgroup Switch with no luck. I don't think it has got anything to do with the switch. Collaboration is known to have some bugs. Is there a (hopefully straightforward) way to determine if a known bug is causing the problem? I am not aware of any bug that would cause the observed symptoms. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: [Bug 419240] [NEW] Need instructions on how to set up a cluster of computers so they collaborate.
Gary C Martin wrote: On 1 Sep 2009, at 20:20, Sascha Silbe wrote: On Tue, Sep 01, 2009 at 02:57:57PM -0400, Mike Lee wrote: As I said in another email, I've tested the Linksys 5-port Workgroup Switch with no luck. I don't think it has got anything to do with the switch. Collaboration is known to have some bugs. FWIW: All my testing has been done over wireless, so no wired results to report. I do have a switch and 2 machines so I might be able to test over ethernet and see if I can reproduce the issue here. That would be good. Even a crossover cable between two machines would be enough to test the system. My current best diagnosis is that the dhcpcd on Strawberry has somehow been configured without zeroconf, so it does not acquire a link-local address and bring up the interface in the absence of a DHCP server. I freely admit, though, that this diagnosis doesn't make a lot of sense, because Fedora has generally embraced zeroconf and Avahi, and there's no reason Strawberry should be different from stock Fedora in this regard. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
Lucian Branescu wrote: This is a bit of a stretch, but would it be possible to distribute GIMPLE or LLVM IR and finish the compilation on installation? Installing would take longer, but it should work on any architecture the code can compile to. Currently, Sugar has a number of blessed interpreters: CPython, Spidermonkey, Squeak, bash, and arguably sed and awk. I think it would be easy to add a C compiler to the list. (I also think skipping the C parser stage by shipping an intermediate representation is a premature optimization.) Providing a C compiler would enable the use of C source code in activity bundles. Activities would be responsible for running a script to initiate compilation, and for caching the binaries in /data to avoid recompiling on every launch. We can provide a standard script for this (like sugar-launch), for the convenience of activity authors. It would be useful. It's more difficult to say that simply adding a compiler solves the problem of dependencies on existing binary packages. For example, many packages require build systems like ant, autotools, CMake, GNU make, imake, or SCons. Unless we also provide all of these build systems, Activities will have to compile the build systems for their dependencies, before they can build their dependencies. It may be acceptable to bless one or more of these build systems, to partially alleviate this problem. Activity bundles can test for the presence of installed applications easily enough, to avoid unnecessary compilation.They may also attempt to download arch-appropriate binary packages over the internet, and compile the included source only if such binaries cannot be found. (I am specifically referring to binary packages constructed to permit unprivileged installation and use, such Gentoo Prefix binpackages or 0install bundles.) We could provide a service to allow Activities to search for binary packages already downloaded, and inform them of preferred package servers. Activities could also pause and ask the user to install certain packages through the system package manager, falling back to compilation only if the user declines (or fails). It may be possible to use PackageKit and PolicyKit to streamline this process, but it does not seem to be strictly necessary. A remaining serious issue is headers. I don't yet totally understand this problem, but many applications can only be compiled in the presence of appropriate library headers, and in many distributions the appropriate headers are not present by default (they are in -devel packages). It may be necessary for Sugar to depend on all these -devel packages so that Activities can compile and link correctly. This is a significant cost in disk space. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
