Re: [sugar] Image Viewer Activity
Sayamindu Dasgupta [EMAIL PROTECTED] writes: I was a little annoyed with having to start up Browse to view images, and since I had done a small toy PyGTK based image viewer widget sometime back, I decided to put that in an activity over the weekend. You can download it from Nice! Here is a fr.po file for it. ImageViewer.fr.po Description: Binary data -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Signed candidate-765 and gg-765-2 builds available for testing.
Important: has anyone successfully upgraded/installed to the signed candidate-765? 1. I retried `sudo olpc-update candidate-765` from 8.2-763 on a secure (developer.sig moved away) XO. This time it worked fine. 2. I followed http://wiki.laptop.org/go/Clean-install_procedure to go back to build 650 (for that Christmas 2007 ship.1 feel :-) ) on a secure XO. su -l olpc-update candidate-765 succeeded, after errors in irsync_pristine and irsync dirty but apparently no out-of-memory problems. This wasn't a perfect test because I didn't revert firmware as well, I was on latest q2e18 firmware throughout. After reboot Software update's Checking for updates hung in Loading groups... , just as Walter Bender reported to testing list. I think this is bug 8681, fixed in build 766. shell.log had two WARNING root: Activity directory lacks a MANIFEST file. then exception from actinfo.py, line 138, in get_activity_group_urls with open( USER_GROUPS_FILE, 'w') that No such file or directory: '/home/olpc/Activities/.groups' 3. Carlo Falciola updated from 711 (8.1.2) to candidate-765 using olpc-update -usb, see separate e-mail. I changed the wiki Sunday night and I think all the links and banners mentioning candidate-765 work. Nobody replied to my question about the gg-765-2 image below. Michael Stone wrote: I have also published gg-765-2, a signed G1G1 candidate composite image, created by Scott. gg-765-2 is similar to what we hope to put into manufacturing next week. ... http://download.laptop.org/xo-1/custom/g1g1/gg-765-2/ (G1G1 composite) Where should this be mentioned? Should someone doing http://wiki.laptop.org/go/Clean-install_procedure copy this image? -- =S Page user:skierpage ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
On 29 Sep 2008, at 19:49, Bert Freudenberg wrote: Am 29.09.2008 um 11:46 schrieb Sayamindu Dasgupta: On Mon, Sep 29, 2008 at 11:57 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote: A screenshot is at http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png The code lives in Git: http://dev.laptop.org/git?p=users/sayamindu/imageviewer-activity;a=tree Comments, patches and brickbats are welcome :-). Thanks, Sayamindu Hey, fantastic, thanks! :-) --Gary P.S. Any hints on changing the default activity that takes charge of a mime type? No clue on how to set the default activity associated with a mimetype :-(. If anyone has any ideas, please let me know :-). /usr/share/sugar/data/mime.defaults Thanks Bert, that trick works a treat. I guess this needs to be exposed at some future point in the Control Panel UI, or at least something that can be over-ridden by a local deployment with a customisation key. Imave viewing workflow with the Journal just got a whole bunch smoother! --Gary P.S. Sayamindu, want an SVG icon to go with it? Or do you have something planned? I was thinking just a rectangular picture frame with a very simple mountain/sun/cloud type thing. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar Digest 2008-09-30
=== Sugar Digest === First, an aside: I introduced the concept of peer editing in the Floss Manual on the Write Activity by referencing the late Don Murray, who taught generations of journalists how to write. He had three simple rules for great writing: 1. revise 2. revise 3. revise Revision is an essential part of the writing process and one of the easiest and most effective ways to revise is to share the burden of editing among your friends. Hand your writing to a friend, who will read it and make comments and suggestions. You return the favor by doing the same for your friend's writing. While riding my bike into Cambridge yesterday, it occurred to me that a simple peer-editing exchange for bloggers would be easy to set up; it could make a world of difference in the quality of the writing, while not in any way impinging upon the freedom and spontaneity that characterizes the blogshpere. In deed, I am of the opinion that one of the biggest differences between blogging and the mainstream media is the strong editorial tradition of the latter. So why doesn't someone set up a social-networking site—ideally integrated with the popular tools such as Word Press—to enable bloggers to find a willing peer to suggest revisions before the publish button is pressed (a Send to editor button)? Such an exchange need not be symmetric—some people prefer the role of critic to creator; it would be a simple, powerful enhancement to the blogsphere. (Or does such a site already exist?) 1. Open Minds: David Farning and I had the opportunity to attend the Open Minds conference in Indianapolis this past weekend. It was refreshing to spend time with so many teachers passionate for learning and creating opportunities for their students. I tried to tune into dicsussions about the various roadblocks that inhibit the introduction of technology into schools and into classrooms. The list is pretty long and some of the items are formidable, but nonetheless, there are obvious needs and teachers and administrators who are fighting for change. There was lots of interest in Sugar—teachers and administrators are looking for an easy (and inexpensive) way to try it in their classrooms. A few specific outcomes from the conference: Nate Ridderman will be helping set up a Sugar classroom in an elementary school in Indianapolis that is doing a one-to-one laptop experiment; David and I will be helping set up a Sugar classroom in a Boston public school that trying to make use of some old Pentium IV desktop machines; we also discussed making Sugar available as part of the offerings from some hardware OEMs who focus on the education market, including Retronics (2goPC) and Resara (who offer a thin-client solution). 2. LiveUSB: It seems that a LiveUSB offers the most simple way to experience Sugar on a preexisting hardware base, such as a school computer lab. (One advantage of a LiveUSB approach—where user data is stored in a disk partition—is that the same key can be used at school and at home, emulating the experience of a one-to-one laptop program, where the laptops go home with the children. The Fedora team has made progress on a LiveUSB this week (See Item 11 below) and we are also working to get fresher Sugar bits into the Ubuntu LiveUSB. However, there remains a problem in that many computers do not have boot-from-USB enabled in the BIOS. Steve Pomeroy suggested we look into U3, a proprietary method of launching applications from a USB key. This would provide a work-around for running Sugar on machines that are running Windows (alas, this accounts for the majority of hardware found in schools). Ben Schwartz pointed out that we could do the same thing using autorun.inf (See http://www.exponetic.com/blog/blog/2006/07/07/autorun-an-executable-from-a-usb-key-in-windows-xp/), launching an instance of Sugar in QEMU. Running Sugar in emulation requires a reasonably fast machine in order to give an acceptable experience. We need to do more testing in this arena, as it is a path of least resistance for teachers and parents who are interested in trying Sugar. 3. Teachers/developers: There was a productive discussion on the IAEP list this week about how to better engage teachers in the Sugar developer community. Rob Costello pointed out that only a small percentage of teachers would participate in the actual development process, building bridges to even that small group would be worthwhile. It was pointed out that the http://sugarlabs.org/go/Patching_Turtle_Art (which is still incomplete) is far from meeting the needs of a teacher (or anyone else new to the community). Bill Kerr wrote up some questions that I tried to answer in the wiki (See http://sugarlabs.org/go/Talk:Patching_Turtle_Art): * Where do you find things (Python files, source code) * Which things do what? How does one know which Python files have to be tweaked? * Who do you communicate with? (Who are the maintainers and how do you content them?) * How do you program more
Re: [sugar] Image Viewer Activity
On Tue, Sep 30, 2008 at 12:19 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: Am 29.09.2008 um 11:46 schrieb Sayamindu Dasgupta: On Mon, Sep 29, 2008 at 11:57 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote: Hello, I was a little annoyed with having to start up Browse to view images, and since I had done a small toy PyGTK based image viewer widget sometime back, I decided to put that in an activity over the weekend. You can download it from http://dev.laptop.org/~sayamindu/bundles/imageviewer/ ImageViewer-1.xo It can zoom and rotate images. However, it cannot put anything in the journal, since a workaround for #8155 would mean eating up a lot of storage space (as I would have to create copies of the images for each journal entry). A screenshot is at http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png The code lives in Git: http://dev.laptop.org/git?p=users/sayamindu/imageviewer-activity;a=tree Comments, patches and brickbats are welcome :-). Thanks, Sayamindu Hey, fantastic, thanks! :-) --Gary P.S. Any hints on changing the default activity that takes charge of a mime type? No clue on how to set the default activity associated with a mimetype :-(. If anyone has any ideas, please let me know :-). /usr/share/sugar/data/mime.defaults - Bert - Ooh - thanks for that :-). I'll try to propose this activity for inclusion into Fructose and if it goes in, I'll try to convince people to change this file ;-). -sdg- -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
On 30 Sep 2008, at 15:58, Sayamindu Dasgupta wrote: On Tue, Sep 30, 2008 at 7:57 PM, Gary C Martin [EMAIL PROTECTED] wrote: P.S. Sayamindu, want an SVG icon to go with it? Or do you have something planned? I was thinking just a rectangular picture frame with a very simple mountain/sun/cloud type thing. Yeah - an SVG icon would be awesome. My inkscape skills are horrible, so I did not dare try to modify the icon of the the helloworld activity ;-). -sdg- Just mock-ups for review, these are not svg format yet (I usually hand code the svg to keep cruft to a minimum). Any strong opinions out there regarding the design? One thing I am on the fence about is inclusion of a spy-glass, hanging over the bottom right of frame. That would say more 'viewer activity' and less 'image file', which is where this is closer to just now. However, adding a spy-glass would make the icon more fussy and require I ditch most of the picture detail (ending up more of a rectangle + spy-glass and maybe corner of a mountain/sun/ something). inline: image-viewer-scratch-work-small.gifinline: image-viewer-scratch-work-medium.gifinline: image-viewer-scratch-work-large.gif Feedback welcome (as I don't see much Sugar related visual design discussed going on around here). --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
Michel Dänzer wrote: On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), EXA does support XShmPutImage(), just not SHM pixmaps. I was remembering the code. As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer being used. Shall I commit a cleanup? Also note that the fbdev driver by default uses a shadow framebuffer in system RAM and only updates the visible screen contents at regular intervals. It might be fairer to compare with Option ShadowFB off, at least assuming the amd driver provides other desirable features the fbdev driver can't provide. Riccardo, could you try that? -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| It's an education project, not a laptop project! ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] rendering test
On Tue, 2008-09-30 at 21:30 +0200, Bernie Innocenti wrote: Michel Dänzer wrote: On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), EXA does support XShmPutImage(), just not SHM pixmaps. I was remembering the code. As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer being used. Shall I commit a cleanup? Also note that the fbdev driver by default uses a shadow framebuffer in system RAM and only updates the visible screen contents at regular intervals. It might be fairer to compare with Option ShadowFB off, at least assuming the amd driver provides other desirable features the fbdev driver can't provide. Riccardo, could you try that? weird, testing with the ShadowFb option off slightly speeds up the test ;P avg time on 5 tries: ~57.5s (it was 62.83s) riccardo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] one response time
Had WikipediaEn-3.xo on a removable storage device. Launched it by clicking in the Journal view for that device. It took about a MINUTE before the pulsing (i.e., activity is being launched) screen was displayed. Otherwise the XO (766) just sat there (in an unchanged Journal view - not even a palette). Except for the blinking of the LED on the storage device, I would not have known that anything was happening. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] another response time
Launched XaoS-2 (on 766). The activity is being launched screen pulsed and pulsed for a couple of minutes. I had definitely concluded that it would *never* launch, and that this was the Sugar launch timeout that kept the screen pulsing -- when suddenly the XaoS activity screen was drawn. It is likely that some people will not have the patience to wait that lng. [How *could* they tell whether the pulsing would end well, or would not end well ?] mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote: A screenshot is at http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png The code lives in Git: http://dev.laptop.org/git?p=users/sayamindu/imageviewer- activity;a=tree Comments, patches and brickbats are welcome :-). No brickbats (or patches), but just wanted to report one (very minor) Image Viewer misbehaviour. I noticed today that if I open an image, and then rename it within Image Viewer, it generates one of those Keep Error warnings about loosing all changes. The new name does actually change correctly. This error seems to crop up on a number of activities so I'm not sure if it's a Sugar bug or some common issue catching out Activity authors. Regards, --Gary P.S. No one seems to have raised any issues yet with the icon sample I posted, so if you're happy with it, and I get no other feedback, I'll turn it into a SVG at end of tomorrow (though I may also try a version with a looking-glass partially over the image frame). ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] why are removable storage devices just an adjunct ?
Applications which I intend to use in the near future I keep resident (Sugar Activities in /home/olpc/Activities, Linux applications on my permanent SD card). Those I access rarely I keep on a removable storage device. Just now was using Journal to access Activity bundles kept on a removable storage device. All I wanted to do was to run them once -- but Journal *installed* (in /home/olpc/Activities) each one that I clicked on. I had not expected that. The XO-1 does not have a lot of nand storage. What interests me is how best to off-load data *and programs* from nand. I had been told that it was possible to run Activities from a removable storage device -- but I now see that in the actual implementation it *still* requires nand to run an off-loaded Activity -- in other words, the removable storage device is just an adjunct, not a repository. There really ought to be a better way to deposit Activities which are not being accessed each week. Sooner rather than later, there simply will not be room in /home/olpc/Activities. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
