Re: [Sugar-devel] [IAEP] ASLO updates
[cc += dfarning, alsroot, syst...@] El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió: I've made some bug fixes to the new ASLO design, I've tested it lightly and it seems to work in all major browsers (even ie6). If you have a few moments, please test it out (download/upload activities, browse around) and let me know if you see any display bugs or major usability issues. http://activities-devel.sugarlabs.org/en-US/sugar/ All links to activity bundles appear to be broken :-( For example: http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail I'm not sure how to fix it, but I can imagine that it may be related with moving the activity bundles from their old location (/srv/www-sugarlabs/activities/files) to the upload directory (/srv/upload/activities/) done by Dfarning in order to enable Mirrorbrain. Earlier today, alsroot asked me to fix some permission issues that would prevent aslo from writing new activities in the new location. Now I'm also noticing that there's still a copy of the activities in the old location, and it is also bigger by 40MB! /me is very confused :-/ Could anyone who was involved please write a short description of what was changed exactly? I'm only trying to reconstruct the current situation, not looking for a scapegoat. Hmm... well, perhaps we can learn something from this accident: The classic way to avoid the too many cooks syndrome would be to appoint a single official maintainer and make all the change requests go through him. However, I feel this solution would create lots of critical roles and ultimately defeat our ongoing attempts to decentralize system administration. Instead, we shall establish simple procedures to improve sysadmin coordination and communication. For example: 1) commit configuration changes in git along with a short description of what was done and why. We already have repositories for /etc and also and we could create more repos as needed; 2) write a short report for systems@ when we make substantial changes to a service; 3) write or update the wiki documentation for important sysadm procedures such as installing a new instance of a service Use your common sense to decide what needs to be documented and how much detail is needed. At all costs, we want to avoid putting too much bureaucratic burden on volunteers because it's the most effective way to make them look for something more exciting to do. We could save time by coalescing steps (1) and (2): all we need to do is enabling a post-commit hook in the repositories that would send patches to systems-logs@ . We need to be extra careful not to expose passwords in this way. Any volunteers to write and test this procedure? -- // 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] Status report on Bookreading
Thanks for that Sayamindu, very informative I hadn't known about the bookreader list, I signed up. We are leaning towards an e-reader spotlight for the Sugar on a Stick Blueberry launch and this info will help us in that reflection. Sean On Wed, Oct 14, 2009 at 9:20 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: Hello, I've posted a short status report on the state of Book Reading in OLPC/Sugar. You can read it here: http://sayamindu.randomink.org/ramblings/2009/10/14/books-sugar-and-olpc/ There's also a video-cast of a modified Get Internet Archive Books activity, retrieving books from Feedbooks.com (it is already linked from the blog post, but it may not be visible in some browsers). You can download it from : http://dev.laptop.org/~sayamindu/get_books.ogv Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ 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
Re: [Sugar-devel] [IAEP] ASLO updates
On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote: [cc += dfarning, alsroot, syst...@] El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió: I've made some bug fixes to the new ASLO design, I've tested it lightly and it seems to work in all major browsers (even ie6). If you have a few moments, please test it out (download/upload activities, browse around) and let me know if you see any display bugs or major usability issues. http://activities-devel.sugarlabs.org/en-US/sugar/ All links to activity bundles appear to be broken :-( For example: http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail I'm not sure how to fix it, but I can imagine that it may be related with moving the activity bundles from their old location (/srv/www-sugarlabs/activities/files) to the upload directory (/srv/upload/activities/) done by Dfarning in order to enable Mirrorbrain. Earlier today, alsroot asked me to fix some permission issues that would prevent aslo from writing new activities in the new location. Thats intended to be so, activities-devel is just mysql copy of activities, I thought, it shouldn't affect activities-devel testing(but you can create new activity/version and it should be downloaded). also noticing that there's still a copy of the activities in the old location, and it is also bigger by 40MB! Thats because /srv/www-sugarlabs/activities/files contains some tmp directory, it shouldn't affect .xo downloading. /me is very confused :-/ Could anyone who was involved please write a short description of what was changed exactly? I'm only trying to reconstruct the current situation, not looking for a scapegoat. We just tried to utilize AMO feature when it lets user download public .xos from mirror sources and from files/ for other cases. Recently all .xo were downloaded from files/(even after creating symlink in /upload to files/).. and it was done from several attempts. For now we have two independent sources for .xo downloads: * /srv/www-sugarlabs/activities/files for not public activities and for 30min age public activities * mirrored /upload/activities for all public activities, after making new .xo public, ASLO uploads it to /upload/activities Hmm... well, perhaps we can learn something from this accident: The classic way to avoid the too many cooks syndrome would be to appoint a single official maintainer and make all the change requests go through him. However, I feel this solution would create lots of critical roles and ultimately defeat our ongoing attempts to decentralize system administration. Instead, we shall establish simple procedures to improve sysadmin coordination and communication. For example: 1) commit configuration changes in git along with a short description of what was done and why. We already have repositories for /etc and also and we could create more repos as needed; Yeah, for now, ASLO configs are stored only in ~activities/site/app/config 2) write a short report for systems@ when we make substantial changes to a service; 3) write or update the wiki documentation for important sysadm procedures such as installing a new instance of a service Use your common sense to decide what needs to be documented and how much detail is needed. At all costs, we want to avoid putting too much bureaucratic burden on volunteers because it's the most effective way to make them look for something more exciting to do. We could save time by coalescing steps (1) and (2): all we need to do is enabling a post-commit hook in the repositories that would send patches to systems-logs@ . We need to be extra careful not to expose passwords in this way. Any volunteers to write and test this procedure? Well, we don't need such ASLO specific administration 24x7, most of time it could be just regular file-permissions/apache/etc administration. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] [IAEP] ASLO updates
On Thu, Oct 15, 2009 at 07:34:50AM +, Aleksey Lim wrote: On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote: All links to activity bundles appear to be broken :-( For example: http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail I'm not sure how to fix it, but I can imagine that it may be related with moving the activity bundles from their old location (/srv/www-sugarlabs/activities/files) to the upload directory (/srv/upload/activities/) done by Dfarning in order to enable Mirrorbrain. Earlier today, alsroot asked me to fix some permission issues that would prevent aslo from writing new activities in the new location. Thats intended to be so, activities-devel is just mysql copy of activities, I thought, it shouldn't affect activities-devel testing(but you can create new activity/version and it should be downloaded). I've just symlinked /upload/activities to /srv/www-sugarlabs/activities-devel/files, so now it shouldn't confuse activities-devel testers. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
I've just tried an equivalent of this patch on OLPC build 802 on an XO-1, and it feels much more responsive. It affects all mouse-over menus in Sugar. I'm adding it to my list of patches that improve performance perceptions. /usr/lib/python2.5/site-packages/sugar/graphics/ -- James Cameron http://quozl.linux.org.au/ --- palette.py.orig 2009-10-15 07:37:11.0 + +++ palette.py 2009-10-15 07:39:13.0 + @@ -209,13 +209,13 @@ self._menu_content_separator = gtk.HSeparator() -self._popup_anim = animator.Animator(.5, 10) +self._popup_anim = animator.Animator(0, 10) self._popup_anim.add(_PopupAnimation(self)) -self._secondary_anim = animator.Animator(2.0, 10) +self._secondary_anim = animator.Animator(0.0, 10) self._secondary_anim.add(_SecondaryAnimation(self)) -self._popdown_anim = animator.Animator(0.6, 10) +self._popdown_anim = animator.Animator(0, 10) self._popdown_anim.add(_PopdownAnimation(self)) # we init after initializing all of our containers ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Zero-install-devel] Zero-calorie bundles?
El Tue, 13-10-2009 a las 20:47 +0100, Thomas Leonard escribió: How about getting together on IRC to exchange ideas regarding packaging strategies? I'd propose next Saturday @ 1500UTC [2], of course negotiable. Sounds like a good idea. Having a repository for Sugar-related apps makes sense and we can certainly help you with that. I'm sure you'll have useful feedback, and integration with Rainbow would be interesting. I'll try to join the IRC if I'm around. I forgot to mention the channel: #sugar-meeting. I'm not sure it solves our hosting problem, though, if the hosting is only for things relevant to Sugar. What kind of policy are you thinking of? We can offer abundant disk space and bandwidth to serve other Zero Install packages, as long as they are Free Software as defined by the FSF, since we are their guests. -- // 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] RFC: Kill the delayed menus for good
On Thu, Oct 15, 2009 at 08:58:12AM +0545, Daniel Drake wrote: It makes all menus that currently have a delay appear instantly? No, it doesn't. Try it. I think you'll like it. It is quite easy to run the cursor over the activity ring ... nothing appears until you stop for long enough. But what does appear appears without a two second delay! Consider it for deployment, Daniel. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] [IAEP] ASLO updates
On Thu, Oct 15, 2009 at 07:34:50AM +, Aleksey Lim wrote: On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote: [cc += dfarning, alsroot, syst...@] El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió: I've made some bug fixes to the new ASLO design, I've tested it lightly and it seems to work in all major browsers (even ie6). If you have a few moments, please test it out (download/upload activities, browse around) and let me know if you see any display bugs or major usability issues. http://activities-devel.sugarlabs.org/en-US/sugar/ All links to activity bundles appear to be broken :-( For example: http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail I'm not sure how to fix it, but I can imagine that it may be related with moving the activity bundles from their old location (/srv/www-sugarlabs/activities/files) to the upload directory (/srv/upload/activities/) done by Dfarning in order to enable Mirrorbrain. Earlier today, alsroot asked me to fix some permission issues that would prevent aslo from writing new activities in the new location. Thats intended to be so, activities-devel is just mysql copy of activities, I thought, it shouldn't affect activities-devel testing(but you can create new activity/version and it should be downloaded). also noticing that there's still a copy of the activities in the old location, and it is also bigger by 40MB! Thats because /srv/www-sugarlabs/activities/files contains some tmp directory, it shouldn't affect .xo downloading. /me is very confused :-/ Could anyone who was involved please write a short description of what was changed exactly? I'm only trying to reconstruct the current situation, not looking for a scapegoat. We just tried to utilize AMO feature when it lets user download public .xos from mirror sources and from files/ for other cases. Recently all .xo were downloaded from files/(even after creating symlink in /upload to files/).. and it was done from several attempts. For now we have two independent sources for .xo downloads: * /srv/www-sugarlabs/activities/files for not public activities and for 30min age public activities * mirrored /upload/activities for all public activities, after making new .xo public, ASLO uploads it to /upload/activities Hmm... well, perhaps we can learn something from this accident: The classic way to avoid the too many cooks syndrome would be to appoint a single official maintainer and make all the change requests go through him. However, I feel this solution would create lots of critical roles and ultimately defeat our ongoing attempts to decentralize system administration. Instead, we shall establish simple procedures to improve sysadmin coordination and communication. For example: 1) commit configuration changes in git along with a short description of what was done and why. We already have repositories for /etc and also and we could create more repos as needed; Yeah, for now, ASLO configs are stored only in ~activities/site/app/config hmm.. but what about passwords in ASLO configs 2) write a short report for systems@ when we make substantial changes to a service; 3) write or update the wiki documentation for important sysadm procedures such as installing a new instance of a service Use your common sense to decide what needs to be documented and how much detail is needed. At all costs, we want to avoid putting too much bureaucratic burden on volunteers because it's the most effective way to make them look for something more exciting to do. We could save time by coalescing steps (1) and (2): all we need to do is enabling a post-commit hook in the repositories that would send patches to systems-logs@ . We need to be extra careful not to expose passwords in this way. not sure, ASLO configs could be not obvious for others, so we need explanation in email anyway. Any volunteers to write and test this procedure? Well, we don't need such ASLO specific administration 24x7, most of time it could be just regular file-permissions/apache/etc administration. Maybe just reuse issue tracker, I mean it could be a good way from decentralization pov and all interested people can subscribe to bugs.sl.o email notifications. So all administration related tasks(not only ASLO) could be requested on bugs.sl.o at first. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] incremental activity update
On Thu, Oct 15, 2009 at 5:04 AM, Daniel Drake d...@laptop.org wrote: I know I myself hacked the image-builder script into this direction, but in hindsight I feel that it got too hacky and that was the wrong approach. It presented various surprises along the way and at the very end left me with the this is the wrong thing feeling. Would be interesting to know more on concrete issues (that lead to the feeling part :-) ). The Pilgrim path is too hard and brittle. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
On Tue, Oct 13, 2009 at 6:39 AM, Bernie Innocenti ber...@codewiz.org wrote: Zero Install appears to have identified reasonable compromises for many of these trade-offs. While I'm not yet claiming that z-i would be a (Keeping it in the Sugar side... ) I think it's a very good idea to look into a userdir-centric packaging system such as z-i. There are of course a few other alternatives, and very well considered critiques of these systems (from OS-centric packagers usually ;-) ) so we don't have to hope we've diagnosed all the potentiall pitfalls -- others have. So a couple of questions -- out of curiosity, no intention to start a flamefest. - Is anything making z-i specially interesting? - What pitfalls will our individual end users and deployment teams face with it? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugarizing an application
On Wed, Oct 14, 2009 at 13:33, Daniel Castelo dcastelo.sugarl...@gmail.com wrote: I am testing the client gnome-ppp to connect the Xo with a modem 3G. When I execute the client using consolehelper and pam (or the root user) the application looks without the sugar theme. When I execute the binary file of the client (/usr/sbin/gnome-ppp) it looks fine. And you want to create a Sugar activity with the functionality in gnome-ppp ? Or what is the final goal? Regards, Tomeu Thanks On Wed, Oct 14, 2009 at 9:57 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Oct 14, 2009 at 12:54, Daniel Castelo dcastelo.sugarl...@gmail.com wrote: Hi. When I execute an application written in C and gtk with a normal user (not the root user) it looks fine, I mean sugarized (for example with rounded entry text). But if i execute it with the root user it looks without the sugar theme. On what it depends? The Gtk+ theme is set per user, so if you run as root you are running it in a very different environment. If this is a problem for you, then we may be able to help if you explain what you are trying to do. 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 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] RFC: Kill the delayed menus for good
On Thu, Oct 15, 2009 at 03:49, Michael Stone mich...@laptop.org wrote: Tomeu wrote: On Wed, Oct 14, 2009 at 16:57, Michael Stone mich...@laptop.org wrote: Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Yay, more roadblocks and stereotyping! :) You shouldn't take this personal, most of Sugar contributors including me have done this in the past. humorI don't take it personally; I take it on behalf of oppressed contributors everywhere...!/humor (In other words, judging the patch by its author rather than by its text and its effects does seem to me to be a rather risky business. Your choice, though.) If you insist on thinking that I have something against you, then I will stop having this discussion with you. I'm really tired of you continuously bringing this as a problem but not hearing anyone else caring about your troubles contributing. I stand by what I said: substantial user experience changes will be considered only after discussion involving the design and deployment teams (which we are having now). This is not just for you but for anybody else that proposes patches for the modules that I maintain. Try going to a GNOME or KDE module and proposing that they accept such a patch so people can test it, they are going to laugh at your face. Maintenance is already a hard enough task, if the community thinks that a maintainer should also be accepting all patches, releasing them, packaging them, making soas spins, asking for feedback, reverting them, etc. Then I will be glad to pass maintenance to whoever is available to do these kinds of things. Regards, Tomeu I'm just saying that now might not be such a good idea any more to accept changes in the user experience without user feedback. Far better to accept the changes, get the user feedback on the changed versions, then revert the changes if they turn out to be inappropriate. Everyone will be happier. (That's my opinion, anyway.) Are you actually saying that you'd prefer either a) no patches or, b) patches that I think make the system worse? Yup, this is certainly absurd. I'm glad that we agree. If, say, Gary comes later and proposes a patch to revert yours, should I accept it in fear that I may discourage him otherwise? Yes, but in awareness rather than in fear, (though only unless you have an overriding reason not to.) Being concerned about developers proposing big user experience changes does not seem to me to meet that criterion. To my mind, overriding reasons not to include the patch is... * incorrect * illegal * an obviously bad idea * a subtly bad idea * more trouble than it's worth At best, it has been argued so far that merging the patch I showed to Bernie is a subtly bad idea because it leaves the obvious possible of refactoring of the context menu code to remove the use of the animation code unimplemented. In the middle, Eben expressed uncertainty on the basis of a specific vision and private memories. This shouldn't impede merging the patch; it should just encourage more testing and thought based on his experiences, vision, and thought experiment so that we get more data. At worst, it has been argued that merging the patch is an obviously bad idea because it was developed by a developer (me; who else was supposed to develop it?) engaged in critical dialogue with and reflection on the Sugar user experience (I do feel that it's better) via methods that I find congenial as opposed to by methods that I find prohibitively expensive. Did I miss any other positions in the debate? C'mon, I'm just asking that when substantial changes to the user experience are proposed, that we have some discussion that involves the design team and the deployments. Is this really so off? I'd call it more timid than off. Or at least inappropriately deferential to the wishes of the design team and the deployments who talk to you at the expense of receiving more contribution by making contribution more dynamic and fulfilling and therefore at the expense of exploring more possible Sugar experiences. Before I look at the patch I would like to know if there's agreement from people close to our users that this behavior change is desired. How can we get that? Well, trying it might be one good way to start. :) After that, shipping it in an explicit beta is another more heavyweight but nevertheless time-tested approach. You know how easy is making a spin of SoaS with such changes for people to try out, or are you saying that you want me to do this work for you? I'm saying three things; namely, that: 1. I trust that you and the other people on this list are empowered and able to make reasonable UI decisions when presented with clear alternatives, 2. Patches are an appropriate way of exchanging proposals for software modification and a good medium for discussion of those proposals, and
[Sugar-devel] Bolzano 2009 - Schedule draft
Hi, I have posted an initial schedule for the Sugar Camp at Bolzano after feedback from Walter, Sebastian, Tomeu, Aleksey and the Zeitgeist people. Please let me know, if you have things you want to present that are not yet part of the schedule or have any concerns or things I have overseen. http://wiki.sugarlabs.org/go/Marketing_Team/Events/Sugarcamp_Bolzano_2009#Schedule The Saturday and Sunday I have left open for free hacking. Many arrive on saturday during the day or on monday. For those there already, use the time and work on specific projects. Please add yourself to the wiki if you have not done so yet. Note as well when you arrive and leave. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
I take two points from this exchange: #1 User interaction changes are always subjective. Patches, requests, suggestions, etc. should not be submitted with duh as a rationale. They should be backed up with a clear rationale; better yet, hard data. #2 The Sugar UI is not sacred. There needs to be a process to collect and evaluate data, and to design and implement improvements. With changes to the user experience, writing the code is expected to be the simplest part of the process so the patch may be trivial, but acceptance may not. I could submit a patch changing the Home background color to a lovely blue; it would be trivial to apply and motivating for me, but not necessarily a good idea! The correct way to submit this patch is to file an enhancement bug, post the patch to the bug, and create a wiki page under http://wiki.sugarlabs.org/go/Features using the provided template. An improvement to this patch that would increase its likelihood of acceptance would be to make it a toggle. Even better would be to report delayed menu item clicks to a usability log server. Work with a deployment to distribute both versions randomly, analyze the results, and include that in the feature request. I'd like to put my designer hat on for a minute and offer an alternative to Bernie/Michael's patch and the current behavior: Any time the mouse hovers over a part of the screen with a delayed action, that part must immediately highlight itself. With the frame, that would be a 1px rectangle around the screen. With icons, this could be a border rectangle. Best, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Thu, Oct 15, 2009 at 14:47, Wade Brainerd wad...@gmail.com wrote: I take two points from this exchange: #1 User interaction changes are always subjective. Patches, requests, suggestions, etc. should not be submitted with duh as a rationale. They should be backed up with a clear rationale; better yet, hard data. #2 The Sugar UI is not sacred. There needs to be a process to collect and evaluate data, and to design and implement improvements. Agreed. With changes to the user experience, writing the code is expected to be the simplest part of the process so the patch may be trivial, but acceptance may not. I could submit a patch changing the Home background color to a lovely blue; it would be trivial to apply and motivating for me, but not necessarily a good idea! The correct way to submit this patch is to file an enhancement bug, post the patch to the bug, and create a wiki page under http://wiki.sugarlabs.org/go/Features using the provided template. An improvement to this patch that would increase its likelihood of acceptance would be to make it a toggle. Even better would be to report delayed menu item clicks to a usability log server. Work with a deployment to distribute both versions randomly, analyze the results, and include that in the feature request. This may be a bit too heavy process for practical purposes, I think there exists a vry wide space between what Michael asks and what you have written above. I think we would go to such a extreme only when we have already made a big change to the UI and some people wanted to revert it (for example move back the activity icons to the frame). A good middle point may be to have people who are in contact with Sugar-using children (both in the classroom and on their own) to explain how the change would affect the usage they have observed. Even better if the design team is available to explain the rationale and suggest alternatives. I'd like to put my designer hat on for a minute and offer an alternative to Bernie/Michael's patch and the current behavior: Any time the mouse hovers over a part of the screen with a delayed action, that part must immediately highlight itself. With the frame, that would be a 1px rectangle around the screen. With icons, this could be a border rectangle. I think this one would have a big impact on usability and may not be hard at all. 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] RFC: Kill the delayed menus for good
Tomeu, If you insist on thinking that I have something against you, then I will stop having this discussion with you. I insist only on the reasonableness of taking you literally at your word. Naturally, I'm quite certain that you have nothing against me that you don't also have against anyone else who is as damn persnickety as I am... except when you write otherwise. I'm really tired of you continuously bringing this as a problem but not hearing anyone else caring about your troubles contributing. Three points: 1. It makes sense that you're tired of hearing about it; I'm tired of it being a problem. 2. The phrase but not hearing anyone else caring... confuses me. I can't tell whether you mean that I'm deaf to other people caring, that no one else cares, or both. Both cases seem implausible to me, but evidence is always welcome. 3. My troubles contributing are adequately controlled for by avoiding sending actual patches. You saw this one only because Bernie said that he liked the effect when I showed it to him and because I told him that if he liked it, then he should recommend that others try it. (Actually, you might have seen it earlier when I mentioned it to you in IRC a few weeks ago, but I can easily understand how a single line of IRC traffic is easy to miss.) I stand by what I said: substantial user experience changes will be considered only after discussion involving the design and deployment teams (which we are having now). This is not just for you but for anybody else that proposes patches for the modules that I maintain. I understand but continue to question the usefulness of the decision given its obvious overhead and consequences. Enjoy the fruits of your choice. Try going to a GNOME or KDE module and proposing that they accept such a patch so people can test it, they are going to laugh at your face. Sugar is not GNOME or KDE (nor the kernel, where experience demonstrates that the pattern you refer to is actually fairly common). Consequently, we should find out what's right for Sugar. There's nothing wrong with you having one position which is different from mine. Maintenance is already a hard enough task, if the community thinks that a maintainer should also be accepting all patches, releasing them, packaging them, making soas spins, asking for feedback, reverting them, etc. Then I will be glad to pass maintenance to whoever is available to do these kinds of things. If you find such a person, then please consider it -- I think Sugar would benefit greatly from having a maintainership community with the resources to do those things in that order, as I suggested in more detail in the remaining part of my last email to which you didn't reply. Regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
yes, what is you exec overview/ why are you proposing to discard .xo bundling? or is this an option? With the XO 1.5 including a gnome desktop and just for development purposes, and environmental running environments having a broader base (read multi linux distro and even aspartamine) and multi windowing systems might be in order, but why is this 0install.net python solution worth considering? FoodForce2 runs from source better on Fedora without the XO bundling (maybe a porting progress issue) Learning python/ sugar/ xo development on a desktop is easier. sugar-jhbuild environment lets me run both environments at once where virtualization brings my machine to it's knees, Maybe I'm just a noob on the sugar-devel list, (and not subbed to the .sf.net list, so not even trying to send there) and expecting more of a business, case but sell me / us on it, please. I know there are next gen .rpm build from source like RPath, and .deb and packaging things, different parts of even the Linux/ *Nix family trees (can you say darwin/*bsd/ why isn't sugar running native on a mac) are rather territorial, and flame producing reglious wars, but even a then, why not use some other build from tarball type approach? On Thu, Oct 15, 2009 at 4:32 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Oct 13, 2009 at 6:39 AM, Bernie Innocenti ber...@codewiz.org wrote: Zero Install appears to have identified reasonable compromises for many of these trade-offs. While I'm not yet claiming that z-i would be a (Keeping it in the Sugar side... ) I think it's a very good idea to look into a userdir-centric packaging system such as z-i. There are of course a few other alternatives, and very well considered critiques of these systems (from OS-centric packagers usually ;-) ) so we don't have to hope we've diagnosed all the potentiall pitfalls -- others have. So a couple of questions -- out of curiosity, no intention to start a flamefest. - Is anything making z-i specially interesting? - What pitfalls will our individual end users and deployment teams face with it? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- DancesWithCars leave the wolves behind ;-) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
On Thu, Oct 15, 2009 at 11:05 AM, DancesWithCars danceswithc...@gmail.com wrote: yes, what is you exec overview/ why are you proposing to discard .xo bundling? or is this an option? I don't think that we're discussing discarding .xo bundling. I think we're discussing augmenting .xo bundling with 0install to bring in dependencies. My only question about 0install is how does it hold up when there is no infrastructure access? Can I still transfer a .xo bundle to someone under a tree and expect it to work? With the current apple-like include everything approach it works. -Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Bookreader] Status report on Bookreading
Thank everyone :-). If a demo version is required - you can download it from http://dev.laptop.org/~sayamindu/GetBooks-1.xo Thanks, Sayamindu On Thu, Oct 15, 2009 at 1:42 AM, Samuel Klein s...@laptop.org wrote: Ditto :) I will be showing off Sayamindu's new work at the Making Books Apparent event in San Francisco next Monday night. If any of you are in the area, let me know and I'll make sure you get an invitation. Now we need to encourage more people to organize OPDS servers of children's works, and tie this into the Rural Design Collective's work in that area. SJ On Wed, Oct 14, 2009 at 3:57 PM, raj kumar rku...@archive.org wrote: Excellent post and video, Sayamindu! Very, very good work. I'm excited about how easy it now is to discover and read books on the OLPC! Thank you so much for doing all the work to tie into the experimental IA aggregated OPDS feed. Your software is working great! -raj On Oct 14, 2009, at 12:20 PM, Sayamindu Dasgupta wrote: Hello, I've posted a short status report on the state of Book Reading in OLPC/Sugar. You can read it here: http://sayamindu.randomink.org/ramblings/2009/10/14/books-sugar-and-olpc/ There's also a video-cast of a modified Get Internet Archive Books activity, retrieving books from Feedbooks.com (it is already linked from the blog post, but it may not be visible in some browsers). You can download it from : http://dev.laptop.org/~sayamindu/get_books.ogv Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Bookreader mailing list bookrea...@lists.laptop.org http://lists.laptop.org/listinfo/bookreader ___ Bookreader mailing list bookrea...@lists.laptop.org http://lists.laptop.org/listinfo/bookreader ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
El Thu, 15-10-2009 a las 10:32 +0200, Martin Langhoff escribió: I think it's a very good idea to look into a userdir-centric packaging system such as z-i. There are of course a few other alternatives, and very well considered critiques of these systems (from OS-centric packagers usually ;-) ) so we don't have to hope we've diagnosed all the potentiall pitfalls -- others have. So a couple of questions -- out of curiosity, no intention to start a flamefest. - Is anything making z-i specially interesting? Honestly? I think the most interesting feature of Zero Install is that it has an active development community working to solve the same hard problems that we are facing with our XO bundles. RPM and Deb have even stronger development, of course, but they're focusing on different usecases and they also seem to be too associated with specific distributions. - What pitfalls will our individual end users and deployment teams face with it? I'm not sure how to answer this question, yet. Getting the Zero Install folks involved may bring in fresh expertise offering new ways to solve the problems on which we have been stalling for years. Let's give them a chance to prove their ideas. -- // 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] Zero-calorie bundles?
On Thu, Oct 15, 2009 at 6:57 PM, Bernie Innocenti ber...@codewiz.org wrote: Honestly? I think the most interesting feature of Zero Install is that it has an active development community working to solve the same hard problems that we are facing with our XO bundles. Ok - that's good. I am familiar with the limitations we are hitting with rpm and dpkg. What I truly wonder about is things like 'autopackage' and klik. See also the 'see also' section in http://en.wikipedia.org/wiki/Zero_Install - What pitfalls will our individual end users and deployment teams face with it? I'm not sure how to answer this question, yet. A while ago there was some serious discussion of the issues with these 'non-OS' pkg managers. Here is a tip of the iceberg - http://www.licquia.org/archives/2006/03/11/autopackage-goes-insane/ The discussion was heated, and sprawled across blogs. Good points were made. Before taking on something like z-i... it'd be worth understanding the good, bad and ugly and how it applies to us... Getting the Zero Install folks involved may bring in fresh expertise They'll know about z-i, not about the needs of Sugar or its users... hence the perspective I am mentioning. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] [IAEP] ASLO updates
I'll try to document how mirror brain is setup and how it affects other systems in the wiki this afternoon. Changes to devel, testing, or product activities.sl.o should not affect one another. They are three separate instances consisting of: 1. Separate code trees. 2. Separate database instances. 3. Separate file storage. Two variations of the file tree are stored. These trees are (I am using mozilla terminology for the trees): 1. Application tree. 2. Repo tree. Each instance has an individual application tree stored at www-sugarlabs/activitie-*/files. Each instance interact directly with its application tree. From a user pov this tree is call the sand box. Each instance can have an _optional_ repo tree. An instance interacts with its repo tree via the 'download server.' From a a user pov this tree is the set of downloadable files. Our confusion was because we were pointing the download server at the application tree via a symlink. When the download server was the same machine as the application server it worked correctly. Adding mirrorbrain forced us to clearly draw the line between the download server and the application server. Long term, it is good system design. Short term, a bug in mirrorbrain cause it to incorrectly handle symlinks in the vhost directory part. Moving forward-- 1. Work Flow -- What ever you decide for a work flow is fine. 2. A.sl.o modularization -- a.slo is design to split up into several pieces as it grows: 2.1 Application server. This is the primary php application. It can be split across multiple machines using mod_perbal. 2.2 Database server. This is the primary database. It can be split across multiple machines as necessary. There are limited to scalability due to db replication issues. 2.3 Download server. This is the primary download server. It can be scaled using various CDN techniques. 2.4 Memcache server. Memcach sits between the application server and the database. Memcache reduces database server load and is easier to scale than multiple database server. Currently, all of these pieces are sitting on sumjammer. As a result we were a bit hand wavy about the abstraction barriers between the pieces. Due to the improvements bernie and danny have done to sunjammer we are maxing out at 45% cpu usage. Due to mirror brain we have reduced our the bandwith usage on Sunjammer from between 100 and 150 GB per day to less than five GB. The big gain is that offloading the downloads reduces the cache churn and eth0 interupts on Sunjammer. Recommended growth roadmap-- Based on discussions with the AMO infrastructure team the recommend plans for grow are: 1. Split off download server. We have effectively done that via mirrorbrain. But at some point we will need to see about putting mirrorbrain on a separate machine. 2. Split off download server. At some point, we will need to put the database on a separate machine which will grow into cluster of machines. 3. Split off memcache server. At some point we will need to split off memcache machines. Memcache machines can just be a bunch of old machines with lots of memory. 4. Build multiple application servers. This is just a matter of using mod_perlbal to distribute across multiple servers. I have no idea when we are going to have to make the above changes. Current growth trajectory for a.sl.o is about 25% per months. But, this could change when: 1. SoaS buleberry comes out. 2. Sugar .86 starts to hit the street and the updater starts automatically pinging a.sl.o for updates. I do want to make sure that ever though a.slo. _looks_ like a black box, scaling a.sl.o is a solved problem. Hope this helps. david On Thu, Oct 15, 2009 at 3:04 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Oct 15, 2009 at 07:34:50AM +, Aleksey Lim wrote: On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote: [cc += dfarning, alsroot, syst...@] El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió: I've made some bug fixes to the new ASLO design, I've tested it lightly and it seems to work in all major browsers (even ie6). If you have a few moments, please test it out (download/upload activities, browse around) and let me know if you see any display bugs or major usability issues. http://activities-devel.sugarlabs.org/en-US/sugar/ All links to activity bundles appear to be broken :-( For example: http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail I'm not sure how to fix it, but I can imagine that it may be related with moving the activity bundles from their old location (/srv/www-sugarlabs/activities/files) to the upload directory (/srv/upload/activities/) done by Dfarning in order to enable Mirrorbrain. Earlier today, alsroot asked me to fix some permission issues that would prevent aslo from writing new activities in the new location. Thats intended to be so, activities-devel is just mysql copy
Re: [Sugar-devel] [Marketing] [Systems] [IAEP] ASLO updates
On Thu, Oct 15, 2009 at 19:13, David Farning dfarn...@sugarlabs.org wrote: 2. Sugar .86 starts to hit the street and the updater starts automatically pinging a.sl.o for updates. Yeah, this could have become a big problem. Thanks, 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
[Sugar-devel] Sugar oversight-board meeting announcment
We will have the first meeting of the newly elected 2009-2010 Sugar Labs oversight board at 14:30 UTC (10:30 EST) on Friday, Oct. 15, on irc.freenode.net #sugar-meeting Among the agenda items are: (1) to sing the praises of our outgoing board members; (2) to make sure that important board positions are filled; (3) to touch base re the Decision Panel; (4) to discuss changes to the Sugar trademark policy, and (5) general goal-setting for the year. 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] [IAEP] ASLO updates
El Thu, 15-10-2009 a las 07:34 +, Aleksey Lim escribió: We just tried to utilize AMO feature when it lets user download public .xos from mirror sources and from files/ for other cases. Recently all .xo were downloaded from files/(even after creating symlink in /upload to files/).. and it was done from several attempts. Hmm... I'm not sure Mirrorbrain would still work if you symlink away from the /srv/upload directory where it is active. To check, use wget on one of the URLs: you should see a 302 redirect before the download starts. Btw, we should start to get psychologically ready to move aslo to beamrider in the future or, better, cluster it on both machines. We could save time by coalescing steps (1) and (2): all we need to do is enabling a post-commit hook in the repositories that would send patches to systems-logs@ . We need to be extra careful not to expose passwords in this way. Any volunteers to write and test this procedure? Well, we don't need such ASLO specific administration 24x7, most of time it could be just regular file-permissions/apache/etc administration. Ok. For now we'll limit it to /etc only. -- // 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] Zero-calorie bundles?
On Thu, Oct 15, 2009 at 1:18 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Thu, Oct 15, 2009 at 6:57 PM, Bernie Innocenti ber...@codewiz.org wrote: Honestly? I think the most interesting feature of Zero Install is that it has an active development community working to solve the same hard problems that we are facing with our XO bundles. Ok - that's good. I am familiar with the limitations we are hitting with rpm and dpkg. What I truly wonder about is things like 'autopackage' and klik. Autopackage was the one I'd seen before, but forgot the name. After ranting on this thread this morning, I ran across http://0install.net/matrix.html which contains a mini ZeroInstall take on the Autopackage and other options. rPath.com is from some of the old Red Hat guys doing RPM one better, making appliances, somewhere between build systems and git, etc, afaict... but personally, I'm still stuck on the older hardware doesn't boot from usb, and cdr isos are very slow by comparison (a young person was complaining (some) when XO hardware was taken away and replaced with a sugar cdr on a regular laptop in the USA...). -- DancesWithCars leave the wolves behind ;-) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] New F11 for the XO-1 Build 8
http://wiki.laptop.org/go/F11_for_XO-1 http://dev.laptop.org/~smparrish/XO-1/builds/OS8 This release includes a fix for the black box in Gnome, an updated repository definition, and replaces Firefox with Midori. If you still want to use Firefox you can always install it by doing a yum install firefox as the root user. Enjoy! Steven Here is a list of updated packages. -atlas-sse-3.8.3-4.fc11.i586 +atlas-3.8.3-9.fc11.i586 -audit-1.7.13-1.fc11.i586 -audit-libs-1.7.13-1.fc11.i586 +audit-1.7.14-1.fc11.i586 +audit-libs-1.7.14-1.fc11.i586 -bind-libs-9.6.1-5.P1.fc11.i586 -bind-utils-9.6.1-5.P1.fc11.i586 +bind-libs-9.6.1-6.P1.fc11.i586 +bind-utils-9.6.1-6.P1.fc11.i586 -cpuspeed-1.5-10.fc11.i586 +cpuspeed-1.5-12.fc11.i586 -crda-1.1.0_2009.09.08-2.fc11.i586 -cronie-1.3-2.fc11.i586 +crda-1.1.0_2009.09.08-3.fc11.i586 +cronie-1.3-3.fc11.i586 -cups-libs-1.4-0.rc1.15.fc11.i586 +cups-libs-1.4.1-4.fc11.i586 -deltarpm-3.4-16.fc11.i586 +deltarpm-3.4-18.fc11.i586 -dhclient-4.1.0p1-4.fc11.i586 +dhclient-4.1.0p1-5.fc11.i586 -dnsmasq-2.46-2.fc11.i586 +dnsmasq-2.46-3.fc11.i586 -dracut-002-1.fc11.i586 +dracut-002-9.git99fd62e3.fc11.i586 -etoys-4.0.2279-1.fc11.noarch +etoys-4.0.2332-1.fc11.noarch -fedora-bookmarks-11-1.noarch -fedora-olpc-release-11-3.noarch +fedora-olpc-release-11-5.noarch -file-5.03-2.fc11.i586 -file-libs-5.03-2.fc11.i586 +file-5.03-3.fc11.i586 +file-libs-5.03-3.fc11.i586 -firefox-3.5.3-1.fc11.i586 -fuse-2.7.4-3.fc11.i586 -fuse-libs-2.7.4-3.fc11.i586 +fuse-2.8.1-1.fc11.i586 +fuse-libs-2.8.1-1.fc11.i586 +geoclue-0.11.1.1-0.6.20090310git3a31d26.fc11.i586 -gnome-settings-daemon-2.26.1-10.fc11.i586 +gnome-settings-daemon-2.26.1-11.fc11.i586 -gnumeric-1.8.4-2.fc11.i586 +gnumeric-1.8.4-3.fc11.i586 -gnutls-2.6.6-2.fc11.i586 +gnutls-2.6.6-3.fc11.i586 -gstreamer-0.10.24-1.fc11.i586 -gstreamer-plugins-base-0.10.24-1.fc11.i586 +gstreamer-0.10.25-1.fc11.i586 +gstreamer-plugins-base-0.10.25-1.fc11.i586 -gstreamer-plugins-good-0.10.15-4.fc11.i586 +gstreamer-plugins-good-0.10.16-1.fc11.i586 -gstreamer-tools-0.10.24-1.fc11.i586 +gstreamer-tools-0.10.25-1.fc11.i586 -iw-0.9.15-1.fc11.i586 +iw-0.9.17-3.fc11.i586 -kernel-2.6.30_xo1-20090919.0116.1.olpc.d2189d4.i586 -kernel-firmware-2.6.30_xo1-20090919.0116.1.olpc.d2189d4.i586 +kernel-2.6.30_xo1-20091009.1735.1.olpc.69c8c87.i586 +kernel-firmware-2.6.30_xo1-20091009.1735.1.olpc.69c8c87.i586 -libv4l-0.6.1-1.fc11.i586 +libv4l-0.6.2-1.fc11.i586 -libxml2-2.7.4-2.fc11.i586 -libxml2-python-2.7.4-2.fc11.i586 +libxml2-2.7.6-1.fc11.i586 +libxml2-python-2.7.6-1.fc11.i586 -libxslt-1.1.25-1.fc11.i586 +libxslt-1.1.26-1.fc11.i586 +midori-0.1.10-1.fc11.i586 -nautilus-2.26.3-3.fc11.i586 -nautilus-extensions-2.26.3-3.fc11.i586 +nautilus-2.26.4-2.fc11.i586 +nautilus-extensions-2.26.4-2.fc11.i586 -newt-0.52.10-3.fc11.i586 -newt-python-0.52.10-3.fc11.i586 +newt-0.52.10-4.fc11.i586 +newt-python-0.52.10-4.fc11.i586 +nodoka-theme-gnome-0.3.90-3.fc11.noarch -openldap-2.4.15-5.fc11.i586 +openldap-2.4.15-6.fc11.i586 -perl-5.10.0-73.fc11.i586 -perl-libs-5.10.0-73.fc11.i586 -perl-Module-Pluggable-3.60-73.fc11.i586 -perl-Pod-Escapes-1.04-73.fc11.i586 -perl-Pod-Simple-3.07-73.fc11.i586 -perl-version-0.74-73.fc11.i586 +perl-5.10.0-82.fc11.i586 +perl-libs-5.10.0-82.fc11.i586 +perl-Module-Pluggable-3.90-82.fc11.i586 +perl-Pod-Escapes-1.04-82.fc11.i586 +perl-Pod-Simple-3.07-82.fc11.i586 +perl-version-0.74-82.fc11.i586 +python-BeautifulSoup-3.0.7a-1.fc11.noarch +python-lxml-2.2.2-1.fc11.i586 +pywebkitgtk-1.1.6-2.fc11.i586 -rpm-4.7.1-1.fc11.i586 -rpm-libs-4.7.1-1.fc11.i586 -rpm-python-4.7.1-1.fc11.i586 +rpm-4.7.1-3.fc11.i586 +rpm-libs-4.7.1-3.fc11.i586 +rpm-python-4.7.1-3.fc11.i586 -setup-2.8.3-1.fc11.noarch +setup-2.8.3-2.fc11.noarch -shared-mime-info-0.60-3.fc11.i586 +shared-mime-info-0.60-4.fc11.i586 -smartmontools-5.38-13.fc11.i586 -sos-1.8-16.fc11.noarch +smartmontools-5.38-18.fc11.i586 +sos-1.8-17.fc11.noarch -taglib-1.5-9.fc11.i586 +taglib-1.6-2.fc11.i586 -totem-2.26.3-5.fc11.i586 -totem-gstreamer-2.26.3-5.fc11.i586 -totem-mozplugin-2.26.3-5.fc11.i586 -totem-pl-parser-2.26.2-2.fc11.i586 +totem-2.26.3-6.fc11.i586 +totem-gstreamer-2.26.3-6.fc11.i586 +totem-mozplugin-2.26.3-6.fc11.i586 +totem-pl-parser-2.26.3-1.fc11.i586 -tzdata-2009m-1.fc11.noarch +tzdata-2009m-2.fc11.noarch -wavpack-4.50.1-3.fc11.i586 +wavpack-4.60-1.fc11.i586 +webkitgtk-1.1.10-1.fc11.i586 -xapian-bindings-python-1.0.15-1.fc11.i586 -xapian-core-libs-1.0.15-1.fc11.i586 +xapian-bindings-python-1.0.16-1.fc11.i586 +xapian-core-libs-1.0.16-1.fc11.i586 -xorg-x11-server-common-1.6.4-0.1.fc11.i586 +xorg-x11-server-common-1.6.4-0.3.fc11.i586 -xorg-x11-server-Xorg-1.6.4-0.1.fc11.i586 +xorg-x11-server-Xorg-1.6.4-0.3.fc11.i586 -xz-4.999.8-0.8.beta.20090817git.fc11.i586 -xz-libs-4.999.8-0.8.beta.20090817git.fc11.i586 -xz-lzma-compat-4.999.8-0.8.beta.20090817git.fc11.i586 +xz-4.999.9-0.1.beta.20091007git.fc11.i586 +xz-libs-4.999.9-0.1.beta.20091007git.fc11.i586
[Sugar-devel] UI thoughts from today's session at the GPA
The Journal Icon in an activity should open the dialog box for feedback. The Stop Icon should not. Resume by default should happen if the activity is already open. Start new should be the default if there is no instance of that activity already open. It was very confusing and distracting to have to clear out previous work, from 2 weeks ago, out of turtle art before they started on today's assignment. In Turtle Art the Save a Snapshot icon should be the Eye cause it saves an image right? It looks too much like save to Journal right now. -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Before I look at the patch I would like to know if there's agreement from people close to our users that this behavior change is desired. How can we get that? How about users (me) proposing big user experience changes by asking a developer (Michael) why the fuck does this UI take so goddamned long to react? Also, define our users. Is it people using Sugar? Is it people using XOs? Is it people other than you? I'll gladly put myself into any of these categories if it makes you happy. Eben wrote: The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. 1) For whom? What about people who know how to recognize English letters and words better than they remember what an obscure picture means? Because you've failed on that front. 2) Good luck. Sincerely. I hope that if that's still your goal that it's actually possible. I'm personally not convinced, but only because I haven't yet seen a demonstration that shows progress on that front. Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. Jesus, why? Think about what you just said for a moment. Why might someone wait for the palette to appear before clicking? Probably because they want to see what's on the palette! The situation of the palette is that all it takes is one accident to discover that hovering shows useful information. And with the knowledge that the palette shows useful information, and that hovering shows the palette, it is reasonable that one might just engage in the described behavior. Either make the useful information available without the contextual menu or make the current expected behavior more responsive. Removing the delay pushes us, I fear, even farther away from an interface in which nice friendly large clickable icons can be directly manipulated and encourages every action to be done through a contextual menu with a bunch of text in it. Is that really what we want kids to face? So what you're saying is that you want to force children to use the system in a way that you just said is contrary to what THEY actually want to do. Perhaps. What would you define as the ailment, yourself? The primary intent was to encourage use of a direct interaction model, in which palettes we're supposed to play a big role. When it turned out that young kids, who didn't read, and who didn't have motor skills for selecting form the palettes, we aimed to reduce accidental invocation of them without entirely eliminating discovery by increasing the delay. Many kids have motor skills, and the ones that don't initially are remarkably good (being kids) at developing motor skills that they don't yet have. Many kids also read. In fact, let's cut into some real deep philosophy stuff here... The idea that the XO laptop is mainly for kids who can't read is completely bogus. Now, maybe you're thinking of other children when you say this, but I prefer to first consider the main existing userbase. Laptops which have Sugar installed on them are primarily located in schools and are used for education. It is kind of ridiculous to say Well, you don't actually need to know how to read to use the laptops, so we should make the interface not require reading. when the truth is that, for most activities that have any educational merit, you DO need to read and you need to read things significantly more complicated than activity names. Most of the people who use Sugar for most of the time WILL know how to read. Daniel Drake wrote: It makes all menus that currently have a delay appear instantly? Not even close. On the XO sitting next to me it still feels like over a second. There appears to actually be ANOTHER delay somewhere that was not modified at all, because the UI takes the same amount of time to respond with the change on both an XO and on a significantly more powerful laptop. What is noticable, however, is that it just doesn't feel like things are craaw-aww-aawwwaaawww-ling (ling) after the change, because before the user was met with a multi-stage, phased delay, whereas now the delay is brief and only up front. If you haven't yet, you really need to at least try it. All of this I don't like it, but I haven't actually tried it stuff is just unhelpful. Sincerely, Avi Kelman ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Should we care about non readers and kids with motor skill issues? was - Re: RFC: Kill the delayed menus for good
Perhaps. What would you define as the ailment, yourself? The primary intent was to encourage use of a direct interaction model, in which palettes we're supposed to play a big role. When it turned out that young kids, who didn't read, and who didn't have motor skills for selecting form the palettes, we aimed to reduce accidental invocation of them without entirely eliminating discovery by increasing the delay. Many kids have motor skills, and the ones that don't initially are remarkably good (being kids) at developing motor skills that they don't yet have. Many kids also read. In fact, let's cut into some real deep philosophy stuff here... True. But all kids matter. Including the nonreaders, the ones going to schools that are not taught in their native language, the ones for whom reading is a struggle, the dyslectics. Also I really disagree about the developing motor skills. I think developing motor skills is a developmental thing that goes at different paces. I see kids that can get the concepts of Sugar but who struggle with clicking the blocks together in Turtle Art. I think they are perfectly normal kids who will eventually have perfectly adequate motor skills for normal computing. Providing them with a system that is as easy as possible for them while those motor skills are developing should be one of our missions. The idea that the XO laptop is mainly for kids who can't read is completely bogus. Now, maybe you're thinking of other children when you say this, but I prefer to first consider the main existing userbase. Laptops which have Sugar installed on them are primarily located in schools and are used for education. It is kind of ridiculous to say Well, you don't actually need to know how to read to use the laptops, so we should make the interface not require reading. when the truth is that, for most activities that have any educational merit, you DO need to read and you need to read things significantly more complicated than activity names. Most of the people who use Sugar for most of the time WILL know how to read. I disagree on this too. I think there a host of activities that nonreaders could use in Sugar. Paint, Colors, Jingsaw, Flipsticks, Write (writing a great way to learn to read), speak, many GCompris Games, Calculate, books that are read to you, Browse if you share a favorited website. In fact if you share a started activity then you further expand the number of things a nonreader could do. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Memorize 33 is buggy - what should I do?
I doubt this is a SoaS only problem but I haven't tested it on an XO Tickets - 1055, 1503 1503 is a total blocker for using Memorize and 1055 is going to give me hell in the field trying to get kids not clear that inviting face. Maybe revert a.sl.o to a previous version? I'm going in to work on the Sticks tomorrow afternoon and I'm going to have to boot and fuss with each one, which will be hours of work, so it would be great to do as much as I can at once. If reverting seems like the right choice it would be great if I could have it for tomorrow. Thanks! Caroline -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Thu, Oct 15, 2009 at 10:09 PM, Avi fiendi...@gmail.com wrote: Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Before I look at the patch I would like to know if there's agreement from people close to our users that this behavior change is desired. How can we get that? How about users (me) proposing big user experience changes by asking a developer (Michael) why the fuck does this UI take so goddamned long to react? Also, define our users. Is it people using Sugar? Is it people using XOs? Is it people other than you? I'll gladly put myself into any of these categories if it makes you happy. I think we'd all agree that the primary audience for Sugar is children of varied age groups and levels of education, and that audience should be considered first in terms of the user experience. I'm not suggesting, of course, that the rest of us aren't also users with valid input and experiences, or that this proposed patch was submitted without the best interests of that audience, or at least a reasonable portion of that audience, in mind. I also don't believe that Tomeu was stating a challenge of any kind, or insinuating that no one other than Michael was likely to have a positive response to the proposed change. The suggestion was that we collect feedback from many people, yourself included, and also from children in our primary audience and the teachers and instructors who work with them daily. In that regard, thank you for your feedback; it would be more constructive, of course, if you could provide it without the profanity and apparent disgust. Eben wrote: The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. 1) For whom? What about people who know how to recognize English letters and words better than they remember what an obscure picture means? Because you've failed on that front. For children! And actually, I agree with you. In many cases text is minimized more than I would like it to be. Clearly it's beneficial for those learning to read to see associations of words and icons, and words are naturally useful to those who already can. 2) Good luck. Sincerely. I hope that if that's still your goal that it's actually possible. I'm personally not convinced, but only because I haven't yet seen a demonstration that shows progress on that front. Honestly, I think we've come relatively close. Would you strongly disagree? It's possible to create new activities, resume past activities, join collaborative activities, connect to networks, participate in activities, copy, paste, and stop activities with the use of primary actions only. I'm not suggesting that the full power of the UI is available without the need for seeing any text, but I am suggesting that there are a great many things you can do with Sugar without needing to use the secondary actions and tools available in palettes. If there are basic functions or actions that are frequently needed that aren't exposed as primary actions, it would be useful to identify those areas in order to make improvements. Do you have any suggestions? Finding that many kids were actually waiting for the palette to appear always, instead of, for instance, simply clicking on an activity icon to join it, encouraged us to INcrease the delay on the palettes to help emphasize this as a secondary mechanism for interaction. Jesus, why? Think about what you just said for a moment. Why might someone wait for the palette to appear before clicking? Probably because they want to see what's on the palette! The situation of the palette is that all it I was not precise enough in my statement. Upon observation, many children were waiting for the palette exclusively to select the first option within it, which is the primary action that a click on the object itself would also invoke. They were NOT attempting to access the secondary functionality, but instead, due to the appearance of the palette, assumed that this was the only means of interaction. As Michael correctly points out, the contextual menus are indeed an inferior solution to direct interactions, since they require finer motor skills (and are difficult with poor trackpads, such as those on XOs) and movement away from the object they wish to interact to a secondary target within the menu. The icons are larger targets, easy to click without delay, and would have saved children both time and aggravation had they learned to act upon them directly. takes is one accident to discover that hovering shows useful information. And with the knowledge that the palette shows useful information, and that hovering shows the palette, it is reasonable that one might just engage in the described behavior. Either make the useful information available without the contextual menu or make the current expected behavior more responsive. I think it may be useful to show the
Re: [Sugar-devel] incremental activity update
2009/10/15 Martin Langhoff martin.langh...@gmail.com: Would be interesting to know more on concrete issues (that lead to the feeling part :-) ). I guess the turning point in my thinking was when I realised that I had to update the .contents file inside the image after making non-activity customizations. This was after we had deployed this buggy image in the field. My realisation was that the more things we do with the image-builder script, the more complications we will have to duplicate from the real build system. And sometimes we might only discover the importance of those things when it is too late. The Pilgrim path is too hard and brittle. Have you tried to set it up? I haven't, but I get the impression from the team here that it is not as bad as you might expect. I'm sure it's not where we'd like it though. Looking forward, the F11 build system is easy to get running. I feel confident it's the kind of thing that can be documented on a single wiki page, which is my general threshold for [some] deployments can do it :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
2009/10/15 James Cameron qu...@laptop.org: No, it doesn't. Try it. I think you'll like it. It is quite easy to run the cursor over the activity ring ... nothing appears until you stop for long enough. But what does appear appears without a two second delay! OK then, that sounds a lot better. I'm surprised that this point wasn't raised earlier. Given that this thread is largely about process, let me throw in one more point then: all patches should be accompanied with a good description of the change that they actually make :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
El Fri, 16-10-2009 a las 09:44 +0545, Daniel Drake escribió: OK then, that sounds a lot better. I'm surprised that this point wasn't raised earlier. Given that this thread is largely about process, let me throw in one more point then: all patches should be accompanied with a good description of the change that they actually make :) +1, but in this case this was just an RFC meant to let people test the new behavior and comment on it. Surprisingly, a lot of feedback came from people who had not actually tried the patch or even *looked* at it! Lack of expertise is not a good excuse as we claim that even children could make changes to Sugar. Here's Michael's patch again (attached below). As can be seen, it's really as trivial as changing just 3 bytes in two files (it's really 3 changed bytes and 1 added byte, but it could be done in just 3 moves :-). One could also edit the files in-place from a SoaS or XO image: vi /lib/python2.6/site-packages/sugar/graphics/palette.py +106 vi /lib/python2.6/site-packages/sugar/graphics/palettewindow.py +151 From: Michael Stone mich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. --- src/sugar/graphics/palette.py |2 +- src/sugar/graphics/palettewindow.py |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/sugar/graphics/palette.py b/src/sugar/graphics/palette.py --- a/src/sugar/graphics/palette.py +++ b/src/sugar/graphics/palette.py @@ -103,7 +103,7 @@ class Palette(PaletteWindow): self._menu_content_separator = gtk.HSeparator() -self._secondary_anim = animator.Animator(2.0, 10) +self._secondary_anim = animator.Animator(0.0, 10) self._secondary_anim.add(_SecondaryAnimation(self)) # we init after initializing all of our containers diff --git a/src/sugar/graphics/palettewindow.py b/src/sugar/graphics/palettewindow.py --- a/src/sugar/graphics/palettewindow.py +++ b/src/sugar/graphics/palettewindow.py @@ -148,10 +148,10 @@ class PaletteWindow(gtk.Window): self._up = False self._old_alloc = None -self._popup_anim = animator.Animator(.5, 10) +self._popup_anim = animator.Animator(0.0, 10) self._popup_anim.add(_PopupAnimation(self)) -self._popdown_anim = animator.Animator(0.6, 10) +self._popdown_anim = animator.Animator(0.0, 10) self._popdown_anim.add(_PopdownAnimation(self)) gobject.GObject.__init__(self, **kwargs) -- 1.5.6.5 -- // 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
