Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On 06/11/2010 03:30 PM, Peter Robinson wrote: On Tue, Jun 8, 2010 at 5:54 AM, Michael Stonemich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15.you:your patch series here Comments? Additions? Substitutions? Deletions? Michael, thanks for stepping up to be the 0.90 development manager :-P Peter PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] review process changes
El Thu, 03-06-2010 a las 12:19 +0200, Tomeu Vizoso escribió: Thanks, this is really useful. A few observations: - how to link tickets and patches? One way is to always end the commit message with a link to the bug: http://bugs.sugarlabs.org/ticket/1622 This is what git-bz does automatically. With proper email search, you can get all tracmail and patch reviews with a single search. +1 - queue control: I still feel it will be harder to find the right patch to review but at the same time, in all the other projects I submit patches to, I need to ping people in irc to get them reviewed. Should we move from a system with a strict queue to a ping-based system? If so, we may need a patch manager as mentioned in http://producingoss.com/en/producingoss.html#patch-manager I'm not a fan of patch managers, but Patchwork seems to be a very good one with a lightweight interface. Ping-based systems work well in practice because it puts the initiative on the side which submitted the patch and presumably cares the most about it. It works more like TCP than ping: if the maintainer forgot about your patch, you keep resending your patch until you obtain an ACK (or a NAK). Like in TCP, resending should be an exceptional case. If all patches routinely need to be resent multiple times, it means that we have insufficient reviewer bandwidth. -- // 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] [PATCH] fix trivial typo in extension loading exception
El Thu, 03-06-2010 a las 14:03 +0200, Tomeu Vizoso escribió: Well, but I guess we want to test a particular new process and for that, it needs to be written somewhere. Otherwise, each of us could end up testing a different process. Bernie was going to propose concrete changes but then got diverted to the realness summit. Is something stopping the other interested parties to propose the process they think is better? Even though I care very much about the upstream development process, at this time I'm really too busy with the F11-0.88 builds to put the necessary amount of thought into it. So, yeah, I'd appreciate if James could kindly help out by writing down a draft based on our previous discussions. -- // 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] ANNOUNCE: Sugar 0.88 for the XO-1
El Fri, 04-06-2010 a las 11:00 +1000, James Cameron escribió: Does this change fix the bug? No. (But it does fix the size of icons in the activity ring). BTW, a lot of testers told me that they like the small toolbar icons of the 72dpi mode more than the old big ones. I also think it confers Sugar a more... functional look feel. Thou all this people aren't really children. Was there some rationale behind using very large icons with children age 6-12? It's not like they have worse vision than adults. I've now switched back to 100dpi, to see what the reactions are. -- // 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] tuchpad revelde
El Thu, 03-06-2010 a las 15:46 -0600, Kevin Mauricio Benavides Castro escribió: Hola como estan a todos los de la lista tengo un problema en un colegio de una comunidad se entregaron XO y la mayoria de los casos de problemas tecnicos son de touchpad que es muy revelde para solucionar este problema temporalmente uso la combinacion de teclas para calibrarlo Hola. Perdone mi español malo. Cual version de sistema operativo tienes? Las versiones siguientes de OLPC 801 corrigen el bug mas molesto de el touchpad: el cursor que salta a la esquina de la pantalla. Si tu XOs no están bloqueados, recomiendo probar el build paraguayo os 180. Es aquí: http://people.sugarlabs.org/bernie/olpc/f11-xo1-py/ -- // 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] Hypothetical sugar-0.90 material, draft 1.
El Sat, 12-06-2010 a las 10:26 +0200, Simon Schampijer escribió: PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. +1. I would also very much like our next RM to preserve our 6-months release cycle and keep it synchronized with the major Linux distros, like GNOME and other high-profile projects do. This does not imply that we cannot ever do very large restructuring of our codebase, if needed. This kind of work just needs to happen in a development trees and be merged when it's sufficiently stable. -- // 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] Hypothetical sugar-0.90 material, draft 1.
On Sat, Jun 12, 2010 at 9:26 AM, Simon Schampijer si...@schampijer.de wrote: On 06/11/2010 03:30 PM, Peter Robinson wrote: On Tue, Jun 8, 2010 at 5:54 AM, Michael Stonemich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15.you:your patch series here Comments? Additions? Substitutions? Deletions? Michael, thanks for stepping up to be the 0.90 development manager :-P Peter PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. No, that was my bad. Not a change but me stuffing up the title name. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
El Sat, 12-06-2010 a las 01:15 -0400, Chris Ball escribió: Hi, Why it is just a pipe dream? 1. Python does not have anything like the DALVIK virtual machine so every Python process consumes a lot of memory. Because of this, implementing the above infrastructure would consume all available RAM and so would not work. Linux memory management shares identical pages between processes. This has been discussed at length on the FUDbus to Toronto with some hard-core Fedora folks. The general opinion is that it won't work in the case of Python, because pages will containing Python objects will: - often contain pointers with slightly different values across processes - As the program accesses the shared objects, even for read-only operations, the intepreter will often increment and decrement reference counts to objects, breaking the sharing This are the very same reasons why the parent process approach was not buying us much. David Malcolm, the the maintainer of Python in Fedora, proposed a strategy which would, sadly, require changes to the on-disk pyc format: http://dmalcolm.livejournal.com/4183.html -- // 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] Hypothetical sugar-0.90 material, draft 1.
El Thu, 10-06-2010 a las 14:24 -0400, Martin Langhoff escribió: On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ and they get little testing and I've seen extremely light thinking about what is _actually_ needed. That's a very polite way of saying that you disagree with the extensive thinking that's been done about datastore design and implementation for No. _It says exactly what it says_. People have been thinking lots about the fun part of the problem, thinking superficially about what they'll have fun implementing. Not about the complete problem space. Not about what hits users. Not about what we need for a saner implementation. I would tend to agree with Martin here. Besides, the assumption that VCS-style deltas will work well with the binary files stored by most Sugar activities is... wishful at best. A design working in real-world scenarios would probably require ad-hoc deltifiers for each file format, making it very complex, slow and fragile. Whether a generic versioned filesystem could ever become feasible, remains a fascinating research subject for the next decade. Perhaps we could slightly enhance the current datastore design to store full copies of each version without any attempt to deltify them. This is also how git started. -- // 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] Hypothetical sugar-0.90 material, draft 1.
On 06/12/2010 10:49 AM, Bernie Innocenti wrote: Besides, the assumption that VCS-style deltas will work well with the binary files stored by most Sugar activities is... wishful at best. It is one thing to say that we need a new datastore, and another to say what the new datastore should look like. I believe we have consensus on the first part, and I'm fairly sure we don't have consensus on the second. For the record, I am pushing a proposal in which no deltas are computed. Files are stored as whole files. Instead, I want each datastore object version to consist of an entire directory. To save space, files that are identical inside multiple objects would only be stored once on disk. This allows us to store and launch Activity Bundles directly from the journal. It also allows slight modifications to objects (including activities) to be stored efficiently if the object consists of multiple files and not all of them are changed. This is the de-duplication approach that was favored over three years ago [1]. I think Martin has listed some important use cases, and we should consider them carefully. One way to do that might be to try to reach a consensus on design. I believe the last attempt at this was over two years ago [2] ... and produced many good ideas but ultimately not much code. --Ben [1] http://lists.sugarlabs.org/archive/sugar-devel/2007-April/002344.html [2] http://lists.laptop.org/pipermail/community-news/2008-January/95.html , section 10. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore rewrite
El Sat, 12-06-2010 a las 11:40 -0400, Benjamin M. Schwartz escribió: It is one thing to say that we need a new datastore, and another to say what the new datastore should look like. I believe we have consensus on the first part, and I'm fairly sure we don't have consensus on the second. I tend to agree with you. For the record, I am pushing a proposal in which no deltas are computed. Files are stored as whole files. Instead, I want each datastore object version to consist of an entire directory. To save space, files that are identical inside multiple objects would only be stored once on disk. This allows us to store and launch Activity Bundles directly from the journal. It also allows slight modifications to objects (including activities) to be stored efficiently if the object consists of multiple files and not all of them are changed. Sounds like a good approach, please ping me to review the spec when it's available. As an optimization to reduce the number of inodes and vfs syscalls, perhaps it might be worthwhile to let the activity specify whether it needs to store one file or a directory with multiple files. -- // 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
[Sugar-devel] Revised hypothetical material for sugar-0.90
First, thanks very much to everyone who commented on my previous thread about wild rumors for sugar-0.90. Your comments are very helpful to me because they inform my mental picture of what changes might be available within the next few months to be released. They are also valuable in their own right for creating excitement, engagement, and a sense of healthy community. Therefore, keep up the good work! Second, to tomeu, rgs, aa, mabente, epastorino, esteban, erikos -- I'd like to hear more from you! In particular, if you could please speak up about the rightness or wrongness of my guesses on what you're going to be working on, I would be most appreciative. Third, to those who are reading this email but who are not yet comfortable replying in public -- don't worry! Public responses are good, but private ones can be okay too and I really want you to be involved. Therefore, please feel free to write to me privately. I'll do what I can to write back and to fold your ideas into future conversations. Regards, Michael ... Sugar-0.90 Integration and Testing Needs Here's a slightly updated list of integration and testing needs based on last week's comments. Further discussion is encouraged. Bigger integration needs: 1. Aleksey: 0install integration 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Raul: rainbow 5. Michael: git repo reorganization and build system rewrite 6. you: your feature here Smaller integration needs: 7. Gary + Christian: alternative activity launch UI 8. Gary + Scott: preliminary touch-related UI tweaks 9. Esteban: virtual keyboard 10. Lucian: browser abstraction 11. Martin L.: polish 12. Walter: write to journal any time 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 16. you: your tweak here I'm not sure yet: 17. Walter: multiple home views 18. Simon: dotted activity versions 19. Peter: support new gnome libraries Certification / testing needs : 20. Aleksey: Vala-based sugar-toolkit 21. you: your activity here ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
Besides, the assumption that VCS-style deltas will work well with the binary files stored by most Sugar activities is... wishful at best. A design working in real-world scenarios would probably require ad-hoc deltifiers for each file format, making it very complex, slow and fragile. Whether a generic versioned filesystem could ever become feasible, remains a fascinating research subject for the next decade. Perhaps we could slightly enhance the current datastore design to store full copies of each version without any attempt to deltify them. This is also how git started. Actually these are the exact same problems that could be solved much better with some kind of per activity DS (not the Android one, which would be a little bit overkill). I mean that even making or not making deltas is dependent on the object the activity stores and the deltifier is also activity object dependent. Also the single file or multi files thing is activity dependent and so on. So you can implement every possible feature in a global glorified DS but I personally do not think that you will reach a really usable general DS ever. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
El Sat, 12-06-2010 a las 20:45 +0200, NoiseEHC escribió: Actually these are the exact same problems that could be solved much better with some kind of per activity DS (not the Android one, which would be a little bit overkill). I mean that even making or not making deltas is dependent on the object the activity stores and the deltifier is also activity object dependent. Also the single file or multi files thing is activity dependent and so on. So you can implement every possible feature in a global glorified DS but I personally do not think that you will reach a really usable general DS ever. This is the same conclusion me and Sascha reached on IRC some time ago. To me, saying that activity authors will have to deal directly with the concept of deltas is equivalent to admitting that it can't be done at all. -- // 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] Datastore rewrite
On Sat, Jun 12, 2010 at 12:57 PM, Bernie Innocenti ber...@codewiz.orgwrote: El Sat, 12-06-2010 a las 11:40 -0400, Benjamin M. Schwartz escribió: It is one thing to say that we need a new datastore, and another to say what the new datastore should look like. I believe we have consensus on the first part, and I'm fairly sure we don't have consensus on the second. I tend to agree with you. For the record, I am pushing a proposal in which no deltas are computed. Files are stored as whole files. Instead, I want each datastore object version to consist of an entire directory. To save space, files that are identical inside multiple objects would only be stored once on disk. This allows us to store and launch Activity Bundles directly from the journal. It also allows slight modifications to objects (including activities) to be stored efficiently if the object consists of multiple files and not all of them are changed. Sounds like a good approach, please ping me to review the spec when it's available. Some references here: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal Sascha Silbe's Datastore redesign draft with embedded comments from Eben, Tomeu, Sascha: https://docs.google.com/a/sugarlabs.org/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGhthl=en (Sugar Labs account holders may edit this document.) As an optimization to reduce the number of inodes and vfs syscalls, perhaps it might be worthwhile to let the activity specify whether it needs to store one file or a directory with multiple files. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Paint patch: fix #813 problem with clipboard OLPC #9022 also
From 12ce2bb69724372132366afa7abf2d3a07be1537 Mon Sep 17 00:00:00 2001
From: Gonzalo Odiard godi...@gmail.com
Date: Sat, 12 Jun 2010 18:08:08 -0300
Subject: [PATCH] fix #813 problem with clipboard , OLPC #9022 also
This resolves pasting of a image from Browse to Paint or inside Paint
Not resolves draging one image from the frame to Paint
---
Area.py |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Area.py b/Area.py
index 7b921b8..8340d50 100644
--- a/Area.py
+++ b/Area.py
@@ -69,6 +69,7 @@ import math
import pango
from fill import *
from Desenho import Desenho
+from urlparse import urlparse
##Tools and events manipulation are handle with this class.
class Area(gtk.DrawingArea):
@@ -741,6 +742,11 @@ class Area(gtk.DrawingArea):
self.tool['name'] = 'marquee-rectangular'
self.window.set_cursor(gtk.gdk.Cursor(gtk.gdk.FLEUR))
self.emit('select')
+elif clipBoard.wait_is_uris_available():
+selection = clipBoard.wait_for_contents('text/uri-list')
+if selection != None:
+for uri in selection.get_uris():
+self.loadImage(urlparse(uri).path, self)
else:
self.loadImage(tempPath, self)
logging.debug('Area.past(self): Load from clipboard fails,
loading from tempPatch')
--
1.6.6.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
Bernie 72 dpi icons looked good to me Maybe the logic of big icons was not eyesight but touchpad control? Though the target audience of the XO builds is still children 6-12, it doesnt have to restrict the audience of other Sugar builds. Sugarlabs can have a wider mission than OLPC. There are features of Sugar which should have strong 12+ appeal: show source, Pippy, TurtleArt Python extensions. I dont recall the issue of target audience ever being discussed at Sugarlabs, we kind of inherited the 6-12 mission of OLPC without further analysis. Tony El Fri, 04-06-2010 a las 11:00 +1000, James Cameron escribió: Does this change fix the bug? No. (But it does fix the size of icons in the activity ring). BTW, a lot of testers told me that they like the small toolbar icons of the 72dpi mode more than the old big ones. I also think it confers Sugar a more... functional look feel. Thou all this people aren't really children. Was there some rationale behind using very large icons with children age 6-12? It's not like they have worse vision than adults. I've now switched back to 100dpi, to see what the reactions are. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
El Sun, 13-06-2010 a las 08:40 +1000, fors...@ozonline.com.au escribió: 72 dpi icons looked good to me Maybe the logic of big icons was not eyesight but touchpad control? Though the target audience of the XO builds is still children 6-12, it doesnt have to restrict the audience of other Sugar builds. Sugarlabs can have a wider mission than OLPC. I agree, but we constantly get told that we should be more focused, not less :-) One easy thing we could do is make the size of these UI elements scalable along with the font. I think there was some code to do it in trac, but it didn't make it in time for 0.88. There are features of Sugar which should have strong 12+ appeal: show source, Pippy, TurtleArt Python extensions. I made some high-school kids play with these and they seemed to have fun. I dont recall the issue of target audience ever being discussed at Sugarlabs, we kind of inherited the 6-12 mission of OLPC without further analysis. I don't have the expertise to tell, but from my occasional observations it seems that 4+ yr children already enjoy hacking on Sugar and they start to feel too constrained at ages 10 and more. I'm talking of kids in developed nations who are kids who are constantly exposed to technology, though. I'd let pedagogists tell us. (and any followup to this thread should probably be moved to iaep@ anyway). -- // 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] Revised hypothetical material for sugar-0.90
Thanks Michael I am interested in what each of these changes means for the user experience. Is it possible to add a link to each of the listed changes so I (and maybe others) can read up a bit on them? Should this list be on the wiki? Maybe it is but I cant find it. Like http://wiki.sugarlabs.org/go/0.88/Feature_List or http://wiki.sugarlabs.org/go/Category:Feature_Page_Incomplete ? Is anybody working on printer support? Tony First, thanks very much to everyone who commented on my previous thread about wild rumors for sugar-0.90. Your comments are very helpful to me because they inform my mental picture of what changes might be available within the next few months to be released. They are also valuable in their own right for creating excitement, engagement, and a sense of healthy community. Therefore, keep up the good work! Second, to tomeu, rgs, aa, mabente, epastorino, esteban, erikos -- I'd like to hear more from you! In particular, if you could please speak up about the rightness or wrongness of my guesses on what you're going to be working on, I would be most appreciative. Third, to those who are reading this email but who are not yet comfortable replying in public -- don't worry! Public responses are good, but private ones can be okay too and I really want you to be involved. Therefore, please feel free to write to me privately. I'll do what I can to write back and to fold your ideas into future conversations. Regards, Michael ... Sugar-0.90 Integration and Testing Needs Here's a slightly updated list of integration and testing needs based on last week's comments. Further discussion is encouraged. Bigger integration needs: 1. Aleksey: 0install integration 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Raul: rainbow 5. Michael: git repo reorganization and build system rewrite 6. you: your feature here Smaller integration needs: 7. Gary + Christian: alternative activity launch UI 8. Gary + Scott: preliminary touch-related UI tweaks 9. Esteban: virtual keyboard 10. Lucian: browser abstraction 11. Martin L.: polish 12. Walter: write to journal any time 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 16. you: your tweak here I'm not sure yet: 17. Walter: multiple home views 18. Simon: dotted activity versions 19. Peter: support new gnome libraries Certification / testing needs : 20. Aleksey: Vala-based sugar-toolkit 21. you: your activity here ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
Hi guys, On 12 Jun 2010, at 23:53, Bernie Innocenti wrote: El Sun, 13-06-2010 a las 08:40 +1000, fors...@ozonline.com.au escribió: 72 dpi icons looked good to me Maybe the logic of big icons was not eyesight but touchpad control? Though the target audience of the XO builds is still children 6-12, it doesnt have to restrict the audience of other Sugar builds. Sugarlabs can have a wider mission than OLPC. I agree, but we constantly get told that we should be more focused, not less :-) +1 One easy thing we could do is make the size of these UI elements scalable along with the font. I think there was some code to do it in trac, but it didn't make it in time for 0.88. Activity developers need to know how many units they have for development, we already have occasional issues where the final distro Sugar does not conform to the Sugar HIG units. Having important functions (aka Stop) fall off the toolbar into a fairly hidden, hard to use drop down menu is a bit of a pain :) If we add some pref option to switch to smaller icons, we will need to get a big heavy stick ready for 'doers' who decide to fill the extra space with tool buttons ;) Regards, --Gary There are features of Sugar which should have strong 12+ appeal: show source, Pippy, TurtleArt Python extensions. I made some high-school kids play with these and they seemed to have fun. I dont recall the issue of target audience ever being discussed at Sugarlabs, we kind of inherited the 6-12 mission of OLPC without further analysis. I don't have the expertise to tell, but from my occasional observations it seems that 4+ yr children already enjoy hacking on Sugar and they start to feel too constrained at ages 10 and more. I'm talking of kids in developed nations who are kids who are constantly exposed to technology, though. I'd let pedagogists tell us. (and any followup to this thread should probably be moved to iaep@ anyway). -- // 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Lost at sea, Calculate-31
Hi Guys, Was just having to re-installing activities to a fresh Sugar (trying to get to test recent Physics patches), and noticed that Calculate is only on ASLO up to version 30! Version 31 was the one supporting the new Sugar toolbars. I guess an official release of it must have slipped through the release cracks. Anyone have any objections to me releasing 31 (it's all in git ready to go)? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fructose Dependencies?
Hi Guys, Should pygame be listed as an official Fructose Dependency (or even Glucose)? I can't find it referenced on the wiki road map pages. Only ask as have just installed Sugar as the desktop in a regular F13 install and it didn't pull in pygame as a dependency, so will cause failures for things like Pippy, Physics, Maze when added from ASLO. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
