Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
Gary C Martin wrote: > Hi Benjamin, > > On 28 Aug 2009, at 03:58, Benjamin M. Schwartz wrote: > >> Bobby Powers wrote: >>> I think having something like: >>> >>> example.activity >>> |-arch/ >>> |-arch/x86/ >>> |-arch/x86/bin/ >>> |-arch/x86/lib/ >>> |-arch/armel/ >>> ... >>> >>> could work. Sugar could set an environmental variable ARCH to the >>> relevant value, and we could have a reference activity_startup.sh >>> which adds the correct lib path to LD_LIBRARY_PATH and launches the >>> appropriate executable (or maybe a flag in activty.info which has >>> sugar do this). This is still somewhat kludgy, but I'm not sure of a >>> better way. >> Which solution we should choose is a technical discussion that >> deserves >> its own thread. I'm personally not enthusiastic about the "fat >> packages" >> approach, in which binaries for many architectures are included in >> one .xo >> bundle, because: > > What would be your recommendation? As a long time Mac user (and > developer) I was/am all for "fat packages" (universal binaries), and > we certainly don't have the ability to compile binaries on demand for > the significant portion of target sugar HW. Activity bundles are a > major plus, from where I'm standing, vs. the traditional ./configure, > make install, and dependancy requirements. > > With my activity author hat on, I've gone out of my way to avoid the > hell of binary blobs, it breaks the whole idea of providing code in > Python source for others to easily edit, modify, learn from. But I > understand (having adopted maintenance of some old projects) that this > has not always been possible for authors (though it woul would always > be my goal when writing code). I am very much with you here: I think writing Activities in pure Python is very valuable to minimize the barrier to entry for software modification, and maximize the incentive to learn a bit of software engineering. Sugar now has a number of officially supported languages: python, eToys/Squeak, HTML+Javascript, and bash/shell, at least, and the benefits of "editability" extend at least somewhat to all of these. When authors ship binary code, not written in one of the above languages, it is either because 1. they are depending on pre-existing software, written in another language, whose presence is not guaranteed by Sugar, or 2. they are writing new software in another language. (or both) These cases seem quite different to me. In particular, we might be able to make use of some existing packages for case 1, whereas no packages yet exist in case 2. Virtually all binaries on Linux are produced by gcc. One way we could resolve our binary issue is to declare gcc to be a "blessed dependency" of Sugar, and then demand that all XO bundles include all their code and dependencies as source files, to be compiled on the target machine. This would essentially resolve the cross-platform problem, in a way that is nicely aligned with Sugar's emphasis on software freedom and hands-on engineering. I also think that the performance overhead would not be totally outrageous. We are not talking about compiling browsers, kernels, GUI toolkits, or X. Those things are already provided, and developers should not duplicate them. The projects being compiled should be relatively small. Unfortunately, the situation is not quite so nice. A few problems: - Pre-existing applications use a variety of build systems, like autotools and cmake. Unless we bless them all, Activity bundles in Case 1 will have to compile the source code for the build system before they can build the project itself. This is not easy for the bundler to get right. - We will need to provide all the headers against which to compile, the -devel packages in many distros. This may require a significant amount of disk space - Different distros have different library versions. Depending on how we phrase our library version guarantees, we could find that Activities need to ship an obscenely deep dependency tree to be safe. - Building large projects is not always easy. Sometimes complicated, fragile, poorly documented steps are required. I am not sure how to resolve all these problems. My favorite solution so far most nearly resembles Gentoo's Portage. Portage is a sort of "dependency-resolving build management system" that processes "ebuilds" which are shell scripts that control package compilation. Portage also supports precompiled binary packages if they are available, as an optimization. "Gentoo Prefix" provides a set of several thousand ebuilds that can be processed, installed, and run entirely without root privileges. I imagine a system in which For case 1: Activity bundles are required to include source tarballs and ebuilds for any dependencies. Upon installation, these dependencies will be installed from binary packages if matching binaries can be found. Otherwise, they will be compiled from the provided source, using the provided ebuild. For case
[Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
Hi Benjamin, On 28 Aug 2009, at 03:58, Benjamin M. Schwartz wrote: > Bobby Powers wrote: >> I think having something like: >> >> example.activity >> |-arch/ >> |-arch/x86/ >> |-arch/x86/bin/ >> |-arch/x86/lib/ >> |-arch/armel/ >> ... >> >> could work. Sugar could set an environmental variable ARCH to the >> relevant value, and we could have a reference activity_startup.sh >> which adds the correct lib path to LD_LIBRARY_PATH and launches the >> appropriate executable (or maybe a flag in activty.info which has >> sugar do this). This is still somewhat kludgy, but I'm not sure of a >> better way. > > Which solution we should choose is a technical discussion that > deserves > its own thread. I'm personally not enthusiastic about the "fat > packages" > approach, in which binaries for many architectures are included in > one .xo > bundle, because: What would be your recommendation? As a long time Mac user (and developer) I was/am all for "fat packages" (universal binaries), and we certainly don't have the ability to compile binaries on demand for the significant portion of target sugar HW. Activity bundles are a major plus, from where I'm standing, vs. the traditional ./configure, make install, and dependancy requirements. With my activity author hat on, I've gone out of my way to avoid the hell of binary blobs, it breaks the whole idea of providing code in Python source for others to easily edit, modify, learn from. But I understand (having adopted maintenance of some old projects) that this has not always been possible for authors (though it woul would always be my goal when writing code). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
Bobby Powers wrote: > I think having something like: > > example.activity > |-arch/ > |-arch/x86/ > |-arch/x86/bin/ > |-arch/x86/lib/ > |-arch/armel/ > ... > > could work. Sugar could set an environmental variable ARCH to the > relevant value, and we could have a reference activity_startup.sh > which adds the correct lib path to LD_LIBRARY_PATH and launches the > appropriate executable (or maybe a flag in activty.info which has > sugar do this). This is still somewhat kludgy, but I'm not sure of a > better way. Which solution we should choose is a technical discussion that deserves its own thread. I'm personally not enthusiastic about the "fat packages" approach, in which binaries for many architectures are included in one .xo bundle, because: 1. It wastes space, by carrying around duplicate copies. This gets even worse for >2 architectures, and even 32-bit and 64-bit x86 might need to be treated as separate architectures. 2. It's not future-proof. Packages that work on ARM and x86 will be broken again if we try to support MIPS (like the Lemote laptops, Free and perfect for Sugar), or maybe even Sparc or Power (massively SMT chips, perfect for LTSP). 3. It won't happen. Cross-compiling libraries is tremendously difficult, so Activity developers won't do it. They'll just get it working on their platform and ship it. 4. It's unreliable. There is no good way to produce binaries that are guaranteed to work on both 32-bit x86 Fedora 9 and 32-bit x86 Fedora 10. Changes between versions can break binary compatibility. Between different distros it's even worse. The Pippy activity recently experienced exactly this problem due to the included Box2D binary library. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
I think having something like: example.activity |-arch/ |-arch/x86/ |-arch/x86/bin/ |-arch/x86/lib/ |-arch/armel/ ... could work. Sugar could set an environmental variable ARCH to the relevant value, and we could have a reference activity_startup.sh which adds the correct lib path to LD_LIBRARY_PATH and launches the appropriate executable (or maybe a flag in activty.info which has sugar do this). This is still somewhat kludgy, but I'm not sure of a better way. Bobby On Thu, Aug 27, 2009 at 9:07 PM, Edward Cherlin wrote: > > We're going to do all of this for the XO-2 (ARM, dual haptic > multitouch screens), and as with trees, the sooner we plant the > better. > > Can we get a virtual ARM running on a Linux X86 system? It seems > likely. QEMU has some form of ARM emulation. Also, > > https://wiki.cse.buffalo.edu/services/content/virtualmhz-arm-vm-arm > The VirtualMHz for ARM (VM-arm) > > Virtera is shipping a free tool that can simulate a 217MHz ARM > processor and embedded Linux system in real-time. The VirtualMHz for > ARM (VM-arm) uses dynamic instruction compilation, rather than the > interpretive simulation techniques used by competitors. > > Has anybody seen it? Tried it? Liked it? > > On Thu, Aug 27, 2009 at 1:11 PM, Ton van Overbeek wrote: > > There have been demos to run Sugar on a Nokia N810 (ARM based) > > starting from the Debian Armel packages. > > Probably a good idea to check with the Debian folks. Debian supports > > multiple architectures for their > > distributions. > > I do have a N810 myself, but I will be very busy the next few months > > (relocating back to Europe), > > so I will not have much time to contribute (and yes, touchscreen, > > stylus, virtual keyboard, etc. are > > problematic with Sugar). > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > > -- > Edward Mokurai Cherlin > Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name, and > Children are > my nation. The Cosmos is my dwelling place, the Truth my destination. > http://earthtreasury.org/ > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Digest addendum
I forgot to mention: We'll be holding the Oversight Board election in mid-September. If you are not already a member, please send email to memb...@suagrlabs.org by September 5 in order to be eligible to vote. 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
Re: [Sugar-devel] [karma] early draft of karma presentation
> > You could send strings for function blocks that can later be eval-ed. > But the eval itself might slow things down a lot. > yep, also it's not recommended ( http://javascript.crockford.com/code.html, look for "eval is evil") Some browsers serialise the JSON to > string and then re-eval it, others send the actual object. > afaik, ff takes the message and then converts it to JSON.. 2009/8/26 Lucian Branescu > You could send strings for function blocks that can later be eval-ed. > But the eval itself might slow things down a lot. You can also send > JSON objects between workers. Some browsers serialise the JSON to > string and then re-eval it, others send the actual object. > > About shared data, try to stay away from it anyway. Message passing is > desirable most of the time. > > 2009/8/25 Felipe López Toledo : > > Hi > > in my early post I talked about > > canvas vs SVG (slide #28) > > why not processingJS? (slide #28) > > here some technical stuff: > > --- > > Browser Optimization (slide #29) > > Karma lessons must run under the XO-1. > > Default browser: Browse ( based on Gecko ) > > Experimental: Surf ( based on webkit ) > > No problem with html elements (div, img, ...) > > What about canvas content? > > Under a normal browser clearing and redrawing the canvas objects may not > be > > a problem, but remember that the XO has not that kind of normal > resources. > > We must use them efficiently. > > If we have no option, it's preferable to spend cpu than spend memory. > > We emphasize rendering speed over quality > > image-rendering / firefox 3.6 alpha > > webkit has nothing > > Quadrilaterals (http://karma.sugarlabs.org/quadrilaterals/) > > how does it work? > > 2 canvases > > the first for temporal drawing of the current line > > cleared and re drawn when "mousemove" > > the second has the drawn polygon, background, etc.. > > Quadrilaterals under Browse has a severe lag problem (unusable) > > Quadrilaterals under Surf works nice > > Surf-106 is faster than Browse-102, should we use Webkit or Gecko? > > -- > > Web Workers (slide #30) > > We tried to use web workers to handle animations: an animation core. > > The animation core would be running as a worker thread: doing the > neccesary > > calculations for the animated objects and sending messages to the root > > document to manipulate (update) the neccesary html elements (canvas...) > > We try to combine actions with predictable behaviour. > > Problems: > > it's not possible to send functions as worker messages, so, it's hard to > use > > callbacks. > > how to share memory (variables) between the root document and the worker > > thread without copying that data? > > -- > > 2009/8/21 Christoph Derndorfer > >> > >> Hey guys, > >> I basically agree with the points raised here so far and have a couple > to > >> add myself: > >> slide #11: I would also mentioned that you had tried eToys/Squeak > >> slide #24: I'm not sure we agreed on each lesson having to include a > >> tutorial and an exercise. Of course this is a good goal but the question > is > >> whether we should really make that a requirement? > >> slide #32: "i81n";-) > >> slide #43: add link to Karma blog at http://karmaproject.wordpress.com/ > , > >> add at least one e-mail address for direct contact, add link to Sugar > >> mailing-list (http://lists.sugarlabs.org/listinfo/sugar-devel) > >> That's all I can think of for now... > >> Christoph > >> 2009/8/21 Felipe López Toledo > >>> > >>> Hi guys > >>> > >>> Joshua, Bryan has talked Christoph and me about you, thanks for writing > >>> :) > >>> > * I would update the slide "Nobody Wants to Help", to something like, > "Flash is a poor longterm solution." I would drop the claim "Flash > Devs > don't like to share." I would > - Despite the great work of the free software community on projects > like Gnash and the GameSWF library, there is very little in terms of > sharing > and collaboration of free software Flash projects. > >>> > >>> +1 > > - There is no free software Flash development tool, > >>> > >>> mmm, I remember MTASC http://www.mtasc.org/ > > instead almost all Flash development is done through the proprietary > software created by Macromedia. > >>> > >>> +1 > >>> > >>> Bryan, really good draft, here some initial feedback: > >>> > >>> 1. SVG vs canvas > >>> I used RaphalJS (http://raphaeljs.com/) demos to test SVG animatios > using > >>> Browse and Surf, > >>> results: > >>> under surf: the XO crashed several times :( > >>> under Browse: the animations look really good, but the performance is > >>> really bad (you will get a several lag when clicking something, etc...) > >>> > >>> canvas is low level so, canvas drawing is faster than SVG drawing. > >>> about manipulation, well, It's really easy to manipulate SVG Objects > >>> (everything you draw is an object) but canvas is just a box where you > can > >>> draw, Karma provides (some of) that objects. > >>> > >>> 2. why not p
[Sugar-devel] Sugar Digest 2009-08-27
=== Sugar Digest === You are very right that if a person doesn't have firmly in mind just what science is really about, they can confuse a representation of ideas gotten by scientific means with science itself. – Alan Kay 1. The discussion about the merits and pitfalls of the use of simulation in science education continued this week (See [http://lists.sugarlabs.org/archive/iaep/2009-August/007722.html]). 2. María del Pilar Sáenz led a deployment meeting this week (See [http://meeting.sugarlabs.org/sugar-meeting.log.20090819_1008.html]). We reviewed the status of Sugar deployments, discussed the most pressing needs from deployments, and alternative communication channels that might result in more feedback from the field. Another discussion on the IAEP list [http://lists.sugarlabs.org/archive/iaep/2009-August/007842.html] is an indication of just how passionate the community is about being responsive to the needs of deployments. 3. Bernie Innocenti and I spent a day in Barre VT with Paul Flint, Kevin Cole, Nicco Eneidi, Colin Applegate, et al. to discuss the role Sugar might play in various education initiatives in the region. Despite too much driving in pouring rain, it was a fun, productive session. (Bernie helped Colin get up to speed on packaging for Ubuntu (Colin has subsequently build Sugar 0.86 for Jaunty) and did some debugging of Turtle Art while engaging in discussion with some teachers. One provocative question that was raised: What is the advantage of a "platform" as opposed to a bunch of cool applications? There are many cool applications out there and commercial (e.g., kidzui, which caters to parents who want someone else to worry about what Internet content is appropriate for their children) and non-commercial (e.g., Curriki, a place where teachers can pick and chose applications and content that meet specific curricula demands) collections. What is the advantage of the Sugar approach? We can sing the praises of many aspects of the Sugar platform—the Journal, the collaboration model, integrated view source, etc.—but I think it ultimately comes down the way in which these features enhance the ability to bring multiple learners together around a collection of activities to engage in authentic investigations. This is a potential that is not yet fully realized, but having spent time this summer watching children move fluidly across multiple activities to, for example, build a memory game, is seeing Sugar at its best. 4. The recent FSF campaign condemning the use of Windows 7 in education (See http://windows7sins.org/) imputes OLPC in complicity with Microsoft. It is disappointing that the FSF is not making any constructive arguments in favor of free software alternatives to Windows such as Sugar on GNU/Linux, which is currently shipped on every machine distributed by OLPC. ===Help wanted/help received=== 5. Google Summer of Code 2009 has official come to a close. We were fortunate to have five intern/mentor pairs, each of whom had a productive two months. Congratulations to Lucian Branescu, Felipe López Toledo, Sacha Silbe, Ben Schwartz, Vamsi Krishna Davuluri, Bryan Berry, Andres Ambrois, and Assim Deodia. Special thanks to Jameson Quinn for organizing the program for Sugar Labs and to Google for their generosity. ===In the community=== 6. One result of Pilar's revitalization of the Deployment Team is that we are being more explicit in our targeting of feedback from deployments. Joshua Pritikin reports: :Our school [http://wiki.laptop.org/go/OLPC_India/Nashik] has some 200 students. Counter to OLPC best practices, we have 33 XO laptops using the "computer lab" model. We would like to move to child ownership, but we haven't found enough funding to do that. :This year we issued USB keys to the students. USB keys are not as easy to use as the integrated journal, but at least some kids are successful saving their work. :The teachers are mainly impressed by Moodle. To teachers who had never used a computer, being able to create an online quiz is something of a revelation. I would like to place more emphasis on Turtle Art and Etoys, but teachers don't see the point yet. Children are mostly left to explore the laptops on their own when they have free time. :I have no idea how much the students are learning with the laptops. At this point, everything is about appearances. For example, we convinced parents to pay double what they paid last year by withholding access to the laptops until they paid up. In many cases, the kids begged the parents to use the laptops. We managed to raise our fee to $100 per year. :Indian electrical wiring is notorious. I am particularly proud of our power distribution solution (see attached photos). Early on, there was talk of an http://wiki.laptop.org/go/Peripherals/XOctoPlug. We made something similar. :The lack of child ownership has an upside. It is fairly easy to test new SoaS builds without worrying about backups or deleting a child's work. We are working
Re: [Sugar-devel] Ad-hoc network identification badge
On 08/27/2009 10:42 PM, Gary C Martin wrote: > Quick ping, > > Do we need something like an emblem-buddy.svg for ad-hoc network icons > (e.g. an XO icon used in same way as the star and lock icon are used > to badge AP icons)? Sorry couldn't find a trac ticket or the right ML > thread. > > Regards, > --Gary Yeah, I think we settled on a badged AP icon. If you have something in mind - please share it with us ;p Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
We're going to do all of this for the XO-2 (ARM, dual haptic multitouch screens), and as with trees, the sooner we plant the better. Can we get a virtual ARM running on a Linux X86 system? It seems likely. QEMU has some form of ARM emulation. Also, https://wiki.cse.buffalo.edu/services/content/virtualmhz-arm-vm-arm The VirtualMHz for ARM (VM-arm) Virtera is shipping a free tool that can simulate a 217MHz ARM processor and embedded Linux system in real-time. The VirtualMHz for ARM (VM-arm) uses dynamic instruction compilation, rather than the interpretive simulation techniques used by competitors. Has anybody seen it? Tried it? Liked it? On Thu, Aug 27, 2009 at 1:11 PM, Ton van Overbeek wrote: > There have been demos to run Sugar on a Nokia N810 (ARM based) > starting from the Debian Armel packages. > Probably a good idea to check with the Debian folks. Debian supports > multiple architectures for their > distributions. > I do have a N810 myself, but I will be very busy the next few months > (relocating back to Europe), > so I will not have much time to contribute (and yes, touchscreen, > stylus, virtual keyboard, etc. are > problematic with Sugar). > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Edward Mokurai Cherlin Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://earthtreasury.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Ad-hoc network identification badge
Quick ping, Do we need something like an emblem-buddy.svg for ad-hoc network icons (e.g. an XO icon used in same way as the star and lock icon are used to badge AP icons)? Sorry couldn't find a trac ticket or the right ML thread. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
There have been demos to run Sugar on a Nokia N810 (ARM based) starting from the Debian Armel packages. Probably a good idea to check with the Debian folks. Debian supports multiple architectures for their distributions. I do have a N810 myself, but I will be very busy the next few months (relocating back to Europe), so I will not have much time to contribute (and yes, touchscreen, stylus, virtual keyboard, etc. are problematic with Sugar). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
David Farning wrote: > On Thu, Aug 27, 2009 at 2:48 PM, Benjamin M. > Schwartz wrote: >> 1. Many Activities contain Fedora 9 x86-32 binary code, and just won't run >> on other platforms. We need to reach a consensus on a multiplatform >> standard for Activities, and then implement it. The options for such a >> standard are obvious enough. The hard part is to choose the right one, >> implement it, and make it stick. > > Are you up for championing this? Abstracting out architecture > dependant code is painful yet very necessary process. I would be happy to push this, and provide technical assistance, but all the computers I own are x86-32. Someone with multiplatform experience would be a better choice ... especially someone who can provide motivation to self and others by saying "this doesn't work on my computer". --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The ARM is near
On Thu, Aug 27, 2009 at 2:48 PM, Benjamin M. Schwartz wrote: > Sharp PC-Z1: > http://www.engadget.com/2009/08/27/sharps-5-inch-pc-z1-netwalker-honors-the-zaurus-legacy/ > > Nokia N900: > http://maemo.nokia.com/n900/ > > A new wave of devices is approaching. They have touchscreens, but they > also have qwerty keyboards. They have long battery life, and built-in > wireless networking. They are lightweight, and sized well for children. > They use Cortex A8 processors based on a core licensed from ARM. They are > designed to allow the user to replace the operating system as she chooses, > but they only support one kernel: Linux. > > In my view, these devices are a natural target for Sugar, despite lacking > full-size keyboards ideal for programming. They are ready for us. In > fact, the PC-Z1 ships with Ubuntu preinstalled. > > Unfortunately, we are not ready for them. Specifically, we have two major > issues to solve: > > 1. Many Activities contain Fedora 9 x86-32 binary code, and just won't run > on other platforms. We need to reach a consensus on a multiplatform > standard for Activities, and then implement it. The options for such a > standard are obvious enough. The hard part is to choose the right one, > implement it, and make it stick. Are you up for championing this? Abstracting out architecture dependant code is painful yet very necessary process. david > 2. We have not done the work needed to make our interface work well on a > touch-screen, with or without a stylus. As touch-screens become more > common, we risk being left behind. > > If you have the hardware to test these features, and the interest to make > them happen, I urge you to take a lead. Solving these problems is an > important contribution that you can make. > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] The ARM is near
Sharp PC-Z1: http://www.engadget.com/2009/08/27/sharps-5-inch-pc-z1-netwalker-honors-the-zaurus-legacy/ Nokia N900: http://maemo.nokia.com/n900/ A new wave of devices is approaching. They have touchscreens, but they also have qwerty keyboards. They have long battery life, and built-in wireless networking. They are lightweight, and sized well for children. They use Cortex A8 processors based on a core licensed from ARM. They are designed to allow the user to replace the operating system as she chooses, but they only support one kernel: Linux. In my view, these devices are a natural target for Sugar, despite lacking full-size keyboards ideal for programming. They are ready for us. In fact, the PC-Z1 ships with Ubuntu preinstalled. Unfortunately, we are not ready for them. Specifically, we have two major issues to solve: 1. Many Activities contain Fedora 9 x86-32 binary code, and just won't run on other platforms. We need to reach a consensus on a multiplatform standard for Activities, and then implement it. The options for such a standard are obvious enough. The hard part is to choose the right one, implement it, and make it stick. 2. We have not done the work needed to make our interface work well on a touch-screen, with or without a stylus. As touch-screens become more common, we risk being left behind. If you have the hardware to test these features, and the interest to make them happen, I urge you to take a lead. Solving these problems is an important contribution that you can make. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Physics-3
w00t! This arrives, by the way, perfectly in time for the beta. :) --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] erasing the journal and config
On Thu, Aug 27, 2009 at 11:43 AM, Sameer Verma wrote: > On Thu, Aug 27, 2009 at 8:17 AM, Daniel Drake wrote: >> 2009/8/27 Sameer Verma : >>> I posed this question on OLPC Support Gang earlier and got responses >>> that its not possible to do so under bitfrost and rainbow. >>> >>> === >>> "Hello everybody, >>> >>> We have a lending library at SFSU, ready to go, but we need to have a >>> way to erase the config and journal every time the XO comes back from >>> a borrower. The SFSU library staff have made it very clear that they >>> don't want the process to be "open the terminal and run a script". An >>> activity (say, Erase) would be quite desirable. >> >> In my opinion, this is silly. Teach them how to run a script, teach >> them how to reflash or tell them to stop being difficult. >> >> As for the borrowers end - this is sillier. What are you expecting the >> borrowers to actually do with their XOs? It's for generating >> contributions to the community, right? >> >> Daniel >> > > I'm dealing with our library. We could have gone the route of a > student group handling this, but logistically, it made more sense for > the library to do this. They are very strict about privacy of patrons > (and rightly so). Privacy is privacy. It does not matter what > borrowers do with their XOs. The library will not even tell me *who* > borrows the laptops. We are going to provide a laminated card with a > URL to provide structured feedback. So, we can't look up people who > borrow the XOs, but we can hope to get feedback and contribution > voluntarily from the borrowers. > > I'm going to stick with the "run a script" routine for now. The process of creating an activity and a control panel plug-in are nearly identical. The control panel is were system admin _should_ occur and plug-ins provide a nice framework for developing guis. david > cheers, > Sameer > -- > Dr. Sameer Verma, Ph.D. > Associate Professor, Information Systems > Director, Center for Business Solutions > San Francisco State University > http://verma.sfsu.edu/ > http://cbs.sfsu.edu/ > http://is.sfsu.edu/ > ___ > Devel mailing list > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Physics-3
Activity Homepage: http://activities.sugarlabs.org/addon/4193 Sugar Platform: from 0.82 to 0.86 Download Now: http://activities.sugarlabs.org/downloads/version/29221 Release notes: * Journal state saving now supported! * MIME type support added so Physics Journal entries can be sent to others (application/x-physics-activity) * Fixed Activity title text input so you can name your work correctly (olpcgames glitch) * New Grab toolbar icon (hand) * New Polygon toolbar icon (irregular polygon shape) * Cleaned up toolbar order * Single click behaviour so that Circle, Triangle, and Box tool add default sized shapes * Single click behaviour for all tools, so that a subsequent single click creates a clone of the last shape made with that tool. * Erase tool now erases (one by one) pins/joints/motors from a shape, before finally removing the shape itself. * Using +key for all keyboard shortcuts (was causing PyGame input focus issues when typing a title) * Using the Sugar standard arrow cursor for the PyGame canvas (well, a fake one) * Cleaned up the Activity icon * Upgraded to new version of Elements 0.13 * Upgraded to new version of Box2D * Picked up Pootle (July 3rd) translations Many thanks to Asaf Paris Mandoki, and Brian Jordan for all their hard work! Reviewer comments: Trusted activity Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GREAT NEWS! Fwd: Dear Morgs,
On Thu, Aug 27, 2009 at 07:29:43PM +0200, Jonas Smedegaard wrote: On Thu, Aug 27, 2009 at 12:02:12PM -0400, Colin Applegate wrote: I have successfully built my first Sugar 0.86 package! Congratulations. Do you plan to join the Debian team as Morgan suggested below? Sorry - I was too fast: I now see your request for membership. Welcome aboard to the cross-distro deb-packaging team at Alioth! :-D - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] erasing the journal and config
On Thu, Aug 27, 2009 at 8:17 AM, Daniel Drake wrote: > 2009/8/27 Sameer Verma : >> We have a lending library at SFSU, ready to go, but we need to have a >> way to erase the config and journal every time the XO comes back from >> a borrower. > In my opinion, this is silly. Teach them how to run a script, teach > them how to reflash or tell them to stop being difficult. > > As for the borrowers end - this is sillier. What are you expecting the > borrowers to actually do with their XOs? It's for generating > contributions to the community, right? It is a fundamental principle of Customer Relations that you don't tell users what they want to do with your product. If people have a security concern, you deal with it or risk losing them and their friends etc. permanently. If you need to be convinced, ask any librarian about National Security letters demanding a patron's reading list. You will get an earful. > Daniel > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Edward Mokurai Cherlin Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://earthtreasury.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GREAT NEWS! Fwd: Dear Morgs,
On Thu, Aug 27, 2009 at 12:02:12PM -0400, Colin Applegate wrote: I have successfully built my first Sugar 0.86 package! Congratulations. Do you plan to join the Debian team as Morgan suggested below? Also you should join the debian packaging team - we tried to diverge from their packaging for Jaunty as they were lagging, but they have caught up and done good work. Anyone can join the team and work on packaging, you don't need to be a DD. Kind regards, - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] erasing the journal and config
On Thu, Aug 27, 2009 at 8:17 AM, Daniel Drake wrote: > 2009/8/27 Sameer Verma : >> I posed this question on OLPC Support Gang earlier and got responses >> that its not possible to do so under bitfrost and rainbow. >> >> === >> "Hello everybody, >> >> We have a lending library at SFSU, ready to go, but we need to have a >> way to erase the config and journal every time the XO comes back from >> a borrower. The SFSU library staff have made it very clear that they >> don't want the process to be "open the terminal and run a script". An >> activity (say, Erase) would be quite desirable. > > In my opinion, this is silly. Teach them how to run a script, teach > them how to reflash or tell them to stop being difficult. > > As for the borrowers end - this is sillier. What are you expecting the > borrowers to actually do with their XOs? It's for generating > contributions to the community, right? > > Daniel > I'm dealing with our library. We could have gone the route of a student group handling this, but logistically, it made more sense for the library to do this. They are very strict about privacy of patrons (and rightly so). Privacy is privacy. It does not matter what borrowers do with their XOs. The library will not even tell me *who* borrows the laptops. We are going to provide a laminated card with a URL to provide structured feedback. So, we can't look up people who borrow the XOs, but we can hope to get feedback and contribution voluntarily from the borrowers. I'm going to stick with the "run a script" routine for now. cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor, Information Systems Director, Center for Business Solutions San Francisco State University http://verma.sfsu.edu/ http://cbs.sfsu.edu/ http://is.sfsu.edu/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] buildslave2.sugarlabs.org unreachable
El Wed, 26-08-2009 a las 11:41 +0200, Tomeu Vizoso escribió: > On Wed, Aug 26, 2009 at 11:29, Tomeu Vizoso wrote: > > On Wed, Aug 26, 2009 at 11:24, Sascha > > Silbe wrote: > >> Nop, but it hasn't been updated lately anyway because we now have > >> buildslave-fedora-11-32bit. Is there a reason you're still using the old > >> one? Should we tell the prgmr.com people that they can take those machines down now and thank them for their support? Or can we figure out another use for them? They're pretty fast VMs, and the only big restriction was that we couldn't use too much bandwidth on them. The console and management interface was also a bit shaky. > Any instructions? Couldn't find it in the wiki. I will need root > access as well to set up a new mock config file and maybe install > packages. Sascha, could you please document the build slaves somewhere in the wiki? It would be great if we could switch to having separate wiki pages for each virtual or physical system (the OLPC VIG uses the naming convention Machine:Foo, Machine:Bar... we could use Machine/Foo, Machine/Bar instead. Having a common template would be terrific. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GREAT NEWS! Fwd: Dear Morgs,
On Thu, Aug 27, 2009 at 18:02, Colin Applegate wrote: > I have successfully built my first Sugar 0.86 package! > > My goal is to have 32-bit and 64-bit versions of the package up at > http://www.launchpad.net/sugar-jaunty by the end of today! > > Documentation is at http://docbox.flint.com:8081/maple/msdevelop Great! Are you aiming to have 0.86 distributed as part of Karmic? Regards, Tomeu > -- > Colin Applegate > -Chief Executive Officer, Applegate Telecommunications > -Chief Technology Officer, Barre Open Systems Institute > --President, Applegate Consulting > "Fixing your computers since 1995." > (703) 835 - 4921 > http://colinapplegate.com > > “To laugh often and much; to win the respect of intelligent people and > the affection of children...to leave the world a better place...to > know even one life has breathed easier because you have lived. This is > to have succeeded.” > Ralph Waldo Emerson > > "Kindness is a language which the deaf can hear and the blind can see." > Mark Twain > > "Love all, trust a few, do wrong to none." > William Shakespeare > > -- Forwarded message -- > From: Morgan Collett > Date: Mon, Aug 24, 2009 at 4:48 AM > Subject: Re: Dear Morgs, > To: Colin Applegate > > > Hi Colin > > On Sat, Aug 22, 2009 at 21:18, Colin Applegate > wrote: >> Greetings, >> >> Colin Applegate here. I am interested in being the universe maintainer >> for Sugar for Ubuntu's universe. I'm in the process of being blessed >> into the MOTU team. Bernie said to talk to you about this. Please >> advise :-) > > Awesome. I unfortunately wasn't close to being a MOTU, so it was > painful trying to get updates sponsored, and then things changed and I > didn't have time any more for packaging. > > Join the ubuntu-sugarteam LP team: > https://launchpad.net/~sugarteam/+members - ask dfarning to add you as > an admin which he will gladly do I'm sure. > > There's also some wiki stuff at https://wiki.ubuntu.com/SugarTeam - > feel free to modify in any way as it's probably very out of date. > There's a mailing list mentioned there. David Farning should have the > admin password for mailman if you want it. > > Also you should join the debian packaging team - we tried to diverge > from their packaging for Jaunty as they were lagging, but they have > caught up and done good work. Anyone can join the team and work on > packaging, you don't need to be a DD. > > Regards > Morgan > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] GREAT NEWS! Fwd: Dear Morgs,
I have successfully built my first Sugar 0.86 package! My goal is to have 32-bit and 64-bit versions of the package up at http://www.launchpad.net/sugar-jaunty by the end of today! Documentation is at http://docbox.flint.com:8081/maple/msdevelop -- Colin Applegate -Chief Executive Officer, Applegate Telecommunications -Chief Technology Officer, Barre Open Systems Institute --President, Applegate Consulting "Fixing your computers since 1995." (703) 835 - 4921 http://colinapplegate.com “To laugh often and much; to win the respect of intelligent people and the affection of children...to leave the world a better place...to know even one life has breathed easier because you have lived. This is to have succeeded.” Ralph Waldo Emerson "Kindness is a language which the deaf can hear and the blind can see." Mark Twain "Love all, trust a few, do wrong to none." William Shakespeare -- Forwarded message -- From: Morgan Collett Date: Mon, Aug 24, 2009 at 4:48 AM Subject: Re: Dear Morgs, To: Colin Applegate Hi Colin On Sat, Aug 22, 2009 at 21:18, Colin Applegate wrote: > Greetings, > > Colin Applegate here. I am interested in being the universe maintainer > for Sugar for Ubuntu's universe. I'm in the process of being blessed > into the MOTU team. Bernie said to talk to you about this. Please > advise :-) Awesome. I unfortunately wasn't close to being a MOTU, so it was painful trying to get updates sponsored, and then things changed and I didn't have time any more for packaging. Join the ubuntu-sugarteam LP team: https://launchpad.net/~sugarteam/+members - ask dfarning to add you as an admin which he will gladly do I'm sure. There's also some wiki stuff at https://wiki.ubuntu.com/SugarTeam - feel free to modify in any way as it's probably very out of date. There's a mailing list mentioned there. David Farning should have the admin password for mailman if you want it. Also you should join the debian packaging team - we tried to diverge from their packaging for Jaunty as they were lagging, but they have caught up and done good work. Anyone can join the team and work on packaging, you don't need to be a DD. Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New F11 for the XO-1 Build 6
On Thu, Aug 27, 2009 at 08:59:28AM -0400, Paul Fox wrote: > to gather a bit more data: > > > - Alt-left, Alt-right, Ctrl-Alt-F1, Ctrl-Alt-F2, Ctrl-Alt-F3, etc do not > > get me to a terminal. Ctrl-Alt-Erase does nothing. > > when the splash screen comes up, can you get it to go away (and > keep the laptop from suspending) by touching the touchpad, or > another keypad key? Yes, that works. The moment the white screen goes away, the laptop starts responding to Alt-left, Alt-right, etc. I can switch to other VTs. However, the video mode is totally borked. I can't read anything. I can type "ls" and see roughly the expected number of pixels move, but I can't see anything remotely resembling text. I guess OLPC doesn't have kernel mode setting? Is there some way to reset the video mode? I might be able to login and type stuff if I know what to type. > that will confirm that user input is making at least as far as > olpc-kbdshim. > > have you tried using an external USB keyboard when booting? Did not try yet. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)
On Thu, Aug 27, 2009 at 16:30, Jim Simmons wrote: > Tomeu, > > What you're saying seems to contradict what others have told me. I > have three places I run Sugar: I must have explained myself badly because what you say below matches my knowledge. Perhaps I should have been more explicitly that I was talking about the Journal and not about the DS? Regards, Tomeu > 1). My XO, running .82. Files on removable media are listed using > the datastore API as if they were Journal entries. > > 2). A linux box running Fedora 10, using the Sugar environment that > ships with it which is a buggier version of what I have on my XO and > does pretty much the same thing. I had to remove sorting in my > datastore query because this was broken in Fedora 10. > > 3). Another Linux box running Fedora 11, with the .84 Sugar > environment that ships with it. With this one the datastore API I was > using does not list files on thumb drives. The files are visible in > the Journal activity and probably in the ObjectChooser, but cannot be > retrieved using the datastore API. Several people were of the opinion > that the datastore API in .84 only deals with the Journal proper and I > would have to use POSIX commands to list out files on thumb drives. > That is what I am planning to do. > > I haven't tried this on SoaS lately, so I don't know how this might > work on the latest .84. > > James Simmons > > > On Thu, Aug 27, 2009 at 4:30 AM, Tomeu Vizoso wrote: >> On Wed, Aug 26, 2009 at 17:09, Jim Simmons wrote: >>> Eben, >>> >>> I have given some thought to how I would implement getting image files >>> from removable media and I think I have a workable plan. Before I >>> describe it I'd like to confess that it is *not* true that .84 code >>> will show objects on the root directory of a thumb drive. It won't >>> show *anything* on a thumb drive, as some of you have pointed out. >>> .82 shows every file whether it is on a thumb drive or in the Journal. >>> It is shown as a flat list with no way to tell what came from where. >> >> 0.84 should display all files in the thumb drive in the same flat >> view, if it doesn't is because there's a bug somewhere. >> >>> What I think I might do is emulate this behavior in .84. Python has >>> an os.walk() function that will list out all the files within a >>> subdirectory. I was thinking that after I load the table with Journal >>> objects I could do the os.walk() for the directory /media, which is >>> where all the removable media seems to get mounted. In my table model >>> I would store the filename and a wrapper class for a Journal object. >>> If there is an actual Journal object in there it would call the object >>> to get a path to the image file in the Journal. If not, it would >>> simply get a real path to a file on a removable device. >> >> This is very close to what should be happening in 0.84. >> >>> I would not check for mounts, etc. Instead, my Activity has a Refresh >>> button which reloads everything. The user would know when he needs to >>> use it. >>> >>> I might put some sort of icon in the table rows so the user knows >>> which entries are from the Journal and which are from thumb drives, >>> etc. >>> >>> I suppose the ObjectChooser should be improved as much as possible, >>> but I doubt I'll ever use it myself. If you want to load only one >>> file into an Activity you could just as easily restore the file from >>> the Journal. If you need to load more than one file having a modal >>> dialog pop up each time just slows you down. >> >> Agreed, multiple selections would help there I guess. >> >> Regards, >> >> Tomeu >> >>> James Simmons > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] erasing the journal and config
> Luke Faraone wrote: > James Cameron wrote: > >> I've tested this method only on unlocked laptops. For locked laptops >> some similar method might be used. > > For locked laptops you would *need* to get a developer key, or have OLPC > sign the file. The latter won't happen. OFW's recently-added multi-key support: http://wiki.laptop.org/go/Firmware_security#Multiple-Key_Support has been used by several deployments (including Uruguay and Paraguay) who might be interested in producing a "wipe power". A scheme similar to the activation lease generation scheme could also be used to rate-limit how quickly such a power could be invoked. Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] erasing the journal and config
2009/8/27 Sameer Verma : > I posed this question on OLPC Support Gang earlier and got responses > that its not possible to do so under bitfrost and rainbow. > > === > "Hello everybody, > > We have a lending library at SFSU, ready to go, but we need to have a > way to erase the config and journal every time the XO comes back from > a borrower. The SFSU library staff have made it very clear that they > don't want the process to be "open the terminal and run a script". An > activity (say, Erase) would be quite desirable. In my opinion, this is silly. Teach them how to run a script, teach them how to reflash or tell them to stop being difficult. As for the borrowers end - this is sillier. What are you expecting the borrowers to actually do with their XOs? It's for generating contributions to the community, right? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] erasing the journal and config
On Thu, Aug 27, 2009 at 04:52, James Cameron wrote: > I've tested this method only on unlocked laptops. For locked laptops > some similar method might be used. For locked laptops you would *need* to get a developer key, or have OLPC sign the file. The latter won't happen. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)
Tomeu, What you're saying seems to contradict what others have told me. I have three places I run Sugar: 1). My XO, running .82. Files on removable media are listed using the datastore API as if they were Journal entries. 2). A linux box running Fedora 10, using the Sugar environment that ships with it which is a buggier version of what I have on my XO and does pretty much the same thing. I had to remove sorting in my datastore query because this was broken in Fedora 10. 3). Another Linux box running Fedora 11, with the .84 Sugar environment that ships with it. With this one the datastore API I was using does not list files on thumb drives. The files are visible in the Journal activity and probably in the ObjectChooser, but cannot be retrieved using the datastore API. Several people were of the opinion that the datastore API in .84 only deals with the Journal proper and I would have to use POSIX commands to list out files on thumb drives. That is what I am planning to do. I haven't tried this on SoaS lately, so I don't know how this might work on the latest .84. James Simmons On Thu, Aug 27, 2009 at 4:30 AM, Tomeu Vizoso wrote: > On Wed, Aug 26, 2009 at 17:09, Jim Simmons wrote: >> Eben, >> >> I have given some thought to how I would implement getting image files >> from removable media and I think I have a workable plan. Before I >> describe it I'd like to confess that it is *not* true that .84 code >> will show objects on the root directory of a thumb drive. It won't >> show *anything* on a thumb drive, as some of you have pointed out. >> .82 shows every file whether it is on a thumb drive or in the Journal. >> It is shown as a flat list with no way to tell what came from where. > > 0.84 should display all files in the thumb drive in the same flat > view, if it doesn't is because there's a bug somewhere. > >> What I think I might do is emulate this behavior in .84. Python has >> an os.walk() function that will list out all the files within a >> subdirectory. I was thinking that after I load the table with Journal >> objects I could do the os.walk() for the directory /media, which is >> where all the removable media seems to get mounted. In my table model >> I would store the filename and a wrapper class for a Journal object. >> If there is an actual Journal object in there it would call the object >> to get a path to the image file in the Journal. If not, it would >> simply get a real path to a file on a removable device. > > This is very close to what should be happening in 0.84. > >> I would not check for mounts, etc. Instead, my Activity has a Refresh >> button which reloads everything. The user would know when he needs to >> use it. >> >> I might put some sort of icon in the table rows so the user knows >> which entries are from the Journal and which are from thumb drives, >> etc. >> >> I suppose the ObjectChooser should be improved as much as possible, >> but I doubt I'll ever use it myself. If you want to load only one >> file into an Activity you could just as easily restore the file from >> the Journal. If you need to load more than one file having a modal >> dialog pop up each time just slows you down. > > Agreed, multiple selections would help there I guess. > > Regards, > > Tomeu > >> James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New F11 for the XO-1 Build 6
joshua n pritikin wrote: > On Thu, Aug 27, 2009 at 08:59:28AM -0400, Paul Fox wrote: > > have you tried using an external USB keyboard when booting? > > I can. How do you expect that will help? Will I be able to chvt from the > USB keyboard? i don't know. that's why i asked you to try it. :-) it wasn't yet clear to me that you have proper keyboard/mouse functionality, and i was thinking a change of input devices might be a useful experiment. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New F11 for the XO-1 Build 6
On Thu, Aug 27, 2009 at 08:59:28AM -0400, Paul Fox wrote: > have you tried using an external USB keyboard when booting? I can. How do you expect that will help? Will I be able to chvt from the USB keyboard? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New F11 for the XO-1 Build 6
joshua n pritikin wrote: > On Wed, Aug 26, 2009 at 11:50:12AM -0400, Steven M. Parrish wrote: > > All normal warnings apply. This is development code. Please report any > > issues you may have. > > I tried flashing os6 to NAND. It boots until X comes up, then it gets > stuck on a white screen. I am experiencing the same problem with Martin > Dengler's builds. xo50 was the last one that worked. More recent builds > fail in the same way as os6. i'm at a loss as to what your problem might be, but... > > - If I press the power butten then I get a nice image and the machine > suspends. If I press the power button again then the machine resumes to > a white screen. i can comment on this. i assume the "nice image" is the powerd suspend/powerdown menu. this means powerd is running -- it's started from upstart, on the rootfs. it also means that VTs can be switched, because that splash screen is put up essentially by doing a chvt, and writing a ppm image to the screen (much the way bootanim and ul_warning work). to gather a bit more data: > > - Alt-left, Alt-right, Ctrl-Alt-F1, Ctrl-Alt-F2, Ctrl-Alt-F3, etc do not > get me to a terminal. Ctrl-Alt-Erase does nothing. when the splash screen comes up, can you get it to go away (and keep the laptop from suspending) by touching the touchpad, or another keypad key? that will confirm that user input is making at least as far as olpc-kbdshim. have you tried using an external USB keyboard when booting? paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About handing of files from external drives in journal
On Fri, Aug 21, 2009 at 07:10, Kushal Das wrote: > Hi, > > Currently journal copies the files from external devices and the > activities don't get any feeling from where it is coming. Which is > acceptable in most cases but while working on music playlist files > (like .m3u or .pls) it becomes difficult as they contain relative path > to the actual songs/videos. > > Jukebox used to find the real path of the link created by the journal. > > Possible solutions: > * Journal can keep an entry in the data structure pointing to the > real location of the file (the place it came from) > * Go back to old only link creating idea (Bad , this may break many > activities) > > I am looking for suggestions on how to overcome this issue. Sorry, I'm really short of ideas on this one. Something very dirty you could do is to look in /media/*/ for the files referenced in the .pls. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)
On Wed, Aug 26, 2009 at 17:09, Jim Simmons wrote: > Eben, > > I have given some thought to how I would implement getting image files > from removable media and I think I have a workable plan. Before I > describe it I'd like to confess that it is *not* true that .84 code > will show objects on the root directory of a thumb drive. It won't > show *anything* on a thumb drive, as some of you have pointed out. > .82 shows every file whether it is on a thumb drive or in the Journal. > It is shown as a flat list with no way to tell what came from where. 0.84 should display all files in the thumb drive in the same flat view, if it doesn't is because there's a bug somewhere. > What I think I might do is emulate this behavior in .84. Python has > an os.walk() function that will list out all the files within a > subdirectory. I was thinking that after I load the table with Journal > objects I could do the os.walk() for the directory /media, which is > where all the removable media seems to get mounted. In my table model > I would store the filename and a wrapper class for a Journal object. > If there is an actual Journal object in there it would call the object > to get a path to the image file in the Journal. If not, it would > simply get a real path to a file on a removable device. This is very close to what should be happening in 0.84. > I would not check for mounts, etc. Instead, my Activity has a Refresh > button which reloads everything. The user would know when he needs to > use it. > > I might put some sort of icon in the table rows so the user knows > which entries are from the Journal and which are from thumb drives, > etc. > > I suppose the ObjectChooser should be improved as much as possible, > but I doubt I'll ever use it myself. If you want to load only one > file into an Activity you could just as easily restore the file from > the Journal. If you need to load more than one file having a modal > dialog pop up each time just slows you down. Agreed, multiple selections would help there I guess. Regards, Tomeu > James Simmons > > > On Wed, Aug 26, 2009 at 8:53 AM, Eben Eliason wrote: >> On Wed, Aug 19, 2009 at 5:43 AM, Sascha >> Silbe wrote: >>> On Wed, Aug 19, 2009 at 08:41:28AM +0200, Tomeu Vizoso wrote: >>> The public API is the POSIX one, though I don't know how this will be affected by future versions of Rainbow. >>> >>> I can't find anything regarding mount points in POSIX 2001. How do you >>> expect Jims activity to discover them? >>> Two ways come to my mind: >>> a) parse /proc/mounts periodically >>> Linux-only, time-wasting but future-proof >>> >>> b) use what the Journal is using internally, i.e. the Gnome way of the day >>> cross-platform (as much as Gnome/Sugar are), event-driven, but likely to >>> break on next release >>> >>> Just as a reminder: The intended workflow for Jims activity seems to be: >>> 1. Start activity >>> 2. Plug in USB stick with photos >>> 3. Select and/or manage(?) photo from within the activity >>> >>> Answering "use POSIX" is like "use a computer", it doesn't help getting the >>> job done. If the answer is "we want the user to copy the photos to the data >>> store first", that doesn't get the job done either, but it's a policy and >>> can be catered for (i.e. documented). >> >> The way I saw this working would be to extend the object chooser to >> allow multiple sources, including external media. Where there is >> currently a Journal icon in the chooser, we would also show any USB >> sticks and SD cards present, and these would be selectable (with the >> Journal the default, of course). Any activity could then invoke the >> object chooser to select objects from the Journal or from external >> media, without the overhead of building their own UI. Once the objects >> are loaded into the activity, they can be bundled up and saved as >> desired. >> >> We even have some preliminary design sketches for this feature: >> http://wiki.sugarlabs.org/go/Design_Team/Designs/Object_Chooser#04 >> >> Eben >> >> >>> CU Sascha >>> >>> -- >>> http://sascha.silbe.org/ >>> http://www.infra-silbe.de/ >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1.4.9 (GNU/Linux) >>> >>> iQEcBAEBAgAGBQJKi8kiAAoJELpz82VMF3Da9+kH/iA64CVf2gkml2dmLezzWdPt >>> HwDhOjpqh+eAs06i+we8UlqwRAgoEmqBMQ7eC16eqm4UrWhSKo6OeX0Rk1RdW8/o >>> Lf1a7HsHpCjxWhudDOtxMcGUeLtb4ahGZR+0mYNiXG5I6DhJh6Diq+UAbGqRXZy7 >>> mo80yjbFDf6NTW2J7qI6mTvhNJl1pEOEpx+FF30Dg5BpUZ+b5ES03nL2WhDK4LUV >>> O6FTEPFfsXSLvYFUTG2TA7Ggjz43RxeAnp2Vuc2Pu6YbNX21iT5OT+12hAWzyMDx >>> QWqOSjEedKZZvT6bhXOWsBGPuff/XmOz83KESR4JsLXQp208BI+3zFBEmxBoYDQ= >>> =Yl9z >>> -END PGP SIGNATURE- >>> >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >>> >> > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning __
Re: [Sugar-devel] Accessing external media from within an activity (was: Re: Problem listing journal objects)
On Wed, Aug 19, 2009 at 11:43, Sascha Silbe wrote: > On Wed, Aug 19, 2009 at 08:41:28AM +0200, Tomeu Vizoso wrote: > >> The public API is the POSIX one, though I don't know how this will be >> affected by future versions of Rainbow. > > I can't find anything regarding mount points in POSIX 2001. How do you > expect Jims activity to discover them? > Two ways come to my mind: > a) parse /proc/mounts periodically > Linux-only, time-wasting but future-proof > > b) use what the Journal is using internally, i.e. the Gnome way of the day > cross-platform (as much as Gnome/Sugar are), event-driven, but likely to > break on next release > > Just as a reminder: The intended workflow for Jims activity seems to be: > 1. Start activity > 2. Plug in USB stick with photos > 3. Select and/or manage(?) photo from within the activity > > Answering "use POSIX" is like "use a computer", it doesn't help getting the > job done. If the answer is "we want the user to copy the photos to the data > store first", that doesn't get the job done either, but it's a policy and > can be catered for (i.e. documented). I agree that my answer wasn't nor complete nor accurate, thanks for following up. Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKi8kiAAoJELpz82VMF3Da9+kH/iA64CVf2gkml2dmLezzWdPt > HwDhOjpqh+eAs06i+we8UlqwRAgoEmqBMQ7eC16eqm4UrWhSKo6OeX0Rk1RdW8/o > Lf1a7HsHpCjxWhudDOtxMcGUeLtb4ahGZR+0mYNiXG5I6DhJh6Diq+UAbGqRXZy7 > mo80yjbFDf6NTW2J7qI6mTvhNJl1pEOEpx+FF30Dg5BpUZ+b5ES03nL2WhDK4LUV > O6FTEPFfsXSLvYFUTG2TA7Ggjz43RxeAnp2Vuc2Pu6YbNX21iT5OT+12hAWzyMDx > QWqOSjEedKZZvT6bhXOWsBGPuff/XmOz83KESR4JsLXQp208BI+3zFBEmxBoYDQ= > =Yl9z > -END PGP SIGNATURE- > > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] erasing the journal and config
Perhaps the librarians would accept a different initialisation method ... one that I use here is a USB flash key with a boot/olpc.fth file which automatically wipes a laptop. As a result, it is dangerous, and kept separate from others. Powering up with it inserted loses all stored data, and reflashes to a standard build. An example of something similar is in the mkbootable.sh script in xodist (the debxo image builder), which has a prompt for "yes" before it erases everything. A copy of the script is attached ... look inside it for the olpc.fth that is constructed. Having a "ruin everything" object (the USB flash key) means it can be scripted, made simple, yet secured in a locked draw to prevent accidental use. I've tested this method only on unlocked laptops. For locked laptops some similar method might be used. -- James Cameron http://quozl.linux.org.au/ mkbootable.sh Description: Bourne shell script ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
