Re: [sugar] 0.84 goals
Marco Pesenti Gritti wrote: Hello, I started working on the goals for 0.84 in the wiki: http://sugarlabs.org/go/ReleaseTeam/Roadmap/0.84#Goals Here is what I have so far. * Next generation journal * File sharing * Collaboration scalability * Responsive UI * Stable activities API * Official Sugar LiveCD * Compatibility with desktop applications * Quality and reliability Each of them points to a separate page in the wiki. I'll be working on several of these pages in the next weeks, writing down requirements, designs and thoughts about resourcing. Help wanted! As you can see the scope is very large. The plan is to narrow down each item to more concrete action items and then probably punt some of the high level goals. But I really want to get a bunch of stuff done this cycle!!! I know it's very vague for now. But if something is obvious missing please let me know or edit directly. Thanks, Marco Some points that came to my mind: - use of gconf for the control panel - what is about performance work - is this covered by 'Quality and reliability' ? - for the 'Next generation journal' I would like to see the possibility to have start-with in the palette of the entry (use-case: to open the source page you created in browse in write you need to use the detail view at the moment #7860). Eben had some ideas on what he want already. Thanks, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Reviews report
= Approved requests = Search entry in Home focuses list view when cleared http://dev.laptop.org/ticket/7874 Double clicking an activity in the home ring causes 2 instances to launch http://dev.laptop.org/ticket/7876 bundlebuilder should warn about missing localization files in the MANIFEST http://dev.laptop.org/ticket/7832 Cannot install Wikipedia-10.xo http://dev.laptop.org/ticket/7733 Home view XO icon palette for Control Panel has wrong icon http://dev.laptop.org/ticket/7987 /setup release does not update the bundle number http://dev.laptop.org/ticket/7270 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
This is getting a little out of hand, here. Let's break this down again, because I think we're all arguing for pretty much the same thing. On Wed, Aug 20, 2008 at 12:19 AM, Bastien [EMAIL PROTECTED] wrote: Eduardo Heleno [EMAIL PROTECTED] writes: But my point was that, at the moment, you can choose to Erase an item, and it's gone forever. I expect that many kids will do this, and will at some point regret erasing some item. Yes. This is a request that has been made here in Haïti. The issue of deletion confirmation is covered under ticket http://dev.laptop.org/ticket/7859. I flagged it as blocks?:8.2.0, but I don't think it is going to be nominated as a blocker at this point unless there is a strong push for it. This is, at least for now, independent of the trash can issue itself. On Wed, Aug 20, 2008 at 1:27 AM, Bastien [EMAIL PROTECTED] wrote: Martin Langhoff [EMAIL PROTECTED] writes: AFAIK, the plan is to *discourage* deletion until the disk is getting full. When you are getting to disk-full, trashcan doesn't help. Yes it does: it contains entries that the system can safely delete without forcing the user to go thru the entries and sort them out on the fly. This is no less true in the future Journal design. Anything which has been previously erased can be transparently deleted by the system without another prompt. The Journal should be following a lazy-deletion strategy, making it really no different from the trash can you speak of. The only difference is how the erased but not yet truly gone files get represented to the user. People now want deletion because the Journal is not optimal. They want deletion to sort out entries in the Joural and get rid of unfinished or useless entries. With too many entries, the (current 703/708) Journal becomes unusable. I do recognize this. The one detail we could add to potentially solve this argument is a button which turns on/off visibility of erased entries. That is, a button which basically shows and hides trashed files by toggling their visibility inline within the Journal, in addition to a way to view only those files as well. When you are running out off disk space, we have two cases: - ds-backup has been doing its job, there's a copy of the files in the XS, so the journal has old-and-backed-up files that it can decide to rm I'm afraid XS servers won't be of use in *many* schools. That's fine. The backup solution is an enhancement, not a requirement. Consider the possible states for entries: 1. Normal: file stored locally on the XO 2. Normal+Backup: file stored locally on the XO, and also on the server 3. Lazy-erased: file stored locally on the XO, but rendered differently to indicate transient state 4. Lazy-erased+Backup: same as above, but also backed up to the server 5. Erased: not stored locally on XO 6. Erased+backup: not stored locally on XO, but still available on the server States 1, 3, and 5 are the basic states without backup in the picture. They map directly onto a file, a trashed file, and a file which has been emptied from the trash, respectively. Without a server, you can still recover anything in state 3. When you have a server, you can recover anything in states 3, 4, and 5 (call these the recoverable states). In all of these recoverable states, we will visually represent a the entry in a way distinct from normal, present entries, and the entries in these states will have buttons which allow them to be a) recovered or b) permanently erased. If we want, we can be a bit more clever about which cases require deletion confirmation (based upon whether or not the action results in a recoverable state), but we could simply ask for confirmation all the time for consistency. Or, never. - no old-and-backed-up files we can safely remove? Prompt the user I'm curious whether someone did this job of being prompted. How long does it take? If you can't remember what a file contains, checking if it's safe to delete it by trying to reopen it might be tiring. The Journal does (will do) better than many other systems. The preview is sadly underutilized at the moment, but it should provide a hint without the need to open it. We have a few ideas about how to encourage naming and tagging as well, which will improve this situation a lot. Finally, we have the notion of favorites in the Journal. If we encourage their use as well (which we will in the next version, since it will be possible to filter the list to show only favorites, thus eliminating the unwanted entries which currently make it difficult to find things), then it should be easy to at least preserve the things you've already indicated in the past mean something to you. We'll also have true versioning in the future, so it will be possible to prune the version tree, keeping fewer intermediate versions the further back in time we look. 2008/8/20 [EMAIL PROTECTED]: prompt the user, interrupting whatever they were trying to get done?
Re: [sugar] #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
eben wrote: ... I hope this clarifies my position on this subject a bit, and paints a it does. thank you. paul picture which is really just a different perspective on the usual trash can metaphor, rather than an abandonment of it. - Eben =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
Eben Eliason [EMAIL PROTECTED] writes: The issue of deletion confirmation is covered under ticket http://dev.laptop.org/ticket/7859. I flagged it as blocks?:8.2.0, but I don't think it is going to be nominated as a blocker at this point unless there is a strong push for it. I'm not fond of confirmation alerts, no problem if this is not in 8.2.0! This is, at least for now, independent of the trash can issue itself. To me it's not completely independant: a trashbin (or an equivalent) feature) functions as a virtual confirmation system. I think having a trashbin somehow spares the cost of confirmation alerts. The Journal should be following a lazy-deletion strategy, making it really no different from the trash can you speak of. Ok, fair enough The only difference is how the erased but not yet truly gone files get represented to the user. Yes, that the difference I'm interested in :) I do recognize this. The one detail we could add to potentially solve this argument is a button which turns on/off visibility of erased entries. Let me guess: this button is usually what the trashbin icon does? That is, a button which basically shows and hides trashed files by toggling their visibility inline within the Journal, in addition to a way to view only those files as well. Ok, good. The button itself would be visible. The trashed files wouldn't be visible until the button pressed. When the button is pressed, only trashed entries are listed. 3. Lazy-erased: file stored locally on the XO, but rendered differently to indicate transient state Ok, great - for me lazy-erased files should not be displayed unless the trashbin button is pressed (in which case only trashed files are listed. Sorry to repeat myself...) If we want, we can be a bit more clever about which cases require deletion confirmation (based upon whether or not the action results in a recoverable state), but we could simply ask for confirmation all the time for consistency. Or, never. Never :) (never as a default - maybe this could be customisable.) If the default is to rely on confirmation, this will not encourage users to lazy-erase their files. With no backup system, it's becomes more important to encourage them to be selective about what they keep, encouraging regular cleaning up. I hope this clarifies my position on this subject a bit, and paints a picture which is really just a different perspective on the usual trash can metaphor, rather than an abandonment of it. Ok, great - things are very clear now. Can't wait for it to be implemented :) -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar mtg reminder, Thursday August 21 2008 - 14.00 (UTC) --- irc.freenode.net, #sugar-meeting
* Update Thrilling news of this week. * Roadmap What do we want to do for http://sugarlabs.org/go/ReleaseTeam/Roadmap/0.84#Goals * Status of bugfixing which bugs rest for 0.82 and when and in which manner do we release the new packages (the localization team asked for clarification as well) * Introducing the new developers * Control panel updater Design, consequences, profit! We will have guest speaker Scott coming in to talk about the sugar-control-update module and what this means to activity authors. Hope to see you there, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [beagleboard] Why Embedded Sugar?
On Tue, 2008-08-19 at 21:29 -0500, Bill Gatliff wrote: David Farning wrote: It has been a bit of a plug but it looks like we have reach critical mass for a self sustaining embedded Sugar community. I love the idea of getting a critical mass around something, but I don't yet get it regarding Sugar for embedded work. snipped So, sell Sugar to me! I am sorry if I have in any way misrepresented myself. I am not interested in selling sugar. On the other hand, I am interested in locating and fostering communities which share common goals with Sugar and Sugar Labs. Why Sugar? I do not believe that Sugar is the one true desktop. I won't even go so far as to say that Sugar is the one true educational environment. What I do believe is that the open source development model can be used to create an educational stack which is socially beneficial and commercially viable. Sugar can be an important part of that stack. Why Sugar Labs? Currently, Sugar Lab's primary mission is to support the One Laptop Per Child project. Nearly all of our developers are working to support OLPC either by directly supporting the current Sugar release or planning future releases. From an economic perspective, the strength of the open source development model comes from the ability for potential competitors to collaborate on common frameworks while competing by differentiating other parts of the stack. OLPC is shouldering the majority of the cost of Sugar development. My goal for the last several weeks has been to help form communities that share an interest in distributing the Sugar desktop to a wider audience. The first step in that goal has been to encourage Linux distributions to package the Sugar core and activities. Once the packages have stabilized, I will recontact the educational 'spins' about making liveCDs and spins that directly support Sugar as a desktop. The third step in this process will be to directly approach the distributions about integrating Sugar into their business models of 'give away the software and sell the support.' The end goal of this effort is to make Sugar a commodity component of the educational stack. Why embedded sugar? The recent successes of the ASUS Eee PC, OLPC XO, and Intel Classmate have blurred the definition of 'portable' computer from shrunk down, ruggedized personal computer to embedded device with extended IO capabilities. From an Engineering perspective, the goals of the primary target device for Sugar align closely with those of embedded devices. More with Less. We constantly asd, 'How can we increase usability while reducing power consumption, size, and cost?' Traditionally, laptop manufactures have been competing by leveraging Moore's law into more speed, memory, and features. Consumers have grown accustomed to the upgrade cycle. One Laptop Per Child turned that model on its head. They specified minimum features that would meet their goals. They then designed a device that would meet those goals while keeping cost and size at a minimum. It is reasonable to credit OLPC with establishing the $100 laptop market. Neither ASUS, Intel nor any of the other players would have been willing to undercut their existing markets without the threat of the XO. While we are not there yet, the $100 dollar laptop is feasible in the near future. As with the Sugar desktop, I do not believe that the XO is the one true laptop or learning device. It is and can continue to be a valuable hardware platform for running the educational stack. Why embedded? Current embedded CPUs are powerful enough to run the Sugar desktop. The embedded industry has years of experience designing and implementing shock resistant, dust resistant, vibration resistant, and extreme temperature resistant devices. The embedded industry has years of experience competing on cost. The embedded industry has recently made significant progress at reducing power usage and extending battery life in cell phone and other mobile devices. The embedded industry is making progress developing toolkits where porting software between platforms is becoming more and more transparent. I Haven't been working with Sugar on embedded devices long enough to form concrete, long term goals. But for the short term, and as a possible presentation topic for the up coming conference, controlling a LEGO mindstorms robot via Sugar activity running on a BeagleBoard would be pretty cool:) I hope this explains my goals for Sugar Labs and the reasons for those goals. If your goal coincide with any of our goals, I hope we can work together for our mutually benefit. thanks dfarning ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] [beagleboard] Why Embedded Sugar?
On Wed, 20 Aug 2008, David Farning wrote: On Tue, 2008-08-19 at 21:29 -0500, Bill Gatliff wrote: David Farning wrote: It has been a bit of a plug but it looks like we have reach critical mass for a self sustaining embedded Sugar community. I love the idea of getting a critical mass around something, but I don't yet get it regarding Sugar for embedded work. snipped So, sell Sugar to me! I am sorry if I have in any way misrepresented myself. I am not interested in selling Sugar. Then let me give it a try. :) The most interesting initial design goal of Sugar, to me, could be encapsulated in three words: Sharing By Default. A desktop that allows you to see all of your friends? Interact with them in real-time in any activity you wanted, be it music, drawing, storytelling, games, programming? That, to me, was a compelling idea. Sugar is still a-ways away from achieving that vision. But from where I sit, Sugar is the only project that is actively pursuing it. When the metaphor for interacting with your environment changes, the thinking changes right along with it. Sugar, done right, puts sharing with other people right dead in the middle of the computing experience. That's what makes it compelling to me. Some people agree with that vision. Some people don't. My goal is to energize and empower that first group. :) --g ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Why Embedded Sugar?
On Tue, Aug 19, 2008 at 7:29 PM, Bill Gatliff [EMAIL PROTECTED] wrote: David Farning wrote: It has been a bit of a plug but it looks like we have reach critical mass for a self sustaining embedded Sugar community. I love the idea of getting a critical mass around something, but I don't yet get it regarding Sugar for embedded work. The problem is most likely that I'm not thinking out-of-the-box, but if you present Sugar at ESC then you're going to have to really know--- and show--- the embedded itches that Sugar can scratch to a room full of people like me. A demo of a pretty UI on non-PC hardware isn't enough. I'm not discarding Sugar's contribution to the computing community as a whole, and I'm certainly not suggesting that Sugar lacks anything to offer for embedded applications. I just want to make sure that while your new team is busy getting Sugar to work on beagleboard, they're also thinking about how to package its sell to the larger embedded audience. Do that right, and you'll never have to struggle for critical mass again. Do that poorly, however, and all the effort goes nowhere. Case in point. I happen to think Forth is cool for embedded work, but it hasn't caught on. Except at Sun, Apple, and OLPC in the form of Open Firmware, and in a few other such places where the casual observer wouldn't know about it. The problem isn't that Forth lacks advocacy, it's that Forth lacks advocacy by those who can credibly sell it as a solution that embedded developers need. If I didn't have more urgent things to do, I would love the opportunity to sell GPLed FORTH/Open Firmware plus consulting to all of the PC board makers in place of the next billion proprietary BIOS chips. I expect that to be one of the lucrative spinoffs from the OLPC project, just like Pixel Qi's daylight-readable screens and the A123 LiFeP batteries. So we remain stuck with uBoot. :) Makes no sense to me. I would expect OFW to be smaller, faster, and easier to work with. But what do I know? Ask Mitch Bradley for an informed opinion. So, sell Sugar to me! I wonder whether you are thinking only of embedded Sugar competing with the XO in schools. Let me suggest a different scenario. We are working on a literacy project within Sugar, combining a multilingual text-to-speech engine with karaoke-style text coloring, as in the Same Language Subtitling practiced in India. SLS in Bollywood musicals and TV singalongs has proven to be a spectactularly successful literacy program, measured in bang/Rupee. Little old ladies who thought they were past it and would never be able to read anything have been going to musicals six or seven times over, memorizing all the songs, and singing along with all the rest of the audience. With SLS they have unconsciously started learning to read. It's a real revelation to them. Now imagine the poor man's music player with a graphical text display, sold as a learning device, not just as entertainment. Another aspect of this is that XOs can read to the illiterate and preliterate without regard to teaching reading, providing access to all kinds of software and information. Now consider a handheld reading device, with or without a screen. Consider machinery that comes with spoken instruction in addition to printed manuals. Think what people might come up with when they are not bound to the form factors of the conventional devices of the West. Talking POS? Talking GPS and ATMs already exist for the blind. Talking voting machines that can read your ballot back to you so that you know that what you picked on the screen is what will go into the ballot box? With a bit of speech recognition and OCR to open up these and even more opportunities. OK, that was one piece of Sugar software. How about Measure for Free/Open Source digital oscilloscopes? How about mesh-networked medical equipment, like the prototype EKG currently in GSoC? Emergency communications systems? Engineering and scientific measuring instruments? MIDI musical instruments? A voice-chat, mesh-networked replacement for mobile phones? If we want to get a little more blue-sky, how about Open Source cars with built-in driving instruction? b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -- Silent Thunder [ 默雷 / शब्दगर्ज ] is my name, And Children are my nation. The Cosmos is my dwelling place, And Truth my destination. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
