Re: [Sugar-devel] Current Sugar implementation on Android
On Tue, Apr 16, 2013 at 7:33 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On the negative side, gobject-introspection cross compilation still sounds like a mess https://bugzilla.gnome.org/show_bug.cgi?id=592311 I worked on that code for a while at litl. Probably the best bet is to not try to cross-compile, but instead during the build process run some code via adb shell directly on the android target device. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Current Sugar implementation on Android
At the time, the android NDK was rather eccentric, which made cross-compilation needlessly difficult. And the GTK stack is very deep, there are a lot of dependencies. My understanding is that the NDK has been improved since then, and is a little more compatible. I wouldn't say speed is the main problem, I'd say maintaining the port/fork is, since the changes required to the GTK stack were extensive. It would be worth revisiting this to see if the situation has improved. --scott On Tue, Apr 16, 2013 at 12:03 PM, Chris Ball c...@laptop.org wrote: Hi, On Sat, Apr 13 2013, Daniel Narvaez wrote: I was curious about what it would take to port enough of the GNOME libraries to android to be able to run the current Sugar implementation there. I'm not planning to work on it, but I thought it would be useful to post some notes on what I found. cscott did some work on this a few years ago, and published source code -- see in particular: http://cananian.livejournal.com/62756.html http://cananian.livejournal.com/63595.html It was very slow on the hardware we had available at the time. Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wikibrowse improvements.
Yeah, the get_block_text way is nicer. --scott On Feb 4, 2013 10:39 AM, Gonzalo Odiard godi...@gmail.com wrote: I have read the patches. The only one I don't like too much is the last one. I prefer doing like in dataretriever.py https://github.com/cscott/wikiserver/blob/50446f21436c936f0aea3884401fc6cd1e8ae5d6/dataretriever.py#L179 I know, there are a few places with code duplication, I need improve that. Gonzalo On Sun, Feb 3, 2013 at 11:33 PM, Gonzalo Odiard godi...@gmail.com wrote: Thanks! I don't know if I will have time this week, but will look at this and integrate the changes. Gonzalo On Sun, Feb 3, 2013 at 5:25 PM, C. Scott Ananian csc...@laptop.orgwrote: I did quite a bit of work on the Wikipedia activity this weekend (related to an HTML port I was working on). I've pushed a set of patches to: https://github.com/cscott/wikiserver based on the latest version at ssh://dev.laptop.org/git/projects/wikiserver Full list of patches is at the end of this email. The summary: I updated mwlib (used to generate HTML from mediawiki markup) from 0.6.2 to 0.8.5 to fix issues I had with infinite-loops in template rendering in the full simple English wikipedia. In the process we got the latest full complete list of translations for Image/Media/Template etc so greatly broadened the # of languages the Wikipedia activity will work with. I also fixed a bug with #anchors in article titles which was causing multiple copies of the articles to be added to the database. This should decrease the size of the database for all languages. Another bug squashed involved different articles with the names differing only in case, for example Template:TOCright and Template:tocright. And there were some SQL escaping issues with article titles which contain quotation marks. There were also some fixes to prevent the processing scripts from breaking when their output is redirected to a file (by default console uses utf-8 encoding, file uses ascii encoding, sigh). Review, comment, merge if you can, enjoy! --scott Full list of patches: f35f8b4c10fb6cddfb48af32ef1cc65f4d40fee2 Use smaller bzip2 block size to improve decompression time. efdf324952e30260596a6a2092be5d59559c8e4c Update to mwlib 0.8.5. 2773b52fa988a6c456f879a470e400eb87e060d2 Update mwlib to 0.8.4. 490c092afff6b6c697252f399b3ce3c3ad0b1cc3 Update mwlib to 0.8.3. e0002405fda01b4a29fde0436d058d75ee7ca8db Update mwlib to 0.8.2. 9da2774ebdadd81484e29144856f0798df08b505 Update mwlib to 0.8.1. ceae189e3dc1631d5157c0c9335803521485276b Update list of localized namespaces to that in mediawiki 1.20.2. d4d4c636dcf154a6c05874410d848a353ffd5f7b Update to copy of namespace_langs from mwlib 0.11.2. 3beec2ad23a8a5e3aa48197f968035ce16ec9e6e Update mwlib to 0.8.0. f2bca19b4d27a53ff5fe6e7f4f231f182b64c7eb Update mwlib to 0.7.1. 8bb74a6c4f4f3f919171759d9c9a042d0b96aba0 Update mwlib to 0.7.0. c1d765f8638add17b582b41e1f970945fc86da73 Update mwlib to 0.6.2. 86e5bd672b2a23c2b38321e3ee502b7d1219c1a6 Trim #anchor from links to avoid putting multiple copies of articles in db. 47642fe412d0e687995956f0c33abb1663d3078e Don't break if we redirect the output of make_selection.py. bbb9892d7e77a7568b70edb82e4d06a4b30e2b16 Make expandtemplates.py script work even when processing --all articles. d7ddf77f555d9a67a3b19b7bbafb6700814f9213 Make normalize_title consistent; don't squash case-sensitivity. 48153400296aea2c048a4c23f8fe2ac733a088cd Fix RedirectParser and make it the same in the 3 places it is duplicated. 6ba73792e5560d813075f313f8c1fe3443a5e0af Fix SQL escaping issues. -- ( http://cscott.net ) -- Gonzalo Odiard -- Gonzalo Odiard ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Wikibrowse improvements.
I did quite a bit of work on the Wikipedia activity this weekend (related to an HTML port I was working on). I've pushed a set of patches to: https://github.com/cscott/wikiserver based on the latest version at ssh://dev.laptop.org/git/projects/wikiserver Full list of patches is at the end of this email. The summary: I updated mwlib (used to generate HTML from mediawiki markup) from 0.6.2 to 0.8.5 to fix issues I had with infinite-loops in template rendering in the full simple English wikipedia. In the process we got the latest full complete list of translations for Image/Media/Template etc so greatly broadened the # of languages the Wikipedia activity will work with. I also fixed a bug with #anchors in article titles which was causing multiple copies of the articles to be added to the database. This should decrease the size of the database for all languages. Another bug squashed involved different articles with the names differing only in case, for example Template:TOCright and Template:tocright. And there were some SQL escaping issues with article titles which contain quotation marks. There were also some fixes to prevent the processing scripts from breaking when their output is redirected to a file (by default console uses utf-8 encoding, file uses ascii encoding, sigh). Review, comment, merge if you can, enjoy! --scott Full list of patches: f35f8b4c10fb6cddfb48af32ef1cc65f4d40fee2 Use smaller bzip2 block size to improve decompression time. efdf324952e30260596a6a2092be5d59559c8e4c Update to mwlib 0.8.5. 2773b52fa988a6c456f879a470e400eb87e060d2 Update mwlib to 0.8.4. 490c092afff6b6c697252f399b3ce3c3ad0b1cc3 Update mwlib to 0.8.3. e0002405fda01b4a29fde0436d058d75ee7ca8db Update mwlib to 0.8.2. 9da2774ebdadd81484e29144856f0798df08b505 Update mwlib to 0.8.1. ceae189e3dc1631d5157c0c9335803521485276b Update list of localized namespaces to that in mediawiki 1.20.2. d4d4c636dcf154a6c05874410d848a353ffd5f7b Update to copy of namespace_langs from mwlib 0.11.2. 3beec2ad23a8a5e3aa48197f968035ce16ec9e6e Update mwlib to 0.8.0. f2bca19b4d27a53ff5fe6e7f4f231f182b64c7eb Update mwlib to 0.7.1. 8bb74a6c4f4f3f919171759d9c9a042d0b96aba0 Update mwlib to 0.7.0. c1d765f8638add17b582b41e1f970945fc86da73 Update mwlib to 0.6.2. 86e5bd672b2a23c2b38321e3ee502b7d1219c1a6 Trim #anchor from links to avoid putting multiple copies of articles in db. 47642fe412d0e687995956f0c33abb1663d3078e Don't break if we redirect the output of make_selection.py. bbb9892d7e77a7568b70edb82e4d06a4b30e2b16 Make expandtemplates.py script work even when processing --all articles. d7ddf77f555d9a67a3b19b7bbafb6700814f9213 Make normalize_title consistent; don't squash case-sensitivity. 48153400296aea2c048a4c23f8fe2ac733a088cd Fix RedirectParser and make it the same in the 3 places it is duplicated. 6ba73792e5560d813075f313f8c1fe3443a5e0af Fix SQL escaping issues. -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On Thu, Jan 31, 2013 at 2:00 PM, Daniel Narvaez dwnarv...@gmail.com wrote: * Both firefox and chrome extensions have good messaging mechanisms between content and extension that we could use. We would have the issue to turn a full browser into a chromeless sugar activity though. For what it's worth, I believe the above is the best strategy. You don't really want to maintaining your own fork/embedding of webkit forever. I have packaged full Firefox for Sugar in the past, there were no obvious blockers there (http://wiki.laptop.org/go/Firefox/Obsolete) and this is the path which will be best supported upstream. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On Thu, Jan 31, 2013 at 8:41 PM, Edward Mokurai Cherlin moku...@sugarlabs.org wrote: On Wed, January 30, 2013 4:26 pm, lio...@olpc-france.org wrote: * What we are doing here is still heavily experimental. I don't think we know exactly where we are going yet, just trying to find out. I posted on the list so early because I think it's important to get feedback. Quite right. Let me add a question, then, where I would like to get some feedback. One of the ideas at the foundation of the Sugar Labs program for Replacing Textbooks (with OERs) is to be able to write learning materials using tools such as HTML5 or EPUB3 in a way that would allow us to embed and script Sugar activities. This would make it straightforward to implement a curriculum fully integrated with Sugar. (We could also discuss what other Sugar activities would be needed for the purpose, and whether existing Sugar activities would need to be adapted to make all of this work.) Do we know how to do such a thing in HTML5? What other questions do we need to ask in order to start looking for more answers? Yes, this would be (more) possible in a Sugar-web-app world. Questions to ask: 1) what does the UI of this text book look like? Are the sugar apps running in little windows like illustrations in the text book, or are things integrated like in the Active Essay work by vpri ( http://tinlizzie.org/jstile/#Tutorial). 2) how are examples integrated? One of my old UI designs was that Pippy examples (for instance) would show up in your journal as Pippy things shared by Chris Ball (for instance). Do you want to mush author-generated and user-generated content together, separate them only as having been created by different people, or enforce a more rigid separation between textbook example and student work? 3) how are exercises integrated in the text? Do you want to do an active learning thing where the student has to work an exercise before they can proceed to the next chapter of the book? http://cscott.net/Publications/OLPC/idc2012.pdf describes an alternative where the textbook is a story (or collection of stories) told using sugar activities. My Nell paper contains a pretty complete design for one way to build an active learning system which integrates pedagogy and activities. The Active Essay work done by vpri is another way, more textbook-like. There are undoubtedly other ways as well. But the technology is basically there, once you figure out how you want it all to work. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
At the risk of diverting you guys from your good work, let me add a few related thoughts: 1) I think the core of this new API focus should be on the question: what are the essential parts of the Sugar experience? I would like these roughly as follows (you may have other ideas): a) the journal b) collaboration c) consistent look and feel (visual design language) / toolbar, etc d) view source e) polyglot support First, decide among yourselves what the core sugar experience is. Then I would encourage the creation of separate focused APIs / libraries for these main components, not rolling them all together into a big sugar tarball. That way apps which want (say) just the sugar look and feel can import a package which does just the UI widgets without dragging in other stuff (and even before, say, collaboration is finished). These APIs should be written in a language-independent manner (think about gobject) so that the same basic APIs can be used on multiple platforms. This will make it easier to write a sugar activity (meaning support for a-e) which is Android-native, or (my preference) a web activity which supports a-e on a desktop web browser, an xo running sugar, and an android device. 2) Ideally these libraries would all be optional; that is, there is a pure web implementation/fallback available, which is overridden when there is platform-specific support. I should be able to run a sugar activity on a desktop web browser, but I might not get (for example) journal support -- or the journal support will be via a journal.sugarlabs.org server somewhere. If I run the same web activity on an XO, there are local hooks (think a plugin) that allows me to use the real journal. If I run the same activity on an Android phone, the plugin might use a special Android implementation of the journal. Write good APIs, and allow multiple implementations. 3) I think embedding a web server is probably the wrong way to go. HTML5 has robust offline application support. If you write an offline web app, it runs the same on an XO, a desktop browser, and an android phone. I recommend Firefox/Android for running webapps on Android. The Nell's Balloons and Nell's Colors activities I've written are good examples of offline web apps; there's also an offline Wikipedia reader. The interesting technical challenge is to prepopulate the offline web cache with the appropriate files when the activity is installed, but this is pretty straightforward profile hacking; I can tell you how I do it for Firefox/Android if there is interest. 4) I recommend adoption of a component strategy. Something like https://github.com/component/component/wiki/Components although jamjs.organd volojs.org also look very reasonable. But try to keep dependencies lightweight. You want just enough to provide for good namespacing. 5) I have written a plugin for Firefox/Android which allows access to Android' native Java APIs from web app code. This is a good way to implement (for example) a collaboration API on top of Android's native peer-to-peer wifi APIs. I'm interested in working on this. 6) The webkit web inspector is the best implementation of view source that I have yet seen. Try to find ways to leverage that --- ie, avoid packaging strategies that bundle or obfuscate the code. I believe this is also the strongest argument against the use of CoffeeScript for Sugar, at least at the library level. (The source map feature of webkit helps to some degree, but it's still not as clear as viewing straight java script.) 7) Writing fluent javascript isn't about syntax, believe it or not. You can get most of the good stuff via good use of the native methods. For example, Array.forEach is an excellent substitute for for each syntax. In fact, I've done quite well writing in a deliberate *subset* of Javascript (see http://cscott.net/Projects/TurtleScript/) in an effort to make my code easier to understand and visualize using block-based editors. That said, I expect 90% of your work will be writing good interfaces and APIs. If this is done, it will be easy to write clean readable activities on top of the APIs, even if the actual implementation of some of the APIs gets messy. Hope this is helpful. I think it would actually be useful to have a summit of some sorts around these issues. As you can tell from the above, I believe that a good implementation of web activities for Sugar is also important for the continuation of the Sugar ideas on other platforms, like desktop and android. So this is good fundamental work. It's good to see how much progress you guys have already made. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On Wed, Jan 30, 2013 at 12:19 PM, Gonzalo Odiard gonz...@laptop.org wrote: Any reason to prefer Firefox over Webkit? Firefox/Android has made great strides recently, and is a much more friendly environment for building add-ons. Chrome Web Apps are rather limited in comparison (no full screen mode on Android), and AFAIK the mobile version of chrome doesn't support extensions. Firefox/Android also has much better WebGL and video support at the current time. Getting HTML5 video to play on Webkit/Android is a nightmare. The Chrome team doesn't really want to compete with native apps, where the Firefox team is making web apps (and boot2gecko) a priority. But really, good modern web code should be browser-agnostic. It shouldn't be hard to make a framework that runs under Firefox/Android on Android and Webkit/Sugar when running on Sugar. From activity code, the Sugar API ought to be made using the postMessage API, which is cross-browser. How those messages are processed under the hood is much less important; you can use different implementations for different platforms. After playing around with canvas a lot, I'm not a huge fan of using it to implement UIs. You give up much of the i18n, accessibility, and introspection support one you start playing with canvases. It's fine to use under-the-covers to draw backgrounds, etc, but it's better to use real HTML/CSS widgets whenever possible. There's also a big API change coming up with respect to retina-displays and canvases. (It's also suprisingly difficult to get animations on canvases to display smoothly across browsers; you end up depending on a lot of details in your browser's graphic acceleration and context invalidation stack. http://cscott.net/Projects/TurtleScript/canvastest.html has a simple test case which I had a lot of difficultly getting to perform well on the XO and Android. Generally speaking, animating widgets and using CSS animations are much easier to get to work with good performance.) That said, canvas is fine it you want to implement a paint program or logo or a pippy environment that lets you draw pictures. paper.js is one library which people seem to like for that purpose. processing is another. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Want to play with html activities?
On Tue, Jan 29, 2013 at 2:18 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Hi, we are still at the very beginning but development is going fast. It would be awesome to have activity authors step in as soon as possible, so that we can add stuff as needed and get early feedback. If you want to write an activity it's pretty easy to get started: git clone git://git.sugarlabs.org/sugar-build/sugar-build.git cd sugar-build git checkout html make Take a look to source/htmldemo for an activity template, we will add more features there as they become available. Let us know about your work. Send bug reports, feature requests, ask for help on the mailing list or on irc. Coming up, roughly in that order: * Ability to close the activity window from js. * Buildbot instance for the html branch * Documentation on how to write an activity. * Initial implementation of a toolbar widget. * Support to run the activity in a web browser. * Support to run the activity as an android application. I'd be interested to see http://nell-balloons.github.cscott.net (ie http://github.com/cscott/nell-balloons ) and http://nell-colors.github.cscott.net (ie http://github.com/cscott/nell-colors ) running on the XO. They are both offline web apps. They also run fine as android applications (open web apps), using Firefox/Android. Also interesting would be: http://offline-wiki.googlecode.com/git/app.html --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engadget post on XO Touch
Presumably with the standard multi-touch X support, which is landing in Linux all over. That's how the XO-3 worked, at least, although that was traditional capacitive touch; I don't think there's an actual Neonode driver in existence anywhere yet. --scott On Tue, Jul 31, 2012 at 8:54 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 26.07.2012, at 20:21, Mike Lee wrote: Here's a cool demo of the Neonode multitouch frame: http://www.slashgear.com/neonode-3d-touch-headed-to-tablets-and-phones-hands-on-28215933/ Not only multi-touch, but also entry direction and tilt. For a dollar! Well, for tilt you would need to stack multiple frames on top of each other as they did in that prototype. For a touch-screen you would want it to be as thin as possible, that would mean single-layer. The Kindle Touch and Nook use Neonode zForce touch sensors, too. Here's a nice animation showing the principle: http://www.neonode.com/solutions/zforce Does anyone know how the multi-touch stuff is going to be exposed in Linux? - Bert - Seems like this would be great as a retrofit kit. Mike On Thu, Jul 26, 2012 at 11:09 PM, Sameer Verma sve...@sfsu.edu wrote: www.engadget.com/2012/07/26/olpc-xo-touch-1-75-to-use-neonode-tech/ The post says as yet unreleased XO 1.75. What's the official status on the 1.75? Still as yet unreleased? cheers, Sameer ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Just learned about Mistery Meat Navigation
On Tue, Mar 20, 2012 at 4:47 PM, Gonzalo Odiard gonz...@laptop.org wrote: If you find non obvious icons, can report to try to improve. May be adults have problems with icons, but kids don't, just see a kid playing in any internet site. These icons become much more problematic on a touch screen, where there's no obvious way to get the text descriptions to pop up. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] badges for collaborative activities
On Wed, Dec 14, 2011 at 11:19 AM, Michael Stone michael.r.st...@gmail.com wrote: On 12/13/11, C. Scott Ananian csc...@cscott.net wrote: I was playing with Sugar collaboration between my XO-1.75 and my crazy-nephew's XO-1.5 over the weekend. We wanted to play together, but it was hard to find which activities would let us do so. What if we added a small badge (perhaps the ring of dots used to switch an activity from 'private' to 'shared') to activities on the home screen to indicate that they support collaboration? That would make it easy to tell which activities allow us to play together. It's not worth much, but: good suggestion; makes sense to me. :) I've added my suggestion to the discussion page for Simon's http://wiki.sugarlabs.org/go/Features/Can_share which also sounds like good (implementation) suggestion, makes sense to me. Once Simon's infrastructure is in place, then things like the launch as Shared idea Walter wants should be straightforward as well. (Although I will note that my 5-yr-old test subject is completely baffled by the many different ways of launching/resuming activities already. He did understand how to share his activity w/ me, once I showed it to him, and seemed quite pleased that he was able to play by himself when he wanted to.) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] badges for collaborative activities
I was playing with Sugar collaboration between my XO-1.75 and my crazy-nephew's XO-1.5 over the weekend. We wanted to play together, but it was hard to find which activities would let us do so. What if we added a small badge (perhaps the ring of dots used to switch an activity from 'private' to 'shared') to activities on the home screen to indicate that they support collaboration? That would make it easy to tell which activities allow us to play together. --scott ps. Typing Turtle is a great new activity which I hadn't seen before -- but it doesn't support collaboration. What if we could play the balloon-popping game together, with the first person to type the word getting points for popping the balloon? -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] badges for collaborative activities
I'm trying not to open the can of worms which is how should we best implement collaboration. In this thread, let's just concentrate on how do we discover collaborative activities when we're playing with our friends? --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] public collaboration servers
Are any of the public collaboration servers still up? I worked my way pretty far down http://wiki.sugarlabs.org/go/Community_Jabber_servers without finding a server that would let me register. I am using an XO-1.75 build, so perhaps collaboration is just busted in this build? If someone could point me to a known-good collaboration server, that would help with my debugging. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Global text to speech
Click-to-translate would be very attractive as well. --scott On Wed, Nov 23, 2011 at 5:09 PM, Tony Anderson tony_ander...@usa.net wrote: Hi, The OLE Nepal library on the school server includes wiktionary. However, I think the dictionary would have to be small enough to keep on the internal store of the XO. I am thinking of a scenario where a student is reading a text in a language other than the native language with a controlled vocabulary (e.g. 3500 words) and could click on a word to get the definition in the native language. In such cases a small dictionary could be developed fairly easily. The trick is to select the word being clicked on. I suspect selecting and then clicking would be fairly easy to implement. Tony On 11/23/2011 11:29 PM, Gonzalo Odiard wrote: Do you know any free dictionary we can use? The activity Words use The Internet Dictionary Project [1] but is not very good. GtkSpell provides word-processor-style highlighting and replacement of misspelled words in a GtkTextView widget. Right-clicking a misspelled word pops up a menu of suggested replacements [2], but the last version is from 2009. Gonzalo [1] http://www.june29.com/IDP/ [2] http://gtkspell.sourceforge.net/ On Wed, Nov 23, 2011 at 6:18 PM, Tony Anderson tony_ander...@usa.net mailto:tony_ander...@usa.net wrote: Would the mechanism used to implement this be exposed in a way that it could also be used for a global dictionary (i.e. the user could click on a word or phrase and get a definition (in the same or a different language)? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
Just to reinforce a few points which maybe might not be clear to people who haven't played with the new hardware: 1) the switch point is set that *you cannot tell when we turn the backlight off*. Ie, the threshold is so high that by the time we turn it off, you couldn't never have told whether the backlight was on or not. This is very different from the auto dim feature in Macs, for example. (And it's the primary reason why the switch to monochrome was so visible -- you couldn't tell that we were turning the backlight on and off, you could only tell that the images on the display were shifting greyscale values intermittently for no obvious reason.) 2) this is a very important power-saving feature for young kids, who generally aren't savvy enough to manually do all these measures which prolong battery life. So, even if power tweakers might want a little more control, it's important to make the default behavior as power-friendly as possible (especially as we move further into deployments where access to power is a big big deal). We should keep in mind the trade-offs here. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TA cairo conversion
On Fri, Nov 11, 2011 at 10:10 AM, Walter Bender walter.ben...@gmail.com wrote: On Thu, Nov 10, 2011 at 7:16 PM, C. Scott Ananian csc...@laptop.org wrote: Current version on the cscott-gtk3 branch works on GTK3. Some functionality might be missing: I've just discovered a bug in the gir bindings for gtk_pixmap_get_pixels() which makes 'read pixel' break in gtk3, for instance. GTK2 operation should have no regressions. (Testing welcome!) I finally got my head wrapped around the surface caching issue in the sprite library. Not sure it will make too much of a difference, but it is working. I have one more optimization in terms of memory footprint I'll play with and then I plan to merge your branch into my mainline... Stay tuned. I fixed 'read pixel' on my branch. I was noticing that tiles sometimes 'stay pressed' after I click on them; that's in both GTK2 and GTK3 but I *think* is a cairo-branch thing, independent of my changes. There seems to be a kludged call to _expose_cb() in the button-press handler, maybe to work around this? Anyway, let me know when you're stable again and I'll do another rebase. Today I expect to get turtleart running in the browser, using the GTK3 Broadway stuff. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TA cairo conversion
On Fri, Nov 11, 2011 at 11:17 AM, Walter Bender walter.ben...@gmail.com wrote: (1) Maybe release this version (cairo) and make 124 the gtk-3 rebased on your patches. This is probably worth doing. At the very least it will make it easier for testers to separate your bugs from mine. ;-) --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TA cairo conversion
I'm rebased on top of mainline now, staged at the usual place. I'll continue working on getting the GTK3 functional while leaving GTK2 operation unchanged. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TA cairo conversion
On Thu, Nov 10, 2011 at 3:21 PM, Walter Bender walter.ben...@gmail.com wrote: +1 I'll do some testing; I plan to make the next release based on this work. May as well get these bits into the field. I'm mostly just concerned that future patches base off the converted source and use the new class capitalization style so we won't continue to have patch conflicts. That said, I should mention that my testing has been entirely on desktop GTK2 and GTK3. I'm not the expert on sugar's transition to GTK3, so there's probably work to do on the sugar integration code. Hopefully the same dual GTK2/GTK3 compatibility mechanism can be used (I view my main contribution as util/gtkcompat.py, which I hope can be extended). --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TA cairo conversion
Current version on the cscott-gtk3 branch works on GTK3. Some functionality might be missing: I've just discovered a bug in the gir bindings for gtk_pixmap_get_pixels() which makes 'read pixel' break in gtk3, for instance. GTK2 operation should have no regressions. (Testing welcome!) --scott On Thursday, November 10, 2011, C. Scott Ananian csc...@laptop.org wrote: On Thu, Nov 10, 2011 at 3:21 PM, Walter Bender walter.ben...@gmail.com wrote: +1 I'll do some testing; I plan to make the next release based on this work. May as well get these bits into the field. I'm mostly just concerned that future patches base off the converted source and use the new class capitalization style so we won't continue to have patch conflicts. That said, I should mention that my testing has been entirely on desktop GTK2 and GTK3. I'm not the expert on sugar's transition to GTK3, so there's probably work to do on the sugar integration code. Hopefully the same dual GTK2/GTK3 compatibility mechanism can be used (I view my main contribution as util/gtkcompat.py, which I hope can be extended). --scott -- ( http://cscott.net ) -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TA cairo conversion
On Tue, Nov 8, 2011 at 7:36 PM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Nov 8, 2011 at 7:27 PM, C. Scott Ananian csc...@laptop.org wrote: I keep rebasing based on your HEAD, we just need to choose one of those rebases and then continue development from that point. I'll try to do another rebase tonight. My latest is on mainline now. OK, my latest is on ~walter/turtleart/walters-gtk3:cscotts-gtk3, rebased on your latest on walters-cairo:master -- but it looks like I should be rebasing on http://git.sugarlabs.org/turtleart/mainline ? --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TA cairo conversion
I keep rebasing based on your HEAD, we just need to choose one of those rebases and then continue development from that point. I'll try to do another rebase tonight. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TA cairo conversion
I've been pushing my work to http://git.sugarlabs.org/~walter/turtleart/walters-gtk3/commits/cscotts-gtk3 I'll rebase to the latest cairo bits. (It might be best to continue working with HEAD of my branch, since it runs fine on gtk2 and will minimize unnecessary patch conflicts.) It's also a little confusing to have so many clones: walters-cairo, walters-gtk3, cscott-gtk3, etc. Can we pick one clone and stick with it, even if we're going to work on separate branches? Gtk2 operation on my branch is unmodified, although the code uses Gtk3 style throughout, for future-proofing. The GTK3 version just needs some more incremental fixes; at the moment it's failing trying to create a CairoContext from a canvas---which I think should just be a no-op, more or less. Just a matter of getting enough time to work through the fixes, help welcome. --scott On Sat, Nov 5, 2011 at 9:15 AM, Benjamin Berg ben...@sugarlabs.org wrote: Hello, On Sat, 2011-11-05 at 08:56 -0400, Walter Bender wrote: I pushed a few more patches last night [1]. I have just two blockers right now to releasing the Cairo version: (1) I cannot seem to figure out how to convert my surface to a pixbuf or png for saving to a file; surface = canvas.canvas.get_target() # get the surface used by the canvas surface.cairo_surface_write_to_png(file_name) --- fails because XlibSurface doesn't have a cairo_surface_write_to_png attribute What you can do is the following: 1. x_surface = canvas.canvas.get_target() 2. Create an image surface: img_surface = cairo.ImageSurface(...) 3. Create a context: cr = cairo.Context(img_surface) 4. cr.set_source_surface(x_surface) 5. cr.paint() 6. img_surface.write_to_png(file_name) This way you can download the image data from the X server, and store it inside the applications memory. After this it can be written out to a file. (2) I cannot seem to create the proper surface from a Pixbuf to use in non-interactive mode in replacement of the canvas surface. I have unsuccessfully tried to create a pixbuf and use it to source a cairo context. The pixel format that cairo uses, and the one that Gdk.Pixbuf uses is differs. If I understand correctly, what you want to do is to create an cairo.ImageSurface instead of the create_similar call. The only non-blockers are: (1) I am struggling with the erratic behavior of rotate on bitmaps. It is disabled at the moment. (2) There must be some way to cache the surfaces used by the sprites instead of re-rendering them from pixbufs each time, but using get_target() gives X errors. Hm, I can't say anything about these of the top of my head. Benjamin -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] how to force Sugar Activities to start fresh? (eg. XO OS 11.2.0 = Build 874)
Is there any way to start a new document once you're in the activity? --Scott On Saturday, November 5, 2011, Walter Bender walter.ben...@gmail.com wrote: On Thu, Nov 3, 2011 at 8:23 PM, James Cameron qu...@laptop.org wrote: G'day Adam, The holding down of the alt key in the activity view was introduced in Sugar 0.86 [1], and 11.2.0 is based on Sugar 0.94, and I've tested it just now and the feature works fine for me. Sometimes the left-alt key fails on membrane keyboards. Please test that the alt key works. You can do this easily by opening two activities and using alt-tab to switch between them. If this doesn't work, then there's more investigation to do. Otherwise, you can use the ok prompt to test /keyboard. 1. http://wiki.sugarlabs.org/go/0.86/Notes#Home_Favourites_View_Improvements -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel The graying out is Sugar's way of telling you that you'll get a fresh instance instead of reopening the most recent. If you are seeing gray, then it should work. Perhaps the children are releasing the Alt key before clicking? Alternatively, right click brings up the hover menu immediately. At the bottom of the hover menu for activities on the Home View is the option to open a new instance. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Read port to Gtk 3 status
On Sat, Nov 5, 2011 at 7:49 AM, Walter Bender walter.ben...@gmail.com wrote: - self._view.set_flags(gtk.CAN_DEFAULT | gtk.CAN_FOCUS) + # TODO + #self._view.set_flags(Gtk.CAN_DEFAULT | Gtk.CAN_FOCUS) This one I think I can help with. Try: self._view.set_can_focus(True) -walter The set_flags method has been deprecated since GTK 2.22. You should use the set_can_default(), set_can_focus(), etc methods (in both GTK2 and GTK3). --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Turtle Art cairo branch
On Wed, Nov 2, 2011 at 9:54 AM, Walter Bender walter.ben...@gmail.com wrote: While there is still a bit of fine-tuning/optimizing to do, I think the basics are in place. We should coordinate our efforts in the gtk-2 - gtk-3 efforts. I'll start by rebasing my GTK3 changes on top of your walter-cairo/walter-gtk3 branch. TurtleArt is a bit of a special case in that (a) it doesn't require an updated GTK3 sugar shell in order to run under GTK3/gnome, and (b) we probably want to spend the effort to keep turtle art running w/ the same source code on GTK2 platforms (effort which may not be worthwhile to expend for every activity). My GTK3 patches pursue these goals; they were just missing some cairo-ization, which it appears that Walter has been doing independently. Win! --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Cairo-ized activity performance
Walter -- is the source code for the cairo-ized version available? I made a decent start at GTK3-izing TurtleArt (http://git.sugarlabs.org/~cscott/turtleart/cscott-gtk3/commits/gtk3) and the missing piece is to replace a lot of GdkPixmap stuff with cairo calls. If that code is already written, finishing the GTK3 port should be a snap! (If you look at the code, note that I've taken great care to end up with a version which runs in *either* GTK2 or GTK3, so TurtleArt is still run anywhere.) --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
The big change moving to GTK3 is gobject-introspection. I'm not aware of any plans to change how scripting language bindings are done in the future, so that part of the sugar port should be future-proof. Other things like removing hippo-canvas are also future-proof -- there's no chance that any of that cruft is going to reappear in future versions of GTK. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
Sorry, I haven't read *all* of the linked documents, but... Congrats on getting a minimal GTK3 port running so quickly! That's very impressive. I'd originally thought that refactoring the Sugar API into more independent modules would be a necessary part of the effort, just to be able to do a more incremental port. I'd like to see that refactoring happen, but I guess it's good that it's not on the critical path? It seems like you ought to be able to port sugar-the-window-manager and sugar-the-library-used-by-activities separately, and run gtk2 activities under gtk3 window manager and vice-versa. But maybe maintaining that compatibility is just more trouble than it's worth. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Tue, Aug 9, 2011 at 5:18 AM, Daniel Drake d...@laptop.org wrote: On Tue, Aug 9, 2011 at 8:11 AM, C. Scott Ananian csc...@laptop.org wrote: I'd originally thought that refactoring the Sugar API into more independent modules would be a necessary part of the effort, just to be able to do a more incremental port. I'd like to see that refactoring happen, but I guess it's good that it's not on the critical path? As mixing pygtk/gtk2 and pygi/gtk3 is not possible, splitting into more modules would be unlikely to help much. For example, if an activity pulled one one GTK2-ported module and one GTK3-ported module, it would have to stick with GTK2. By independent modules I meant modules communicating via DBus or g-o-i (C interface), not python all-in-one-interpreter modules. I should probably have said independent libraries; maybe that would have been clearer. (Memory management has to be thought through, but you could embed a python interpreter and a pile of python code into a library which exports a C API. Such a library can be running any version of python you like; it doesn't leak out and infect other libraries/modules.) --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On Tue, Jun 14, 2011 at 4:42 PM, Daniel Drake d...@laptop.org wrote: On 14 June 2011 21:35, Peter Robinson pbrobin...@gmail.com wrote: Would a skinned version of Firefox Mobile work for what is needed? No, as we need collaboration, journal access, etc. But (I didn't include this argument as I lost the link) this response matches what I read from mozilla developers: if you want to build a mozilla-based product, fork the mozilla codebase and write your application inside there. I did work on that; you can certainly make a firefox extension that supports collaboration, journal access, etc. My firefox activity did some of what's necessary. Firefox can speak dbus, etc. That said, I had first-hand experience w/ a project which switched from embedded mozilla to webkit, and I can testify that the performance improvement was indeed significant. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] cookie licker
There's both a pattern and an anti-pattern here, and I saw both during my OLPC v1 days, circa 2008. There were certain features that we were assured had a brilliant and complicated design that was just waiting to be implemented and the implementer never got around to either documenting the design or implementing it. There were other features that got reimplemented several different times in equally-bad ways because no one involved would take the time to get all the stakeholders together and have a good discussion before charging off to do something. The results were short-sighted solutions to one person's view which ignored broader context. Debian has it right here -- everyone is encouraged to adopt unmaintained projects, no stigma attached -- but there's *also* a definite communication process beforehand which attempts to survey the stakeholders and ensure that people don't go charging off blindly. I don't know to what degree these two sides of the pendulum exist in our present community. At EduJam I saw a lot of communication-before-implementation, which is good, and I didn't see any territoriality about projects. For my part I was attempting to participate in the Journal discussions with a big but I don't have time to implement this! disclaimer to avoid any appearance that I was licking the cookie. So things seem good (in my limited view). But it's certainly worth keeping both sides of the danger in mind. And now we have a clever name for half of it. (I have a name I use for the other half, too, but I shouldn't post it on a public list. ;-) --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Exploring Sugar-on-Tablets
On Tue, Apr 12, 2011 at 1:57 PM, C. Scott Ananian csc...@laptop.org wrote: On Mon, Apr 4, 2011 at 6:15 PM, C. Scott Ananian csc...@laptop.org wrote: I've posted a four week plan for XO-3 software exploration at http://cananian.livejournal.com/62667.html Briefly: April 4-8: Android April 11-15: Chrome/ChromeOS/NativeClient Report on first week's work now at: http://cananian.livejournal.com/62756.html The (belated) report on week 2 is now up, in three parts: * Sugar on Native Client (general observations): http://cananian.livejournal.com/63325.html * Comparing NaCl and Android: http://cananian.livejournal.com/63595.html * Next steps for the next month: http://cananian.livejournal.com/63783.html --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Sat, Apr 23, 2011 at 7:39 AM, Sean DALY sdaly...@gmail.com wrote: http://fsfe.org/projects/gplv3/europe-gplv3-conference.en.html http://fsfe.org/projects/gplv3/barcelona-rms-transcript.en.html see question 6b from this QA from the 3rd International GPLv3 Conference (Barcelona, June 22-23, 2006): ** Q6b: Second question, when people start to update their licences to the new versions, how will that happen in practice? RMS: In practice, any program that says it can be distributed under GPL version two or later will automatically be available under GPL version 3, but, when people make subsequent releases, they can change that to say GPL version 3 or later, that's what we will do in subsequent releases of GNU software. The FSF can do this because they own the copyright on all their code (via mandatory copyright assignment). In fact, they've done this on my code, too -- I've assigned copyright on patches to the FSF. I'm not objecting to the FSF doing this, or to the GPLv3 in general -- I'm objecting to dragging *Sugar* through a debate it has no part in, for no compelling reason. Since the FSF has maintained explicit copyright over its code for the explicit stated reason to allow it to move aggressively to hold the left of the copyright wars, I have no objection to the FSF using my code for this purpose. That's why I support the FSF, and why I contribute code to them. That's *not* part of SugarLab's core goals (unless you somehow think that the GPLv2 is no longer a free software license). I object to the Sugar code being manipulated as a pawn in this fight. It has enough battles of its own to fight without being dragged into more. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Mon, Apr 25, 2011 at 12:17 AM, Bernie Innocenti ber...@sugarlabs.org wrote: By updating to the GPLv3, we make a clear political statement that commercial usage is ok, but our software must always remain free for users to use, study, share *and* modify. 1) I'm not interested in using Sugar code to make political statements for their own sake. 2) I thought this was what our use of the GPLv2 accomplished. How is the GPLv2 no longer free? --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Fri, Apr 22, 2011 at 10:50 AM, Martin Langhoff martin.langh...@gmail.com wrote: - What's the upside? - At what point do we say hey, this has scant upside, and negative controversy around it, let's spend our time in productive things instead? This is the crux of my objection as well. I see Sugar being used as a pawn in some larger argument (about I know not what) and want no part of it. No compelling reason to change license; let's stay as far away from that rathole as possible. People are already free to make a gnewsense of themselves and distribute combined works under GPLv3 terms. Fedora-based distros are arguably doing just that. But going through and changing license information in everyone's source files without their explicit consent (and denying the right to do future distribution under the terms of the GPLv2 *is* a change: GPLv2 or later != GPLv3 or later) -- that's just causing a ruckus for no reason. Please don't start that fight. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Fri, Apr 22, 2011 at 12:33 PM, Bernie Innocenti ber...@sugarlabs.org wrote: On Fri, 2011-04-22 at 16:45 +0100, Peter Robinson wrote: We're not retroactively re-licensing existing code. Really? By moving to GPLv3 your removing the ability to use GPLv2 which is by definition a re-license of the code. Not really, this is a common misconception: redistributing code under later versions of the GPL is explicitly allowed by the current licensing terms (GPLv2 or later). If it weren't the case, then we'd have to ask for permissions to all copyright holders, which includes present and past contributors of legally relevant portions of the code. What constitutes a legally relevant portion is a matter of infinite arguments between copyright lawyers. Yes, you seem to be confused Bernie. You can redistribute under a license however you like, usually without explicitly stating it. But if you alter the source files or replace COPYING, you are *changing the license*. That is a different act. A more passive-aggressive means to your end might be to announce that SugarLabs will only accept new contributions which are licensed GPLv3+. That will effect the redistribution change you want, while still (a) pissing off parts of the community, and (b) not illegally altering the license on code you do not own. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Thu, Apr 21, 2011 at 6:18 PM, Bernie Innocenti ber...@sugarlabs.org wrote: Q: Do we need to ask the permission of all copyright holders? A: No, we'll take advantage of the or any later version clause in the current license. We're not retroactively re-licensing existing code. This isn't actually true. You can't change the license on my code -- it's still GPLv2 or later. You can make a combined work where the new parts are GPLv3, and you can redistribute it under the terms of the GPLv3 (because of the or later), but you cannot change the license on the existing code unless you are the sole owner. That is why the FSF does copyright assignment. (See discussions on the net, for example: http://lwn.net/Articles/228354/ ) I'm also opposed to this change, for three reasons: a) code of the affected code is mine, and i don't want to do it. b) it seems to have no point, other than a philosophic one. I'm opposed to change-for-change sake in this matter; it can only make things worse, and I see nothing which is being made *better*. (Ironically, moving to GPLv3 is taking freedoms *away* from users of Sugar). --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Thu, Apr 21, 2011 at 8:00 PM, Bernie Innocenti ber...@sugarlabs.org wrote: Isn't this exactly what I wrote? No, you wrote: Q: How is the actual license change done? A: We need to replace the COPYING file in the source code and update the headers of all source files. This operation can easily be automated. which I don't think is allowed. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Thu, Apr 21, 2011 at 8:00 PM, Bernie Innocenti ber...@sugarlabs.org wrote: (Ironically, moving to GPLv3 is taking freedoms *away* from users of Sugar). Which freedoms are being taken away from the users of Sugar? You are taking away the right to distribute Sugar under the GPLv2. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Exploring Sugar-on-Tablets
On Mon, Apr 4, 2011 at 6:15 PM, C. Scott Ananian csc...@laptop.org wrote: I've posted a four week plan for XO-3 software exploration at http://cananian.livejournal.com/62667.html Briefly: April 4-8: Android Report on first week's work now at: http://cananian.livejournal.com/62756.html --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Exploring Sugar-on-Tablets
On Tue, Apr 12, 2011 at 5:01 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Apr 12, 2011 at 4:43 PM, Caryl Bigenho cbige...@hotmail.com wrote: PCs and Linux machines yes. But... there still lots of issues with Macs and so far it does not work with the older G4 Power PC Macs (EToys to go does!). Does Android run on your G4 PPC Mac?? Or is this all random talk? This week's work (Sugar-on-Chrome) provides a much better story for desktop compatibility. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Exploring Sugar-on-Tablets
I've posted a four week plan for XO-3 software exploration at http://cananian.livejournal.com/62667.html Briefly: April 4-8: Android April 11-15: Chrome/ChromeOS/NativeClient April 18-22: Get down dirty with mesh April 25-29: Pulling legacy Sugar codebase into the GTK3/g-o-i/touch-interface future May 2-6: in Uruguay to present results and discuss all this w/ Sugar folks in person I'll be posting more about each project as I dig into them; there are also threads on IAEP where I've discussed all these topics before, so they shouldn't come as too much of a surprise. There are other ideas out there, and I'm not going to *finish* any of these investigations in a single week. Feel free to ask questions and suggest other projects -- although please read the existing discussions first if you can. In order to actually get work done w/o endless distraction, I'll probably try to avoid getting into lots of details for projects other than the one I'm currently focusing on. And rest assured that I do deeply care about (a) focusing on kids' needs first, (b) preserving as much of the legacy codebase as possible (I am lazy, like all good programmers), and (c) working closely with SugarLabs, Activity Central, and all you other folks! --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Exploring Sugar-on-Tablets
On Mon, Apr 4, 2011 at 11:59 PM, Edward Cherlin echer...@gmail.com wrote: When can we look forward to a similar exploration of hardware topics? Hardware stuff is being discussed actively internally for XO-3. Unfortunately, I can't say anything specific about it yet. But I am pretty excited. As always, OLPC hopes to push the market, rather than necessarily be the single source of low cost and robust computers for education. So we welcome other hardware efforts and discussion as well. Part of what makes me excited about the ChromeOS/Chrome exploration track (next week's work) is that it gives a mechanism for deploying Sugar on everything from desktops (inside the browser of your choice---the NativeClient client is currently Chrome-specific, but will eventually become browser-independent), to netbooks, to tablets -- to whatever comes next! --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins abhun...@uncg.edu wrote: Please ensure that, in *audio* recording mode, any video display (including an oscilloscope-style display) does not cause glitches in the audio. (This was an apparent problem in earlier versions.) Of course, the surest guarantee of this is no simultaneous (changing) video display. I think video feedback is vital. How do you know it's actually doing something if nothing seems to happen when you start recording audio? It doesn't necessarily have to be a waveform display, but *something* needs to be changing. A waveform display has pedagogical value. It's worth making that work right. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Limit the nick name to be only 8 characters maximum #10737
On Thu, Mar 17, 2011 at 2:40 AM, Simon Schampijer si...@schampijer.de wrote: Just in case people are wondering: this patch does only affect internal handling. The nick name that is visible in the UI (neighborhood view) is not affected by the limiting. It will be displayed in full length. And what are the adverse consequences if there is a conflict between JoseMariaSuarez and JoseMariaRamirez ? I think you'd want to show that the potential bugginess is not so bad, or else hash the names rather than truncate them. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FR: visual notification when too many activities are open
What about just closing the excess activities? Why make the kids do more work? --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FR: visual notification when too many activities are open
2011/3/8 Bastien b...@altern.org C. Scott Ananian csc...@laptop.org writes: What about just closing the excess activities? Why make the kids do more work? Maybe with a warning first? Maybe for backwards-compatibility, but child-friendly activities should be able to save and close without losing anything. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundle format
On Mon, Nov 22, 2010 at 11:07 PM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-11-22 at 10:53 -0500, C. Scott Ananian wrote: (oh, and the .zip file already has a checksum, it's not clear why you'd need another one.) Ah, cool... but I guess it's not a cryptographically secure one, right? Cryptographic security can be added to a manifest in the same way it is done for jar files, for android zip files, and for any number of other zip-based archives. In fact, it should be done *exactly* as in one of those other formats. I believe I suggested 'jar'. Use the existing tools, Luke. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Wed, Nov 24, 2010 at 10:43 AM, C. Scott Ananian csc...@laptop.org wrote: I'm suggesting that you work on reducing the time commitment, rather than dilute the responsibility. (Christoph's suggestion seems a useful step in that direction.) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Wed, Nov 24, 2010 at 1:37 AM, Michael Stone mich...@laptop.org wrote: A committee-of-three with people like Gary, Martin, and Walter on it [...] [Another orthogonal issue:] I like and respect Gary, Martin, and Walter, and I think I'd have no trouble convincing them of any UI change I'd wish to make. AFAICT that's part of the *problem*, not the solution. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
[more thoughts, again apologies for not making these shorter] Failing a good candidate, I think do no harm should be the motto -- concentrate on the (many!) design-related tasks which *don't* involve making design decisions. Briefly: organizing/maintaining the specs, collecting/collating issues that need design review or redesign, and facilitating outside review for these. (For example, if a design class at a university were to make Sugar their term project, what documents would you give them, what opinions would you want them to hear, what tasks would you want them to consider? In what form would you want their report? Which outside voices would you want to guide them/review their results? There's a lot of facilitation work to be done there, meetings to organize, documents to write, patches to summarize, etc.) I think a self-appointed Design Dictator Committee composed entirely of developers, some who may well have written portions of the patches under review, can easily do more harm than good. I'd rather see an all-developer Designer Enablement Committee whose job was to maintain design docs, collect issues for review, and generally make it possible to have a productive one-hour once-a-month design review meeting with the best *designers* we could get to do it. (Or once-a-release-cycle, as Christoph would have it.) If the problem is that the good designers don't have enough time, I don't think the solution is to use whoever we can find who has the time. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
I've said all I need to say, time to hear from other people. We'll know we've been successful when the new updated version of the Sugar HIG comes out. Until then, I guess just keep on pounding that big red button at 6 month intervals. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] New Sugar Web chat
On Wed, Nov 24, 2010 at 8:19 AM, Aleksey Lim alsr...@member.fsf.org wrote: Also, not sure if https should dramatically increase amount of traffic, anyway could be check both instances: http://chat.sugarlabs.org:9090/ https://chat.sugarlabs.org:9091/ It's not traffic, it's the number of round trips. According to page 30 of http://tools.ietf.org/html/rfc2246, I count an additional 3 round trips for the https handshake. At .5s-2s latency, that's an additional 1.5s-6s to connect. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
Random thoughts, not terribly connected: 1) agree with developers != designers. It's like developers != release managers. We developers can often play at being a designer (or a release manager), but we've got bad tendencies that sneak in, just because we know too much or know what's hard or just start thinking about how to code something instead of how to *use* something. It's fine to use developers as short-term stand-ins for an empty slot, but we should keep in mind the dangers and compromises involved. 2) That's not to say that a lot of the basic HIG work can't be done by a developer -- or a teacher, or *anyone*, really. There's a lot of don't want to touch that paralysis that we should try to get over. Step 1 of a HIG update could be to import the HIG into a more appropriate non-wiki tool, or to radically restructure how it is kept on the wiki to make it more of a living document, and/or to figure out how versioning should work. Step 2 is probably to go through and red-line the existing document to describe how (and why) the existing implementation doesn't currently match the design -- with maybe a rough idea of whether its the design or the implementation that's at fault. Both of these things don't actually need a designer, they really need *time*. A large design team composed mostly of folks without design training can still be of great ongoing assistance with these paperwork tasks. Progress can/should be made independent of finding the one perfect dictator. 3) I see a little bit of buck-passing going on, as a third-party observer. It seems like the real reason for a 3-person committee is that no one wants to actually step up and take on the responsibility of UX lead. Unfortunately, lack of clearly defined responsibility is the crux of the problem you're trying to solve, so I'm not certain that splitting the horcrux is part of the solution. Maybe it would be help to identify a single dictator and lieutenants (rather than the committee-of-3) with hat-passing as necessary -- so, for example, we can have 4 (!) design leads, but each one is ultimate dictator for one week a month. That reduces time commitment without diluting buck-stopping responsibility. 4) Agreed with the general sentiment that the best shouldn't obstruct the good. Even with the concerns I stated above about designers!=developers, having someone step up and actually start cleaning up the UX docs (and/or organizing the UX patch queue) is probably the most important thing. Dictatorship may (or may not) naturally evolve from this; if Walter and/or OLPC are going to find the perfect UX Design Dictator candidate in 2 months (say) then consider what you can do in the meantime to pave the way for the Messiah's arrival. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
(apologies for not having the time to make these messages shorter) Another way of thinking of this problem might be as civics-style separation of powers. Given that the problem is (simplified) UX design compromised by developers (wrong target users, implementing the easiest thing, whatever) -- how are we to guard against this? Any solution will necessarily slow development. That needs to be acknowledged as a cost. One solution might be to have a monthly UX oversight board meeting. For proper separation of powers, no member of the board may have a patch up for review by the board (or they must recuse themselves). Board candidates should also be chosen based on their resumes, not just because we think they could be convinced to serve. I suggest that it would be easier to fill the board if you keep the workload as light as possible. Therefore you could have a (large?) design team group whose job was *not* to make design decisions, but rather to facilitate the work of the oversight board. The board's work would be easy if it had a nice agenda for their meeting (which they didn't have to prepare themselves!) listing each patch/bug up for review, summarizing discussion pro/con, with relevant screenshots/video. The board could meet at a scheduled time each month (on IRC, or Skype, or videoconference) and (if necessary) voices pro/con the various proposals could show up and argue their case. The design team facilitators could then summarize the meeting, prepare minutes, guide the development of revised patches as necessary, etc. Timing/frequency/size of the board could be varied as time goes on based on workload, etc. Regardless of the strawman proposal above, my main point here is to suggest thinking about the role of design as a deliberate frustration of developers -- in the same way that the legislature and courts are a deliberate frustration of the power of the executive. I think this mindset would lead to a very different idea of Design Dictator that the one proposed early in this thread -- whose function seemed to be to rubber-stamp/expedite patches, not preserve UX. --scott ps. ...and preserving UX seems orthogonal to the task of maintaining design documents, which is a separate job description at litl, at least. -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
On Mon, Nov 22, 2010 at 9:37 AM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-11-22 at 07:23 +, Aleksey Lim wrote: You can try microformat ASLO updater from http://activities-testing.sugarlabs.org/services/micro-format.php?name=fructose Nice! I'm not sure about the size in KB... bytes would be more natural for machine parsing, but kilobytes look better in formatted HTML. I avoided doing this in the original specification because I meant the microformat to be human-writable, and I didn't expect humans to be able to reliably update these fields correctly. Besides, the size can be ascertained with an HTTP HEAD request, which takes very little bandwidth. Checksum should also be HTTP ETag. Again, less than 100 bytes. I believe that my original implementation did both of these optimizations, although I wouldn't be surprised if some servers didn't properly support HTTP HEAD and/or ETag. But I believe it is the server which should be fixed in that case. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
(oh, and the .zip file already has a checksum, it's not clear why you'd need another one.) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Heads up: dbus upstream planning to break sugar-jhbuild and sugar-emulator
It just seems like sugar-jhbuild/sugar-emulator should have its own user, then. I bet Michael Stone could help you out there. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Coding style: line continuations
FWIW, I greatly prefer continuations of parentheses-enclosed expressions to be aligned with the start paren. Which also happens to be emacs' default, for Python as well as c-mode. gratuitous-use-of-religion What crazy editor are you using which doesn't support this? /gratuitous-use-of-religion --scott ps. In fact I've been known to gratuitously parenthesize sub-expressions for the sole purpose of structuring their indentation. This is also the '-lp' option to GNU indent, which is included in both the GNU coding style for C and the KR style. It's also the correct indentation style illustrated in PEP8, saying Make sure to indent the continued line appropriately before giving an example with continuations aligned to parentheses. http://www.python.org/dev/peps/pep-0008/ -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Coding style: line continuations
On Fri, Nov 12, 2010 at 2:09 AM, Simon Schampijer si...@schampijer.de wrote: In general I would do what the spec says if there is no good reason not to [1]. The example they have does not really handle all the cases, though. Neither pep8 nor pylint does favor any formatting. So I guess we are a bit free here. I belive PEP8's example is rather definitive: ... Make sure to indent the continued line appropriately. The preferred place to break around a binary operator is *after* the operator, not before it. Some examples: class Rectangle(Blob): def __init__(self, width, height, color='black', emphasis=None, highlight=0): if width == 0 and height == 0 and \ color == 'red' and emphasis == 'strong' or \ highlight 100: raise ValueError(sorry, you lose) if width == 0 and height == 0 and (color == 'red' or emphasis is None): raise ValueError(I don't think so -- values are %s, %s % (width, height)) Blob.__init__(self, width, height, color, emphasis, highlight) I don't think there's any ambiguity there, actually. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Adopt Updater to new activity version scheme
On Thu, Nov 11, 2010 at 5:28 PM, Simon Schampijer si...@schampijer.de wrote: I hope there's documentation on the wiki for activity authors. (Ideally at the level of detail of PEP386.) There's certainly not source code documentation at any sufficient level of detail. --scott This [1] will go into [2]. Why isn't it there yet? --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Adopt Updater to new activity version scheme
I hope there's documentation on the wiki for activity authors. (Ideally at the level of detail of PEP386.) There's certainly not source code documentation at any sufficient level of detail. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Appearance Customization
I don't think you need to do any studies about whether kids want to customize their computers. This has been a constant message from deployments since day 1. The first thing kids did with the very first XOs fielded was slap stickers all over them to customize them. Unfortunately, kids have no sense of taste or decorum, and so their desire to have a hello kitty home screen (or whatever) is historically countered by NN's desire to be like Apple, all clean and elegant. This was supported by the UX design team, which wants a design which wins awards, not one that is plastered with kids favorite soccer players or whatever. Walter has tried to bridge this divide in the past by presenting it as a teaching opportunity: make one of the first XO lesson how to customize the code to change the XO man in the home screen or change the colors. This gives them incentive to learn how to hack the code. It's a very interesting compromise, and maybe it's even the right thing. Anyway, I think we should let the kids customize their machines easily -- certainly to change the colors. But this discussion is an old one. I wonder how it will turn out this time, maybe we've finally moved past some of the old bugbears. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Appearance Customization
I'm not certain that editing the existing gtkrc will be sufficient (although it would certainly be a good start). As my history briefly explained, Sugar was not designed to be 'colored' in the sorts of ways a kid might want. (We might care whether the text/icons are easily readable; they might not. Should we prevent them from doing what they want.) I think you'll probably also have to add some new gtkrc entries for styles like 'home screen background', etc, to allow changing these elements independent of the rest of the system. Using an HTML/CSS analogy -- the HTML has to be written with enough separate CSS style names so that interesting CSS can be written. It might be best to allow swapping out entire gtkrc files, rather than allowing individual gtkrc entries to be edited. This would make creating a theme somewhat more challenging, but you could easily allow kids to install/share whatever themes they liked, and it would actually give the theme author a lot more low-level knobs and dials to tweak. But again -- I think there should also be some effort made to expose the knobs and dials for changing the colors of various things, although maybe that's putting the cart before the horse. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Appearance Customization
On Wed, Nov 3, 2010 at 1:02 AM, Gary Martin garycmar...@googlemail.com wrote: Here's a mockup image using a blurred drop shadow for the icons and a simple wood texture desktop, yes it looks rather pretty, but it would consume perhaps 10% of memory on an XO-1, redraws and switching views would likely be unpleasantly slow. My very quick back of an envelope calculation for a 1200x900 24 bit image (~26Mb) could be roughly equated to being able to run one less (lightweight) activity at a time (Sugar generally starts to lockup, force kill activities, and/or reboot in these cases). For a limited-memory/power system, I don't think blurred drop shadows and 1200x900 24 bit images are the most appropriate choice. Think back to the ways you could customize an old Mac SE or Performa. Your choice of 64x64 background tiles, in 256 colors, and free choice of UI colors. No drop shadows -- it's your responsibility to pick a background color which is light enough to have everything remain legible. (Actual Macs really had simple 1-bit masked 'shadows', which worked fine for the purpose.) Phrasing the customization question as 'huge memory hogging customizations or nothing' isn't a good way to advance the customization. Rather, let's consider how radically we can allow customization *without* imposing any (or minimal) performance penalty. Certainly changing colors of the home screen can be done w/o any penalty at all. Even displaying a 'C. Scott's XO1!' label at the top of the home screen adds a lot of fun w/ neglible performance penalty.Changing the shape of the XO man in the center can also be done with minimal penalty -- how to do just that is already the subject of one of Walter's hacking the XO tutorials; there's no reason why a nice and friendly UI for changing the center man can't be added (except for all the clean design issues I outlined in my initial email). Let's add puppies! And soccer balls! And unicorns and stars! --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Thu, Oct 28, 2010 at 3:58 PM, Simon Schampijer si...@schampijer.de wrote: I have been giving the patches another go and made some smaller fixes for error handling. I have tested them as well to make sure there are no regressions. I give them my ok. http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Adopt-to-new-numbering-scheme-2425.patch http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Add-new-numbering-scheme-2425.patch Where's the documentation? Does this code correspond to a concrete proposal? Or do we expect contributors to reverse engineer the version scheme from pydoc sugar.bundle.bundleversion? --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Thu, Oct 7, 2010 at 12:39 PM, Daniel Drake d...@laptop.org wrote: On 4 October 2010 15:27, Gonzalo Odiard gonz...@laptop.org wrote: What do others think about this approach? Packagers? A clearer way to discuss this would be to just send a patch. That way there is no doubt over the details of the implementation that you are proposing. I object to implementations without documentation, on principle. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 6:58 AM, Gonzalo Odiard gonz...@laptop.org wrote: Then I plan to ignore the customization when I compute the order. So why is it there? b) use the debian version numbering system *exactly*. It has been shown to work in the real world, and it is well documented. The current proposal is neither (yet). We do not need to burden the world with yet another ad-hoc numbering system. Please build on other people's work instead of re-inventing the wheel. Just because the debian system has features you don't *think* you need (yet) is not a reason to bypass it. There are great benefits to sharing a commons. I agree with not reinvent the wheel, but not with using the debian versions. Why not the Fedora, Gentoo or OSX? If you want, we will be using the linux kernel numbering system :) Yes, please. Using anything from the *commons* instead of inventing a new *bespoke* system is preferable. Build connected communities, not islands. I am working with OLPC fixing Browse in sugar 0.84. The version we are using is Browse 108, but I cant release Browse 109 because already exists. The same problem we have, will have Dextrose or anybody who maintains a older branch. And count by ten it's not a good idea. Seems like count by ten solves the particular problem you have. It's the simplest possible solution that could work, which is a surefire way to avoid Second system effect [1] [1] http://en.wikipedia.org/wiki/Second-system_effect Either solve the problem correctly, or solve it as simply as possible. The current proposal does neither, and just adds a new layer of poorly documented ad-hoc-ery. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 5:00 PM, Martin Langhoff martin.langh...@gmail.com wrote: Initially, I advocated strongly for something with the expresiveness of dpkg's versioning. However, that's wrong. We need to use a clear _subset_ of what dpkg, rpm, portage(... etc) can do, so the distro packager retains its flexibility (see: epoch). Defining the version string as identical to the pre-epoch portion of a debian version string says a lot more in 11 words -- and with more precision -- than the entirely of the dotted version string proposal so far. This is the power we get from *building* on other's work, instead of reinventing it. (But we should remember what problem debian is solving with epoch numbers, and think really hard about why this could never ever ever happen to us before getting rid of them.) You could make a similar proposal based on redhat version strings, etc. We all *think* we need a subset right now. And then you'll find that subset grow, and mutate, etc, etc. We are all better off if we implement a well understood standard, even if we don't think we need all of its power immediately. It is true, dpkg considers 1.1-peru to be an upgrade over 1.1-argentina, due to alpha ordering. But that has no useful meaning. My personal feeling is that the peru and argentina part isn't really a version number, it's something else, which is misplaced here. But I don't feel as strongly about that. Either solve the problem correctly, or solve it as simply as possible. This solves it as simply as possible. I've outlined several simpler solutions. QED. Again, I think either the slightly more complicated (but more precise and easier to describe) solution (debian version numbers, exactly), or a simpler solution (say, just use only even version numbers for upstream releases, save odd numbers for localization teams) is preferred to the present proposal, which I think is both too complicated (by defining its own ad-hoc version string semantics) and too simple (0.1 possible, 0.0.1 impossible, at least according tohttp://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions). I think that's exactly the wrong way to optimize. Sugar doesn't need yet another ad-hoc undocumented scheme. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
If you're going to use something other than simple integers, I suggest either: a) a string of dotted integers. You should *always* be able to subdivide a release if necessary. Strings like peru belong (in my opinion) in release notes or the name of the activity or anywhere else. They don't tell you anything about version ordering. If the problem is that you can't put a new release between 0 and 1, why are you creating a system that causes the same problem, except between 0.0.0 and 0.0.1? b) use the debian version numbering system *exactly*. It has been shown to work in the real world, and it is well documented. The current proposal is neither (yet). We do not need to burden the world with yet another ad-hoc numbering system. Please build on other people's work instead of re-inventing the wheel. Just because the debian system has features you don't *think* you need (yet) is not a reason to bypass it. There are great benefits to sharing a commons. Of course, my preference is to keep the existing simple integers and solve the version precedence problem in other ways. Perhaps important activities should be encouraged to count by ten when increasing verson numbers -- or perhaps the tight dependency of Browse on a given Sugar version should be fixed. A truely forward-thinking replacement would replace the integer version numbers with a git-style version tree. Just say, this activity replaces the activity bundle with manifest hash abcdef. That is more decentralized, and more accurate. Each activity could/should contain a list of URLs describing the canonical source for both itself (authoritative) and its (say) 10 immediate parents (non-authoritative). This proposal could be elaborated -- and it paves the way for a truely decentralized activity repository, where activities are created *and hosted* by children *on their own machines*. (Isn't this stil the vision of Sugar?) --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] code submitted for review should have been tested
On Wed, Aug 11, 2010 at 6:22 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Because of this specific commit, file transfers have been broken since early this year and it's obvious that this code wasn't tested at all: http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/11828796 Given the current poor state of our testing efforts, committers should be extra careful about this. Out of curiosity: what was the failure? It's not obvious to me, in reading the patch; I can see how problems wouldn't be caught by a reviewer. If it's a Python syntax problem, you might consider using a tool to automatically report (ie, via email or directly into a bugtracker) uncaught python exceptions. That would give you better coverage at least of brain-dead it will crash as soon as you try to use it problems. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Home view activities layout
On Tue, Aug 3, 2010 at 6:39 AM, Walter Bender walter.ben...@gmail.com wrote: (3) even with the above resolved, we have arguably too little control over the home view, both in terns of what appears -- several requests have been made for the ability to have views of multiple collections: e.g., school view, home view, etc. and the ability to customize (as the Random View currently supports). (Also, there is often a request for a background image for the Home View.) All of these are features that could be added incrementally, preferably after we settle item #2. (My favorite solution for collections is to allow multiple stars, like in gmail.) My radical suggestion (years ago) was that the Home view should be an activity, like any other activity. It should be possible to install new home views just like any other activity bundle. In that environment, a thousand flowers can bloom. (Incidentally, I believe that the network view should also be an activity. The Journal already is an activity; it should be more easily replaceable.) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Home view activities layout
On Sun, Aug 1, 2010 at 12:22 PM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Aug 1, 2010 at 10:54 AM, Christian Marc Schmidt christianm...@gmail.com wrote: Any pattern will eventually run out of space. A space-filling curve (Peano curve) might be interesting. There is an orthogonal question, It's not strictly true that any pattern will eventually run out of space. The original layout code, as I recall, also had provision for zooming the icons out. So you can shrink the icons down arbitrarily and there is no particular limit on how many you squeeze in. That said, a home view with one-pixel high icons is pretty useless. So this is just quibbling about a technicality. I did investigate space-filling curves of various types at the time I was writing the Sunflower layout. I couldn't come up with anything I liked aestheically -- which just means that the opportunity is still available for others to come up with something! I'm not completely sold that panning and zooming is the right answer to the problem. There are (at least) two other orthogonal axes: nesting, and search. The iPhone interface chose to add first search, and then nesting, rather than to simply add extra panes to the left, right, up, down, etc. This isn't to say that we must follow their lead -- just as a reminder that the solution space is not as constrained as it may appear. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Wed, Jul 28, 2010 at 12:06 PM, Bernie Innocenti ber...@codewiz.org wrote: There's no reason to have both a filename and a dbus-like name for the same thing. The former must already be unique on both distribution sites and in the Activities directory. I claim we should be using the dbus-like name for both distribution sites and in the Activities directory. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Tue, Jul 27, 2010 at 5:14 PM, Bernie Innocenti ber...@codewiz.org wrote: The bundle base name (e.g Record) should be unique by itself, because you can't have two directories named Record.activity in your activities directory. This is, IMO, a bug. The directory should really be named after the bundle id. The bundle ID is not a dbus name, it just conforms to the character rules for dbus names. To quote http://wiki.laptop.org/go/Activity_bundles : -- begin quote -- This is the activity bundle identifier. It is required. The name should conform to the D-Bus spec - in particular, hyphens are not allowed (although this wasn't enforced in earlier builds, see Trac 6226). It is recommended that Java package naming conventions are used when chosing bundle identifiers, to ensure uniqueness. Briefly, your name should begin with the reversed domain name of an organization you belong to. The reversed domain name part is supposed to be rooted in some actual DNS-rooted namespace. You don't need to own this domain; you just need to have a reasonable claim on some unique name at that domain. There are several ways to derive one: If your email address is yourn...@somemailhost.com, then you could use com.somemailhost.yourname.YourActivity. You could set up a web page on a free hosting service with information about your activity, and use a name derived from its URL. For example, if you create a page at http://www.geocities.com/xotumusica for your activity, then com.geocities.www.xotumusica is a reasonable bundle_id. If nothing else is available, even org.laptop.wiki.YourActivityPageTitle is probably a reasonable bundle_id, provided that you create the YourActivityPageTitle page. Remember, bundle_ids should be unique, so you should double check that the YourActivityPageTitle page doesn't already exist (and then create it) before using this as your bundle_id. end quote This is a nicely decentralized mechanism for choosing identifiers which are guaranteed by construction never to conflict. Even if it were possible to install org.sugarlabs.Record and com.microsoft.Record in parallel, having two different activities with the same name would be confusing and almost never what the user expected. You're neglecting localization issues here. Perhaps there's still something we could do to simplify the design without breaking backwards compatibility: if an activity doesn't specify a bundle_id, its dbus name could be derived from the bundle name by pre-pending org.sugarlabs. (or org.laptop., it doesn't matter) to it. If sugarlabs is willing to maintain a mechanism for ensuring uniqueness, feel free to prepend org.sugarlabs to whatever activities you have registered. For all other purposes, the bundle_id is just a string which could contain anything. The bundle_id org.tuxpaint.sugar-is-lame worked flawlessly for all this time. Yes, this identifier is childish, but conforms precisely to the rules outlined above, which ensure its uniqueness. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Tue, Jul 27, 2010 at 6:57 PM, Bernie Innocenti ber...@codewiz.org wrote: On Tue, 2010-07-27 at 18:21 -0400, C. Scott Ananian wrote: This is a nicely decentralized mechanism for choosing identifiers which are guaranteed by construction never to conflict. It is indeed a simple and nice scheme, but why is such uniqueness a desiderable feature when developers can--and in fact *do*--often distribute forks of existing activities? I think this is an orthogonal problem. I'm sure that some disagree. (if the bundle_id were instead changed, funny things would happen when a user tries to install both bundles on the same machine). Bug. If sugarlabs is willing to maintain a mechanism for ensuring uniqueness, feel free to prepend org.sugarlabs to whatever activities you have registered. A good surrogate could be that no two activities with the same name can be uploaded to ASLO. Translated name? English name? No Spanish name may conflict with a Portuguese or English name? Seems a bit strange to me. For all other purposes, the bundle_id is just a string which could contain anything. The bundle_id org.tuxpaint.sugar-is-lame worked flawlessly for all this time. Yes, this identifier is childish, but conforms precisely to the rules outlined above, which ensure its uniqueness. It's not actually conforming, it has hyphens! ;-) Oh, that's right, I *did* have a legit reason to dislike the name! ;-) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
On Mon, Jul 26, 2010 at 11:27 AM, David Farning dfarn...@gmail.com wrote: patch review process and (b) loosing patches. If a patch is a solution to a problem it is not necessary to discuss the problem and if it is the patch submitters responsibility to track the patch the need for a maintainer to track the patch goes away. It's easy to say it's the patch submitter's responsibility, but that: a) alienates new members of the community, who feel like their patches are being ignored and don't understand why their help is not appreciated, and b) begs the question: now what does the patch submitter use to track submitted patches? For major developers, this is still a big problem, and patches are lost simply because the developer lost track of them in the process. Similarly, even though a patch may be the solution to a problem doesn't mean its the best solution, or that the patch doesn't need work (style fixes, regression tests, fixes for corner cases, backports, updates to latest git). Often a developer can push a patch so far and then needs to move on to other things. Using a patch process -- ideally one associated with a bug tracker -- lets other developers pick up the pieces and finish the patch where needed. It's not hard to see examples in (say) Mozilla's bug tracker where 2 or 3 developers (and several years!) were taken to take a particular patch all the way through the review process. All of the patches attached to the bug were the solution to a problem, and often individual users were successful in manually applying those patches to their local copy of the code for some particular use, even though it was not ready or able to be committed yet (for instance, it didn't apply to git head any more!). So, following Einstein's maxim that a process should be as simple as possible but not simpler -- I think you've made things too simple. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
On Mon, Jul 26, 2010 at 6:18 PM, David Farning dfarn...@gmail.com wrote: Is it preferable to worry about potentially alienating new members because their patches 'might' be ignored or is preferable to worry about the existing patches which deployments have written but have given up trying to push upstream because of the current review process? Please see http://people.sugarlabs.org/bernie/sugar/sugar-0.88-patches/ From http://people.sugarlabs.org/bernie/sugar/sugar-0.88-patches/merge-plan.txt it appears that the review process is working as intended: Some of these patches have outstanding quality issues A bug tracker is probably exactly the right thing to use here. In many projects, patches with quality issues which are still driven for inclusion by a release team will get committed, but a bug will be *opened* to record the additional work still needed. When this is not done, it seems to me to indicate that people do not trust the bug tracker. So maybe we're really not talking about patch review process at all, but about how bugs are entered, recorded, *not forgotten*, and (eventually) closed. Is there a release process people trust to ensure that bugs targeted for a certain release are eventually resolved? If one were to commit some of Bernie's patches, how would we ensure that someone gets around to fixing their quality issues for the next release? --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On Sat, Jul 3, 2010 at 9:54 AM, Bernie Innocenti ber...@codewiz.org wrote: NetworkManager used to call ntpdate when it setup a connection. Was that an OLPC addition? Yes, although it's now present in litl's software builds as well. We figured out that the ntp package has never been present on the XO images. It was ntpdate, which was smaller than the whole ntp package. There's no way to practical way to implement effective anti-theft without taking away root from the user. And once we take away root access, we've also taken away olpc's principle #1: child ownership. See my recent message on this topic. Apart from the hardware fix (which avoids RTC dependency altogether), it is also possible to separate most of root's authority from the RTC priviledge. Installing software, for example, requires root access to the filesystem, but not access to the RTC. What are the school servers doing to keep their clocks reasonable? They're using ntp, with the Fedora pool of ntp servers. You should probably apply for your own pool: http://www.pool.ntp.org/en/vendors.html#open-source It's pretty painless, and makes you a better netizen. Why aren't we using ntp? ntp is probably overkill for XOs. Besides, who would want to give up that much ram? On top of that, ntpd doesn't get along with power saving mode. That's why you use ntpdate. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 7, 2010 at 2:16 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Rainbow, on the other hand, has seen a major new release, feature development that spurred new work in general Linux sandboxing, and is now available in more distributions than ever before thanks to dedicated support by folks like Luke, Sascha, and Jonas. Finally, if rainbow itself now receives little day-to-day attention, this is because it mostly does what its authors require and it does it well enough not to require their continued hand-holding. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software - compile on demand is a regular workflow within 0install (existed sugar doesn't not let such possibility:), rainbow should be more then essential requirement. I took some time to read up on 0install -- very impressive technology, good work. I agree with Michael that this (userland installs) is the direction Sugar should be pursuing. With rainbow (or other sandbox) integration, this would accomplish all of the original goals with a much more robust packaging and dependency system than the .xo bundle. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
On Tue, Jun 22, 2010 at 4:28 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: - Ideally something (Gnome I assume?) should trigger the keyboard overlay when you focus on a text field, perhaps with some hints about what the 'return' key behaviour should do (or expose a tab key as that is usually the other common text field navigation method). Dismissing the keyboard overlay when a text field is defocused would also be ideal. AFAIK, this requires a GTK+ module to be loaded. I'm still trying to write a proof of concept implementation of this - it seems that there's no documentation anywhere for writing GTK+ modules :-( Yeah, I gave up and just used LD_PRELOAD when I had this problem. If you want to try the quick-and-dirty way for a proof of concept, this might be handy: http://dev.laptop.org/git/users/cscott/journal2/tree/ Do all of firefox/xulrunner/chrome use GTK widgets for text entry? I'm nervous that some programs might not pop up the keyboard appropriately. You could add a gesture to force the keyboard up even for badly behaved applications. I think the iPad/iPhone gesture for that is dragging your finger from the bottom of the screen to the top. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Schoolserver icon
On Tue, Jun 29, 2010 at 7:00 PM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Jun 29, 2010 at 6:34 PM, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 29-06-2010 a las 02:49 +0100, Gary Martin escribió: Here's a few more misc. plays around school building shape. Maybe I'm being too literal here and should stray more down the server/resource aspect, rather than a school aspect? Shout if you think one works better than others (or some specific feature): For me, the one on the bottom left is the one which better communicates the concept of school. Might be something we eventually have to localize. None of these look anything like the schools I have seen in Nigeria, Thailand, etc. Most icons don't look anything like what they represent. I like the dailymotion one; it's consistent with the sugar theme, and I personally think the bell is an important visual element here. It's true, the schools I went to in central america usually had a big steel pipe the teacher would bang on to summon us, instead of a nice traditional bell shape, but I think the summon kids to school element (in some form) is a nice hook for a school icon. That said, a schoolserver isn't really a school (neither is a floppy disk a decent representation for 'save'), so an abstract shape would work just as well. But if we're going to go for representing a school, I vote for a bell. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add ds2xos conversion script to export
On Sun, Jun 27, 2010 at 9:53 PM, Michael Stone mich...@laptop.org wrote: El Sat, 26-06-2010 a las 23:07 -0400, Michael Stone escribió: * whose name is URL-encoded with spaces encoded as pluses Why pluses? Because they're nicer than %20 and python provides urllib.quote_plus? Can't we simply leave spaces as spaces? Have you got a shell that doesn't require me to escape them in order to process the resulting files? Or convert them to '_' and use '~' or ';' as a version separator? Thanks; I prefer characters which don't need to be shell-escaped. FWIW: shell will only expand ~ in first position; a~b is fine. using ; as a version separator has a long and distinguished history (http://en.wikipedia.org/wiki/Files-11) anyone who hasn't figured out how to use -0 options to grep, xargs, find, etc in order to properly handle spaces is living in the past filenames in spanish will look terrible with %-escapes for áéíñóú anyway, and utf-8 is not reliable on FAT (sigh). if you can get people to format their USB sticks with NTFS, whose kernel support is pretty good, you can use utf-16 and a much smallest set of bad codepoints. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
It might also be worth thinking about how this would play out in Squeak/Etoys. See in particular: http://wiki.laptop.org/go/Smalltalk_Development_on_XO#Submit_your_changes --scott attempting to learn from the community ps. as bert's doing the only multitouch work (that I know of) I've given some thought recently to what Sugar II would look like if it were totally implemented in Squeak/Etoys. Why not? --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
I don't know about RH, but @ litl we're using all-introspected bindings w/ a distro based on Ubuntu Hardy. So backporting shouldn't be too painful, really. (Of course, we're not using the python introspection, so you might have other troubles there.) +1 on introspection in general. Hopefully the python introspection support is sufficiently lazy -- we certainly haven't had any startup issues w/ gjs. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore rewrite
As far as I know, you could use fuse-mounted olpcfs to store the journal files, and obtain this space savings (which is technically known as deduplication) with no extra effort. You could also store the files in git for the same effect. --scott On Sat, Jun 12, 2010 at 3:07 PM, Frederick Grose fgr...@gmail.com wrote: On Sat, Jun 12, 2010 at 12:57 PM, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 12-06-2010 a las 11:40 -0400, Benjamin M. Schwartz escribió: 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. I tend to agree with you. 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. Sounds like a good approach, please ping me to review the spec when it's available. Some references here: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal Sascha Silbe's Datastore redesign draft with embedded comments from Eben, Tomeu, Sascha: https://docs.google.com/a/sugarlabs.org/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGhthl=en (Sugar Labs account holders may edit this document.) As an optimization to reduce the number of inodes and vfs syscalls, perhaps it might be worthwhile to let the activity specify whether it needs to store one file or a directory with multiple files. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] music USB keyboard for Tamtam
On Tue, Jun 8, 2010 at 3:34 AM, Sameer Verma sve...@sfsu.edu wrote: I'm looking for a musical keyboard device (black and white keys like on a piano) that plugs into USB on a XO and allows one to play music via TamTam. Does such a device exist? If so, pointers? Well, I don't know if any such keyboard is supported by TamTam, but there are a lot of relatively cheap USB piano keyboards out there, like: http://www.thinkgeek.com/electronics/musical-instruments/af36/ --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2010-05-25
On Wed, May 26, 2010 at 12:24 AM, Michael Stone mich...@laptop.org wrote: On Tue, May 25, 2010 at 11:54:42PM -0400, Chris Ball wrote: That's certainly true in general, but would it have to follow that a bug couldn't be counted as fixed, for the purposes of conducting the competition when a patch is approved? It doesn't have to mean that the bug on SL Trac should be closed as fixed. Cool, then can we have a competition for moving bugs that have fixes with a patch to a release? ;-) Sure. Just award points for every action transition listed on http://wiki.laptop.org/go/Trac_ticket_workflow in addition to the one suggested by Gonzalo. In fact, you could just reimplement for trac what's already implemented for bugzilla.gnome.org and bugs.launchpad.net -- a point or karma system that awards points based on bug transitions. --- bugzilla.gnome.org says: --- C. Scott Ananian * added 189 comments to bugs. * closed 14 bugs. * reported 41 bugs. * gathered 12 points. --- eof --- --- Launchpad says: --- This is a summary of the Launchpad karma earned by C. Scott Ananian, organized by activity type. Bug Management 179 Total karma: 179 These are the latest actions which have contributed to the Launchpad karma earned by C. Scott Ananian and the dates on which the action occurred. DateAction 2010-04-20 12:22:49 EDT 2010-04-20 New Bug Filed 2010-04-08 15:39:51 EDT 2010-04-08 Bug Comment Added 2010-04-08 15:30:37 EDT 2010-04-08 Bug Comment Added 2010-04-08 15:30:37 EDT 2010-04-08 Bug Comment Added 2010-03-08 09:37:44 EST 2010-03-08 Bug Marked as Fixed 2010-03-02 11:58:01 EST 2010-03-02 Bug Comment Added [... etc ...] --- eof --- See also http://blog.launchpad.net/cool-new-stuff/karma-for-commits You can play the FIFA cup year 'round! --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Did someone say Webkit?
On Mon, Apr 26, 2010 at 8:38 PM, Bobby Powers bobbypow...@gmail.com wrote: I wrote surf a while ago, and it was quite an easy port. In fact, the demo browser for pywebkitgtk was (at least at one point) based on browse. I did most of the work in a day and a half, but ran into problems with both webkit's packaging and the feature-completeness of pywebkitgtk (the ability to download files, for example), both of which seem to be solved now. There are also gir bindings for webkit (in webkit's trunk), so it might be worth investigating their completeness, especially since pywebkitgtk seems to be unmaintained, as Sayamindu pointed out. I believe we use the GIR bindings for webkit at litl. So you can probably consider them well supported. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Did someone say Webkit?
On Tue, Apr 27, 2010 at 8:56 AM, C. Scott Ananian csc...@laptop.org wrote: There are also gir bindings for webkit (in webkit's trunk), so it might be worth investigating their completeness, especially since pywebkitgtk seems to be unmaintained, as Sayamindu pointed out. I believe we use the GIR bindings for webkit at litl. So you can probably consider them well supported. Marco says I'm wrong: we're driving webkit over dbus. I know our *dbus* gir bindings are well supported! (I'm writing all my code for the 8051 these days.) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Modern Linux trends (was: Re: [PATCH] use ConsoleKit instead of HAL for)
Sorry, Sascha, didn't mean for the attack to seem personal. And Martin, I'm not sure NetworkManager is really the right tool for your (server) job. NetworkManager's goal in life is dynamic roaming, not static setups. I'm not necessarily defending NM: lord knows I wish it had better docs and a more stable API. I'm just saying that a command-line interface isn't the be-all and end-all. The goals of network manager aren't terribly well served by a CLI, and NM does have strong scriptability via other mechanisms. If the thread started as why doesn't networkmanager do XYZ or ...have better docs I wouldn't have felt it to be a troll. But bitching about lack of CLI doesn't get my automatic sympathy. If NM doesn't do what you want, let's write the tools/patches necessary. But don't start complaining just because the kids don't use getopt anymore. --Scott On Monday, April 26, 2010, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Apr 26, 2010 at 5:51 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: What I want to be able to do is exactly the same I can do using nm-applet. That would be a good start. Reasonable feature parity with the old network scripts would also be great. The best that I can say of NM is that Dan moves quickly, and cares. At this stage it's mature for many uses, but cli and server usage are rather green. And that for server scenarios the model of having a daemon is not the best fit. Is there any good documentation of a fullblown cli for it? Good docs of a fullblown config setup for servers (including bonding, bridging, virtual interfaces and similar goodies)? It's puzzling to me why Scott is jumping to defend NM. While in general things are getting better on the linux world, sometimes new tools have large green areas. NM has taken a long long time to mature to where it's at (it's not an easy job) -- but it's silly to say it excels at things it... well, doesn't (yet?). Learn the new tools, Where's docs, examples? Where's --help ? man and --help on nm-tool on F-12 don't have anything to say for example. Who else is using it? Or are we going to pioneer it, and file all the bugs tht come with the territory? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Modern Linux trends
Brief tutorial on Gobject: http://cananian.livejournal.com/58744.html Sorry, Bernie you don't get any sympathy from me: XFConfig deserves to die, no matter how much you liked it. And are you really running Gentoo and complaining whenthings break? Seriously? That's the price of unstable (and progress): sometimes things get broken before their replacement is quite ready. I'm not a udev expert yet either, but as far as I can tell it's not obviously the wrong thing here. Maybe you should try to contribute udev versions of the hal-* cli tools, if they don't already exist? --scott On Monday, April 26, 2010, Bernie Innocenti ber...@codewiz.org wrote: On Sun, 2010-04-25 at 18:54 -0400, C. Scott Ananian wrote: I am failing to resist responding to this troll. Dbus access from the command line is fairly good, and NM supports a number of static data files for configuration if that's what you want yo do. Fear not, scriptability of Unix systems is, if anything, *increasing*, as there are now powerful ways to get at the internals of most system software using things like gobject, which provide much more powerful mechanisms than simple pipes and getopt. +1 Insightful. You would have got a +1 Informative if you'd link to a nice tutorial. I've always wanted to learn how to control things with dbus. Learn the new tools, you'll like them. Arguing from the stuck-in-the-mud old fart perspective may be fun, but it's not constructive. Bah, such a luddite! ;-) I'll go back trying to get my scroll wheel emulation to work in my brand new X 1.8. The old xorg.conf way was way too easy: Option EmulateWheel 1 Option EmulateWheelButton 2 When static configuration files fell in disgrace, I figured out that I could achieve the same functionality by means of this simple HAL fdi: /etc/hal/fdi/policy/10-bernie.fdi: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.mouse merge key=input.x11_driver type=stringmouse/merge match key=info.product contains=TPPS/2 IBM TrackPoint merge key=input.x11_options.EmulateWheel type=string1/merge merge key=input.x11_options.EmulateWheelButton type=string2/merge /match match key=/org/freedesktop/Hal/devices/computer:system.kernel.name string=Linux merge key=input.x11_driver type=stringevdev/merge /match /match /device /deviceinfo Now hal also fell in disgrace and devices are being configured directly by udev. Being clueless, I asked my friends on #xorg-devel: bernie whot: what's the udev equivalent of these hal rules for Xorg 1.8? remi|work bernie, we started writing an upgrade guide for our users with a couple examples : http://dev.gentoo.org/~scarabeus/xorg-server-1.8-upgrade-guide.xml bernie remi|work: thanks! dberkholz remi|work: yeah, i guess we could reverse our old script that translated xorg.conf to fdi dberkholz wherever that thing ended up remi|work dberkholz, that script is dead, it relied on xf86config which can't be pulled easily from the server dberkholz it's been a while, but i thought we had figured out some way around that remi|work dberkholz, besides, I've never been a huge fan of that script. I think our users should know what they're doing remi|work so we're documenting it properly dberkholz i think knowing what you are doing is different from creating needless work dberkholz when will people ever need to repeat this task again? how is it a valuable skill? remi|work then let's not run the script by default remi|work if you create one... remi|work IMHO, trying to figure out how to parse HAL .fdi files isn't much fun. remi|work and given the complexity HAL files can reach, I don't think it'll work reliably dberkholz sigh. that dumb script was never written to actually understand the xml, just to output tags as raw text. Eventually, I wrote this: Section InputClass Identifier TPPS/2 IBM TrackPoint Wheel Emulation Driver evdev Option EmulateWheel true Option EmulateWheelButton 2 MatchProduct TPPS/2 IBM TrackPoint EndSection Unfortunately, it doesn't seem to work. I'm not really sure what the product string is supposed to be, and testing changes requires restarting X. Meanwhile, I'm typing two obscure xinput commands manually every time I start my X server: xinput --set-int-prop 'TPPS/2 IBM TrackPoint' 'Evdev Wheel Emulation Button' 8 2 xinput --set-int-prop 'TPPS/2 IBM TrackPoint' 'Evdev Wheel Emulation' 8 1 Ah, progress... why don't anyone just love it? Now you've got to be a hacker with connections with the Xorg core developers in order to configure your clit mouse on Linux! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- ( http://cscott.net
Re: [Sugar-devel] Modern Linux trends (was: Re: [PATCH] use ConsoleKit instead of HAL for)
Replying to quoted text is hard from my phone; bear with me. On Monday, April 26, 2010, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Sun, Apr 25, 2010 at 06:54:13PM -0400, C. Scott Ananian wrote: and NM supports a number of static data files for configuration if that's what you want yo do. What I want to be able to do is exactly the same I can do using nm-applet. As for the static config files, I considered that in the past, but failed because I couldn't find any documentation locally (and didn't have internet access because that was exactly what I was trying to set up on the only laptop I had with me). Even now I find the documentation [1] to be rather lacking. I'm referred to the settings specification [2] for finding out what settings I need to supply; the specification lists 139 keys in 15 settings. It would take me hours to figure out how to connect to a bog-standard WPA2 access point this way. You seem to have experience using these files: would they work the same way using system connections with nm-applet would do? I.e. can I still change location and have NetworkManager connect automatically to available networks? Will Sugar still be able to show all available networks and let me pick them? yes. The best documentation is to connect to the network you like in gnome's nm applet and save it as a system connection. The resulting XML file in nm's connection dir will show you what settings you need. I also recommend d-feet for interactively querying NM for connection properties and settings. so far I'm getting quite frustrated every time I try, wasting countless hours trying to accomplishing something that would have taken me mere minutes before. A normal user would be totally out of luck. Maybe NetworkManager us the wrong tool for the job, then. Are you trying to drive a nail with a screwdriver? FWIW, I'm even planning to enhance Sugar [3] so I can run nm-applet, just to be able to _configure_ NetworkManager. It sounds like you really want to run NM's connection editor, which is a seperate application. Nm-applet itself is trivial to clone, and afaik sugar already did a good job of that. The smarts are all elsewhere, either in the headless NM daemon or in the connection editor. --Scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Modern Linux trends (was: Re: [PATCH] use ConsoleKit instead of HAL for)
I am failing to resist responding to this troll. Dbus access from the command line is fairly good, and NM supports a number of static data files for configuration if that's what you want yo do. Fear not, scriptability of Unix systems is, if anything, *increasing*, as there are now powerful ways to get at the internals of most system software using things like gobject, which provide much more powerful mechanisms than simple pipes and getopt. Learn the new tools, you'll like them. Arguing from the stuck-in-the-mud old fart perspective may be fun, but it's not constructive. --Scott On Sunday, April 25, 2010, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Sun, Apr 25, 2010 at 02:16:34PM -0400, Bernie Innocenti wrote: unified, perhaps, except that access from shell (last i looked) was fairly inadequate. So I'm not the only one to be disgusted by this trend? Certainly not. Modern Linux is becoming worryingly similar to MacOS and Windows. In some ways it (*) already got worse - see the recent Xorg decision to use a fixed DPI value. CLI support is being added as an afterthought to new subsystems: http://fedoraproject.org/wiki/Features/NetworkManagerCmdline Oh yeah, my pet peeve. None of the CLI tools for NM that I tried so far were really useful, and this one doesn't look any better. :-/ I don't need a way to script pressing a button on nm-applet, I need a full-featured replacement for it. I need a way to _configure_ system connections, not just use them. (*) Actually I'm referring to the usual ecosystem around Linux, not the kernel itself. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [GSoC] Sugar Browser
FWIW, at litl we are switching from a xulrunner-based brower to a chromium-based browser. We are seeing a big performance improvement, plus it's making it easier for us to implement plugin isolation and better memory management (unloading pages which are not foregrounded, etc). YMMV, and it's been about 3 person-months of work, but I can suggest from experience that it may be worth it. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Test request: Wifi encryption changes...
Clear network settings does have other uses, even in the absence of bugs: you may want to remove a network from being autoselected, or remove a password for a home network before lending your device to someone. In the absence of a per-connection editor (like nm-applet has), clear network settings gets the job done. --scott On Friday, February 12, 2010, Martin Langhoff martin.langh...@gmail.com wrote: Hi lists, I've recently been working on wifi wpa association issues on the 8.2.x releases (F-9, NM-6.5, Sugar 0.82) and there is bug I would like to ask people to test for with Strawberry (of F11 images on XO), Blueberry and the 0.87 SoaS builds. I have definitely seen it a long time ago, and it was known, but it wasn't on dev.l.o as an open bug so I tracked it as http://dev.laptop.org/ticket/10021 To repro you need an XO or SoaS and an access point... * Setup an AP with WPA or WPA2 encryption, with a passphrase * Connect to it from XO giving the right passphrase * On the AP, change the passphrase * On the XO, reconnect. The reconnect will try to use the stored passphrase, fail, and ask for a new passphrase. However, NM ignores the new passphrase. Similar issues are likely to exist with changing between no encryption, WEP, WPA, WPA2. Hopefully this is fixed in newer NM + Sugar, but it is something nobody has been testing, and it does mess things up in the field so we need your help... If this gets fixed, then we can remove the ugly delete network info button from the control panel (which is just a workaround for this). (Why am I asking for this? I don't have equipment at all at this moment, as I am on the move.) cheers, martín -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Automatically Retrying an AP?
On Thu, Feb 4, 2010 at 12:08 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Thu, Feb 4, 2010 at 9:49 AM, C. Scott Ananian csc...@laptop.org wrote: I think I convinced myself that network manager was the right place to make the patch, because you want to reuse NM's list/order of The right place, I am sure, is the kernel or firmware ;-) For my specific case, I am trying to find the codeblock that controls the try known APs, if they don't work cycle though mesh frequencies. I am pretty sure that this control cycle happens in Sugar/Python code. I thought that had been moved into NM. I could be wrong. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
