[Sugar-devel] [Karma] updating jsdoc for Karma
I changed some of the basic stuff in jsdocs but I still need Felipe's help when he gets a chance. http://karma.sugarlabs.org/docs/ I got rid of the confusing Jquery-Anonymous- prefix that was in front of a lot of classes. I will take a look again at it tomorrow. Felipe, you used the @memberOf_ tag in a number of places. Does that do anything different from @memberOf which doesn't have the trailing _ ? -- Bryan W. Berry Senior Engineer OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Assorted Debian+Sugar bugs
Hi again, On Tue, Oct 13, 2009 at 07:37:07PM -0400, Michael Stone wrote: On Mon, Oct 12, 2009 at 07:52:11PM -0400, Michael Stone wrote: Jonas co: I just wanted to report a couple of regressions that I found today while trying out sugar-0.84 on Sid. In no particular order: Thanks for reporting this. You're very welcome; thanks again for your hard work packaging sugar! Even better, however, is if you file issues like this as proper bugreports. I haven't diagnosed the causes of these issues so I don't actually know what packages are at fault yet; I'm just reporting behavioral regressions. Consequently, I don't know what packages to file the bugs against. :) I understand, but don't let that discourage you: file the issues, as separate as you feel they make sense to split, against some - any - package you feel is related to the issue. It is easy later on to reassign to another package if that turns out to make more sense. And it is easy to merge issues together (splitting is possible too, but little more work). Problems experienced using a specific activity are probably best filed against the package containing that activity (e.g. sugar-pippy-activity or sugar-browse-activity-0.84). Only package that would be bad to file against is perhaps that education-desktop-sugar package, as I would not notice bugs filed there and I suspect noone else will either. I will respond here, cross-posted to both list, to respect your choice of communication platform. But there is a higher risk that your information will not get tracked and the issues not solved by doing it this way. By all means, feel free to enter the information into the tracker of your choice. I will be happy to follow your lead. I simply do not wish to file reports with faulty information. I can do that, but a) it is more work, b) it is more polite to play by the communication style of the initiator, causing me to *both* have this thread going *and* start a new one through the BTS which risks this thread stealing focus from the other one and thus c) draining attention away from where bug solving happens. (exact same is most probably true about Sugarlabs and OLPC bug trackers, and I am guilty of not engaging very well with those either) The more work a) it not (only) that work is passed from you to me, but that the reportbug tool bootstraps new bugreports elegantly, attaching you as bugreporter, gathering valuable details about your system, and guiding you through a few questions to improve effective processing. Thing is, filling in data is only part of the process. The more valuable part (in many cases) is a continued dialogue with the bugreporter - and with others chiming in later with additional info, something that is encouraged by discussion-style communication which feels natural in emails. A thing that I love about the Debian BTS is that it is email-based, dynamically creating a mailinglist for each bugreport. This makes ongoing discussion with the bugreporter quite fluent, unlike (IMHO) most web-based systems. Others less fluent with email may obviously disagree with me on that, but I suspect most _developers_ are fluent in email, and in my opinion issue tracking should serve developers more than users. A user-friendly pendant to an issue tracker would IMO be a different thing, one that e.g. allowed users to let off steam even if irrelevant to the developers (similar to an issue tracker dealing with details of absolutely no interest to the user). You may, however, be interested to know that, as of yesterday, sugar-0.86 depends on substantially more material than sugar-0.84. (To the tune of 300 MB more, I think.) Oh my :-( A few days ago I installed a smallest-possible install of (the Debian-packaged parts of) Sugar 0.86. I am not yet satisfied with the configurations, and have not gotten rid of some old cruft, but I believe it required less than 200MB, including X11, GNU and BSD utilities and the kernel. If stripping unused locales I can probably save another 50MB. Maybe I am oldfashioned, but I still find it a worthy challenge to squeeze a full system into 256MB or 512MB USB sticks. P.S. - Please also find attached the output of dpkg -l run from inside my testing chroot. This chroot was constructed by the code in the sugar branch of http://dev.laptop.org/git/users/mstone/puritan with conf/distro == debian and conf/debian/distro == sid. Ahem, does this mean that you did not in fact use a Debian system but some homecooked lookalike? I test sugar in chroots so as to be able to efficiently generate reproducible results across multiple distros. My debian chroots are constructed with debootstrap, as is apparent in the debian.mk Makefile in source code that I mentioned. Sounds interesting (as I would expect from you!) I do still, however, recommend you to mention any such specialties about your environment when filing bugreports. Yes, some
[Sugar-devel] incremental activity update
Hi, At OLE Nepal we have difficulties with updating activities because our main educational activity is so huge. Aayush Poudel implemented an incremental activity update which I have now merged with the standard software updater. When updating activities and content, the updater now only downloads the files of the new activity that have changed, greatly reducing time and bandwidth needed for updates. Patches at http://dev.sugarlabs.org/ticket/1499 We're also adding the patch I used in paraguay so that the updater does not try to go online when the school server has an activity available: http://dev.laptop.org/ticket/9259 I hope this is useful for other deployments too! 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
On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) BTW, Michael and I have a small disagreement on how a maintainer should react to the present patch. From a purely functional PoV, this patch is short, correct and low impact. Yeah, but... who's ever going to clean up after it if we do not demand the cleanup to be merged atomically with the patch that opens the need for it? Once the patch is in, the maintainer would no longer have a stick to brandish while saying now eat your veggies!. (Michael replies: This is a flawed position because it leads to absurd conclusions. More specifically, it actively discourages the current contributor from submitting more patches by denying the satisfaction of seeing their existing patch merged, delays the deferral of a correct and believable patch that introduces behavior you yourself describe as 'desirable' and, last but not least, misses an opportunity to involve inexperienced contributors by providing appropriate on-ramp bugs like the proposed refactoring.) 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? 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
Re: [Sugar-devel] incremental activity update
On Wed, Oct 14, 2009 at 11:43, Daniel Drake d...@laptop.org wrote: Hi, At OLE Nepal we have difficulties with updating activities because our main educational activity is so huge. Aayush Poudel implemented an incremental activity update which I have now merged with the standard software updater. When updating activities and content, the updater now only downloads the files of the new activity that have changed, greatly reducing time and bandwidth needed for updates. Patches at http://dev.sugarlabs.org/ticket/1499 We're also adding the patch I used in paraguay so that the updater does not try to go online when the school server has an activity available: http://dev.laptop.org/ticket/9259 I hope this is useful for other deployments too! Wonder how we could make it easier for other deployments to benefit from these changes. Do you have plans to push the changes to the sugar-update-control repo and spin new F9 rpms? 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] incremental activity update
2009/10/14 Tomeu Vizoso to...@sugarlabs.org: Wonder how we could make it easier for other deployments to benefit from these changes. Do you have plans to push the changes to the sugar-update-control repo and spin new F9 rpms? No - my time is too tight and at least for Paraguay and Nepal it's easier to apply customizations as patches rather than to add RPMs. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugarizing an application
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? Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] MANIFEST experiments
On 14.10.2009, at 13:44, Daniel Drake wrote: Today I ran a quick experiment on OLPC OS v8.2.1, based on the question: what are the activity MANIFEST files used for? I see sugar frequently complaining about MANIFEST inconsistencies in the logs, but I don't recall seeing it act on these inconsistencies in any way. I noticed that it even logs such inconsistencies during startup, meaning that it must be checking every file in every activity during a regular boot... So, I reflashed 2 XOs, booted for the first time, entered a name. On one, I modified sugar.bundle.ActivityBundle.read_manifest() to be a no-op, then turned it off. On the other, I just turned it off. Then I powered both on at the same time and started a stopwatch. I measured how long it takes for the XOs to reach the stage of boot where the XO stick figure and the activity icons are visible. The one with the modification reached this point *55* seconds faster than the other one! It basically zeroes the time where you can see the XO stick figure on screen but the activity icons on the home view have yet to appear. This was using OLE Nepal's customized build which includes a big activity with many manifest errors, so the difference might be less elsewhere. Tomeu points out that this behaviour has been improved in more recent sugar versions to the point where manifest checking probably is not happening in the startup path, but personally I question why we are even checking at all. Perhaps we should rip out all that code and leave MANIFESTs purely as a tool for developers to specify which files get included in a bundle or something like that. I did indeed think that's the entire purpose of it. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugarizing an application
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. 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-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Turtle Art-74
Activity Homepage: http://activities.sugarlabs.org/addon/4027 Sugar Platform: from 0.82 to 0.86 Download Now: http://activities.sugarlabs.org/downloads/version/29278 Release notes: * auto-load start block for new projects * fixed bug with reloading descriptions from Journal * added hover help to command-line version * initiate the import Python chooser when Python block is clicked * saving pastable code to html export * fixed some problems in export to HTML code Reviewer comments: Trusted activity Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
A word of initial warning: please turn on your sense of the absurd before reading. This response is written with a deep sense of amusement, rather than angst. Tomeu wrote: I'm more concerned about developers proposing big user experience changes because they feel it's better. Yay, more roadblocks and stereotyping! :) Are you actually saying that you'd prefer either a) no patches or, b) patches that I think make the system worse? 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. Failing that option, you likely need to find some product specialists. ... For what it's worth, I do view this patch as a UI bandaid to the underlying problem that hover-to-click-somewhere-else is the wrong UI affordance for the home screen to use in supporting discovery of and access to variant or associated behaviors. The patch is, however, still a big improvement that is available today. Now, as for what better look like: treat each view has having a primary layout algorithm for Sugar-level UI actions. This algorithm should effectively arrange logically related groups of capabilities as determined by metadata attached to the capabilities and as determined by the current filtering criteria for the view. In actual activities, this layout algorithm is the new toolbar approach. The filtering criteria are hover-or-click on an expandable toolbar item. In the circle view, I'd like to see the layout algorithm expanded to lay out arcs of smaller option icons each with the same prelighting and saturation behavior as partial halos around the exterior perimeter of the activity icons. Naturally, there are some obvious interesting extensions involving zoom effects and more subtle saturation behaviors. Lastly, it seems to me that a similar approach might also be effective in the mesh view and around the central XO-figure. Kind regards, Michael ___ 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 10/13/2009 04:36 AM, Bernie Innocenti wrote: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001 From: Michael Stonemich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. Can you describe what the patch will change from the user point of view? Is this to get rid of the delayed build up of palettes when hovering over icons? You can use right click to get the menu immediately. The delay is on purpose. Regards, 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
On Wed, Oct 14, 2009 at 7:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) BTW, Michael and I have a small disagreement on how a maintainer should react to the present patch. From a purely functional PoV, this patch is short, correct and low impact. Yeah, but... who's ever going to clean up after it if we do not demand the cleanup to be merged atomically with the patch that opens the need for it? Once the patch is in, the maintainer would no longer have a stick to brandish while saying now eat your veggies!. (Michael replies: This is a flawed position because it leads to absurd conclusions. More specifically, it actively discourages the current contributor from submitting more patches by denying the satisfaction of seeing their existing patch merged, delays the deferral of a correct and believable patch that introduces behavior you yourself describe as 'desirable' and, last but not least, misses an opportunity to involve inexperienced contributors by providing appropriate on-ramp bugs like the proposed refactoring.) 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? People could take both versions to a group of kids and video how it goes. 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 -- 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
In marketing parlance, these would be called focus groups and are a very effective and quick way to get feedback. The group I did at my kids' school last June (http://lists.sugarlabs.org/archive/marketing/2009-June/001625.html) immediately showed for example the problems kids had with quitting Activities. Sean On Wed, Oct 14, 2009 at 6:15 PM, Caroline Meeks solutiongr...@gmail.com wrote: On Wed, Oct 14, 2009 at 7:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) BTW, Michael and I have a small disagreement on how a maintainer should react to the present patch. From a purely functional PoV, this patch is short, correct and low impact. Yeah, but... who's ever going to clean up after it if we do not demand the cleanup to be merged atomically with the patch that opens the need for it? Once the patch is in, the maintainer would no longer have a stick to brandish while saying now eat your veggies!. (Michael replies: This is a flawed position because it leads to absurd conclusions. More specifically, it actively discourages the current contributor from submitting more patches by denying the satisfaction of seeing their existing patch merged, delays the deferral of a correct and believable patch that introduces behavior you yourself describe as 'desirable' and, last but not least, misses an opportunity to involve inexperienced contributors by providing appropriate on-ramp bugs like the proposed refactoring.) 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? People could take both versions to a group of kids and video how it goes. 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 -- 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 ___ 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 Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer si...@schampijer.de wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001 From: Michael Stonemich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. Can you describe what the patch will change from the user point of view? Is this to get rid of the delayed build up of palettes when hovering over icons? You can use right click to get the menu immediately. The delay is on purpose. We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. 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. A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. 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? Just for fun, I might suggest an alternate possibility which actually decreases the discoverability of the secondary palette. We could reveal the primary palette (label) on a delay as we do now, with some indication of more options that can be clicked to expand the menu to reveal the secondary items. This would provide the (essential) primary palette as a label and introduce kids to the existence of more controls without encouraging them to use this as a primary method of interaction. Advanced users, of course, could still right-click to invoke the full menu in one shot. Eben [1] Incidentally, one of my major complaints with the resume by default behavior is that it makes starting new activities hard to do, and virtually impossible to do without using a secondary action, which is the wrong approach in my mind. I think starting from home, with the option to resume, while encouraging one-click resume from the Journal is still the correct approach. I think offering the option to enter resume by default mode is great, but I'm not sure it should be, itself, the default for Home view. In practice, it seems it has worked too well. It used to be that kids never resumed activities. Now, it seems, they never start new ones. The solution seems to be in encouraging use of the Journal and the Home view for these different default actions, and in clarifying the UI such that kids understand and desire to do so. Eben Regards, Simon ___ 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] RFC: Kill the delayed menus for good
On Wed, Oct 14, 2009 at 16:57, Michael Stone mich...@laptop.org wrote: A word of initial warning: please turn on your sense of the absurd before reading. This response is written with a deep sense of amusement, rather than angst. 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. 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. 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. If, say, Gary comes later and proposes a patch to revert yours, should I accept it in fear that I may discourage him otherwise? 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? 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? Failing that option, you likely need to find some product specialists. ... For what it's worth, I do view this patch as a UI bandaid to the underlying problem that hover-to-click-somewhere-else is the wrong UI affordance for the home screen to use in supporting discovery of and access to variant or associated behaviors. The patch is, however, still a big improvement that is available today. Now, as for what better look like: treat each view has having a primary layout algorithm for Sugar-level UI actions. This algorithm should effectively arrange logically related groups of capabilities as determined by metadata attached to the capabilities and as determined by the current filtering criteria for the view. In actual activities, this layout algorithm is the new toolbar approach. The filtering criteria are hover-or-click on an expandable toolbar item. In the circle view, I'd like to see the layout algorithm expanded to lay out arcs of smaller option icons each with the same prelighting and saturation behavior as partial halos around the exterior perimeter of the activity icons. Naturally, there are some obvious interesting extensions involving zoom effects and more subtle saturation behaviors. Lastly, it seems to me that a similar approach might also be effective in the mesh view and around the central XO-figure. I'm having trouble getting your proposal, maybe some mockups would help. 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
[Sugar-devel] New SoaS v2 Snapshot Ready
Hi everybody, there is a new, true SoaS snapshot ready for you, awaiting testing. You can grab it here: http://download.sugarlabs.org/soas/snapshots/2/ Note that the XO images have apparently an issue (my fault!), which prevents them from booting, but will be addressed in the next build. Anyway, this build has been created and quickly tested on Monday. It adds FoodForce2 per default and introduces a number of other minor changes, mostly to the way the images are built. However, also the base system has matured, as Fedora is now in its Final Freeze, too. Finally, this build ships the latest Sugar build, 0.86.2! Satellit reports that the user need to add the selinux=0 line manually in this build when the zyx-liveinstaller is used. It will be fixed, too. Please report all issues you encounter on the appropriate bug tracker! Thanks, --Sebastian ___ 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'm extracting some of the for [[The Undiscoverable]]. On Wed, Oct 14, 2009 at 9:39 AM, Eben Eliason e...@laptop.org wrote: On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer si...@schampijer.de wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) Works for me. I hate hover menus. From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001 From: Michael Stonemich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. Can you describe what the patch will change from the user point of view? Is this to get rid of the delayed build up of palettes when hovering over icons? You can use right click to get the menu immediately. The delay is on purpose. Yes, that's in [[The Undiscoverable]] We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] That's fine, if 1) Everything is discoverable. or 2) Teachers have guidance on what is not discoverable and how to introduce it, and on children's use cases and on how to handle those use cases efficiently. We have neither. I'm working on 2. Anything that improves 1 gets +1 from me. This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. Was the discoverability of hover menus tested with children? I didn't discover it, and I'm a born lever puller and button clicker. 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. A case of treating the symptom rather than the ailment. A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. 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? I don't see the problem. The nice friendly large clickable icons will remain where they are. You either have to create and *demonstrate* a path to *equal* discoverability, or you have to think about helping teachers help children with what they don't discover. Just for fun, I might suggest an alternate possibility which actually decreases the discoverability of the secondary palette. Not my kind of fun. We could reveal the primary palette (label) on a delay as we do now, with some indication of more options that can be clicked to expand the menu to reveal the secondary items. This would provide the (essential) primary palette as a label and introduce kids to the existence of more controls without encouraging them to use this as a primary method of interaction. Advanced users, of course, could still right-click to invoke the full menu in one shot. I don't like to hear children divided into advanced and non-advanced that way. If we get a series of lesson plans together on all of the known non-discoverable elements of Sugar, we should be able to get this difference down to two or three weeks max. Then we can talk about advanced children being the ones who have developed skill in what an Activity is for, not in knobs and blinkenlights. Eben [1] Incidentally, one of my major complaints with the resume by default behavior is that it makes starting new activities hard to do, and virtually impossible to do without using a secondary action, which is the wrong approach in my mind. I want to know what is in the children's minds. I think starting from home, with the
[Sugar-devel] Mesh
Hi, I have read a lots of documents which explains what kind of packages the mesh has got, for example, beacon, probe response, probe request, the ones for discovery the path. But i can't join all this information and understand how one XO can see another XO in its neighbourhood. I hope you can understand me and help me. Regards, Cecilia ___ 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 Wed, 14-10-2009 a las 12:15 -0400, Caroline Meeks escribió: People could take both versions to a group of kids and video how it goes. When are you going to be at the GPA? Next time I could come along, apply the patch before the kids start using the machines, and then we could interview them at the end of the day about their experience. Or -- if we were evil enough -- we could patch only half of the stations and see which group performs better ;-) -- // 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] [Systems] sunjammer: upgrade to Jaunty, Sat Oct 10th @ 20:00-24:00EST
El Wed, 14-10-2009 a las 22:08 +0530, Sayamindu Dasgupta escribió: It looks like this broke the Pootle and translate toolkit packages (the stock Ubuntu/Debian provided versions are used instead of the ones from your PPA). I tried to rebuild for Jaunty (with some new patches), but some files are getting installed in lib/python2.6/dist-packages (instead of the usual site-packages) which is breaking the build. I'm not _that_ familiar with Ubuntu/Debian packaging - could someone with better debian packaging foo take a look ? The patches that need to go in are at http://git.sugarlabs.org/projects/pootle/repos/mainline (I have shut down Pootle since there are problems with the PO parser in the Ubuntu packages which can mess up Etoys translations badly) I'm afraid I don't have time to respond quickly today. I guess I could force the installation of my older packages if that would help. -- // 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] Mesh
Cecilia Abalde wrote: Hi, I have read a lots of documents which explains what kind of packages the mesh has got, for example, beacon, probe response, probe request, the ones for discovery the path. But i can't join all this information and understand how one XO can see another XO in its neighbourhood. I hope you can understand me and help me. The connection you are looking for, between the wireless mesh network and the graphical representation in the Neighborhood View, is the Presence Service [1] and Telepathy-Salut [2]. These pages are in English, but we can help you with translation if language is a problem. This is a complicated subject, so please feel free to ask more questions. --Ben [1] http://wiki.laptop.org/go/Presence_Service [2] http://wiki.laptop.org/go/Telepathy-salut 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] RFC: Kill the delayed menus for good
On Wed, Oct 14, 2009 at 1:50 PM, Bernie Innocenti ber...@codewiz.orgwrote: El Wed, 14-10-2009 a las 12:15 -0400, Caroline Meeks escribió: People could take both versions to a group of kids and video how it goes. When are you going to be at the GPA? Next time I could come along, apply the patch before the kids start using the machines, and then we could interview them at the end of the day about their experience. Or -- if we were evil enough -- we could patch only half of the stations and see which group performs better ;-) they all have their own sticks so that might not be quite so easy. Also I don't want to do it during classroom time. We hope to start an afterschool session on Sugar on Fridays in a couple of weeks. Want to help? I think once we've done that for a few times we might be able to ask to borrow some kids who have yet to use Sugar some afternoon when they are in after-school. Give half of them one kind of stick and half another in the GPA computer lab. Realistically, I think it will be about a month before I could set that up, just in terms of how many new requests I can give the school at once. There is also a club at Harvard using XOs in a Boston after school program. I'm not sure where they are in their process but they might be able to provide a test bed on XOs. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- 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] [SoaS] New SoaS v2 Snapshot Ready
Douglas McClendon fixed selinux problems and bugs in zyx-liveinstaller: v0.1.12 is in soas02.iso. If you want to test immediately with soas02.iso, start terminal, become root, and type rpm -e zyx-liveinstaller rpm -Uvh \ http://filteredperception.org/downloads/zyx-liveinstaller/zyx-liveinstaller-0.1.14-1.i386.rpm Then as root or non-root, launch by typing 'zyx-liveinstaller' as usual. Sebastian Dziallas wrote: Hi everybody, there is a new, true SoaS snapshot ready for you, awaiting testing. You can grab it here: http://download.sugarlabs.org/soas/snapshots/2/ Note that the XO images have apparently an issue (my fault!), which prevents them from booting, but will be addressed in the next build. Anyway, this build has been created and quickly tested on Monday. It adds FoodForce2 per default and introduces a number of other minor changes, mostly to the way the images are built. However, also the base system has matured, as Fedora is now in its Final Freeze, too. Finally, this build ships the latest Sugar build, 0.86.2! Satellit reports that the user need to add the selinux=0 line manually * in this build when the zyx-liveinstaller is used. It will be fixed, too. *see note at top Please report all issues you encounter on the appropriate bug tracker! Thanks, --Sebastian ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ 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 Wed, Oct 14, 2009 at 1:41 PM, Edward Cherlin echer...@gmail.com wrote: I'm extracting some of the for [[The Undiscoverable]]. On Wed, Oct 14, 2009 at 9:39 AM, Eben Eliason e...@laptop.org wrote: On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer si...@schampijer.de wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. (please, let's not add another configurable knob!) Works for me. I hate hover menus. From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001 From: Michael Stonemich...@laptop.org Date: Mon, 14 Sep 2009 22:33:12 -0400 Subject: Make various palette animations happen more quickly. Can you describe what the patch will change from the user point of view? Is this to get rid of the delayed build up of palettes when hovering over icons? You can use right click to get the menu immediately. The delay is on purpose. Yes, that's in [[The Undiscoverable]] We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] That's fine, if 1) Everything is discoverable. Yes, we could use some work there. The hover was meant to increase discoverability, not decrease it, but perhaps it's not working effectively. or 2) Teachers have guidance on what is not discoverable and how to introduce it, and on children's use cases and on how to handle those use cases efficiently. Agreed. We have neither. I'm working on 2. Anything that improves 1 gets +1 from me. This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. Was the discoverability of hover menus tested with children? I didn't discover it, and I'm a born lever puller and button clicker. Almost nothing was tested with children until the first release of Sugar on the XO-1, unfortunately; we would have liked to test more. 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. A case of treating the symptom rather than the ailment. 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. Perhaps (assuming, of course, the rules you laid out above already) we should remove the hover activation altogether! (Not, of course, without testing!) A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. 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? I don't see the problem. The nice friendly large clickable icons will remain where they are. You either have to create and *demonstrate* a path to *equal* discoverability, or you have to think about helping teachers help children with what they don't discover. The problem is that the appearance of the palette seems to encourage kids to take the longer (and harder) route to their desired interaction. The reveal of the alternate option could distract from the more direct path to their intended goal. Again, observation with kids indicated that, even without revealing palettes immediately, they tended to wait for them instead of clicking directly on
Re: [Sugar-devel] RFC: Kill the delayed menus for good
Michael Stone wrote: In the circle view, I'd like to see the layout algorithm expanded to lay out arcs of smaller option icons each with the same prelighting and saturation behavior as partial halos around the exterior perimeter of the activity icons. It took me a while to get this, but now that I understand it, I like it. The basic idea is to make the current palette appear with no delay on rollover, but not directly under the cursor. The user is not dissuaded from clicking on the primary icon, which remains accessible, but the secondary options are also immediately visible. The obvious problem with this is that the palette may cover another nearby icon, preventing the user from accessing it. A simple solution, in the circle view, would be to make the palette always pop out, away from the center. Michael proposes a more aesthetic solution, changing the geometry of the palettes to curve around the outside of the circle. 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] [Systems] sunjammer: upgrade to Jaunty, Sat Oct 10th @ 20:00-24:00EST
El Wed, 14-10-2009 a las 23:30 +0530, Sayamindu Dasgupta escribió: I managed to figure out the issue in building the packages - https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027439.html I'm going to do a build in a up to date jaunty VM and install the built packages in the server. Also, I'm going to create a PPA containing these packages so that we can push updates to that subsequently. Does that sound sane ? If you're going to create a PPA, then you don't have to do all the extra work to setup a Jaunty VM: just upload the source package with dput and the PPA will automatically build binaries for all distros and archs! It works very much like Koji in Fedora. If you want to debug a build on a local machine, you could also use your sunjammer shell account. -- // 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] Status report on Bookreading
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
Re: [Sugar-devel] [Bookreader] Status report on Bookreading
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
Re: [Sugar-devel] incremental activity update
On Wed, Oct 14, 2009 at 1:19 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Wonder how we could make it easier for other deployments to benefit from these changes. For the F9 series (8.2.1) my current plan is to work to polish the imagecreator scripts so that it is easier for deployents to - prepare a custom image (mostly covered) - base on an existing image (in place, even if the tar isn't available) - create and inject signatures with the local keys (ofw, initramfs, kernel) in addition to that, I hope I can pull a 8.2.2 image collecting these patches. See my 'papercuts' post a while ago. Can't promise when or how, but it's on my list. Unless someone beats me to it... 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] [ASLO] Release Conozco Uruguay-7
On Tue, Oct 13, 2009 at 03:07:59PM -0400, Caroline Meeks wrote: I just got a 404 error when I tried to download this onto a Sugar VM from a.sl.o On Mon, Oct 12, 2009 at 4:32 PM, Sugar Labs Activities activit...@sugarlabs.org wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4199 Sugar Platform: from 0.82 to 0.86 Download Now: http://activities.sugarlabs.org/downloads/version/29277 Release notes: Reviewer comments: This request has been approved. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Looks like we have permitions issue, ASLO can't push new .xos to to /upload/activities. Can someone chown /upload/activities and rsync /upload/activities from /srv/www-sugarlabs/activities/files. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Conozco Uruguay-7
Activity Homepage: http://activities.sugarlabs.org/addon/4199 Sugar Platform: from 0.82 to 0.86 Download Now: http://activities.sugarlabs.org/downloads/version/29277 Release notes: Reviewer comments: This request has been approved. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: Mentor request for PyDebug Activity
-- Forwarded message -- From: George Hunt georgejh...@gmail.com Date: Wed, Oct 14, 2009 at 17:56 Subject: [support-gang] Mentor request for PyDebug Activity To: Developers List de...@lists.laptop.org, Support Gangsters support-g...@laptop.org I am excited about developing a tool to help me develop other XO Activities. When I shared my ideas with Adam Holt, he suggested that I seek a mentor, or a few partners to help me clarify my ideas, and increase the usefulness of the end product. I am writing this to request such help. As a programmer, I'm fairly new to python. I started writing assembly language in 1975 for the terminal division of Hewlett--Packard, which was soon to become the Personal Computer division. I only started python after I got my G1G1 in early 2008. I'm fairly averse to re-inventing the wheel. So I have been thinking of combining Activities that already run on the XO as my main strategy. At this point I have hacked together Write, Terminal, and Browse to all exist in a notebook under the Sugar toolbar. I can read and write Activity.xo files from the journal. So I've learned a lot from what is already written. Whatever the final form factor, the work I've done up to now will not be lost. At this point I'm debating whether to substitute gedit for the functionality of abiword. Gedit includes many of the feature a programmer is looking for. It is extensively internationalized. It has a python extension system that I think will make for easy integration into my application. I'm leaning towards the structure of a remote debugger, even though the client and server will mostly reside on the same machine. I'd like for the application to be insulated from errant client programs. I'm having a lot of fun, and feeling much more productive than I did a few months ago. I'd love to hear from a few people who are willing to help me perfect my ideas or have experience that could keep me from going down unfruitful paths. I've written a wiki page trying to pull together some of my ideas: http://wiki.laptop.org/go/Python_Debugger_activity_for_the_XO. There is also a little more bio info about me at http://wiki.laptop.org/go/User:GeorgeHuntd Thanks, George ___ support-gang mailing list support-g...@lists.laptop.org http://lists.laptop.org/listinfo/support-gang -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
On Wed, Oct 14, 2009 at 12:14:57PM +0100, Tomeu Vizoso wrote: On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. Please, test it yourself and report back. If we like this change, I think we should go on and also kill the code that this patch makes redundant. 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? From [1]: Also the context menu, that appears when hovering for a moment over an icon, providing some settings or features, irritated at least five children more than it was supportive. Only two children used the context menu of the home screen-icons to identify the activity, because the name of the activity is displayed on top of the menu. [The children] were partially bothered [by the context menu-function] and one girl even groaned every time the menu appears, because she did not want it to. Eben's justification of popup-menus[2] (which I alway re-buy into everytime I read it) is perhaps not being absorbed by Activity developers? Perhaps with a bit of developer elbow-grease we can eliminate the crutch of the popup-menu from every (Fructose) Activity? Thanks, Tomeu Martin 1. http://dimeb.informatik.uni-bremen.de/documents/Sugar-Not_necessarily_unhealthy.pdf My favourite use out of context for bashing-the-UI-design quote is: Every-time the Frame appeared, which happened mostly unintentional, the children were irritated and one girl even [got] a little bit angry and started to swear. 2. http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020209.html pgpKi7DFrbw6q.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] updating jsdoc for Karma
Hi guys I realize that, unfortunately, JsDoc did not show all classes and methods documentation. Example: JsDoc produced documentation for KSound (constructor) but no its methods (play, pause, etc..) atm, If you want to read the full documentation you will need to read it from the code (js file) Bryan, thanks for fixing the Jquery-Anonymous- prefix I originally used @memberOf bu it produced unexpected results, instead of commenting those lines, I simply added '_' I will try to fix it this weekend, I will keep u on track of positive or negative results. regards 2009/10/14 Bryan Berry br...@olenepal.org I changed some of the basic stuff in jsdocs but I still need Felipe's help when he gets a chance. http://karma.sugarlabs.org/docs/ I got rid of the confusing Jquery-Anonymous- prefix that was in front of a lot of classes. I will take a look again at it tomorrow. Felipe, you used the @memberOf_ tag in a number of places. Does that do anything different from @memberOf which doesn't have the trailing _ ? -- Bryan W. Berry Senior Engineer OLE Nepal, http://www.olenepal.org -- Felipe López Toledo ___ 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
Simon wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: I'm loving how the menus suddenly are now snappy and responsive. From: Michael Stone ... Subject: Make various palette animations happen more quickly. ... Can you describe what the patch will change from the user point of view? Of course I can. In fact, I believe that Bernie and I already did, in the lines of your message that I quoted above. Do you actually find these lines to be obscure? (I inquire most particularly because I'm nearly certain that you could have learned the user-visible effect of the patch more quickly and more easily by trying out the change yourself than by asking. Maybe you had a more complex goal in mind than simply learning the nature of the user-visible change which justifies the additional delay and round-trips that your request incurs?) Is this to get rid of the delayed build up of palettes when hovering over icons? Yes, this is the purpose of setting the length of the build-up animation to be 0.0 seconds. The delay is on purpose. Of course it is. Unfortunately, that does not make it good. Now, after trying out the patched version vs. the unpatched version, do you actually find that you prefer the current behavior? Kind regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] MANIFEST experiments
Confirmed. On Wed, Oct 14, 2009 at 05:29:09PM +0545, Daniel Drake wrote: So, I reflashed 2 XOs, booted for the first time, entered a name. On one, I modified sugar.bundle.ActivityBundle.read_manifest() to be a no-op, then turned it off. On the other, I just turned it off. I reproduced this experiment. Used build 802, with a limited set of 22 activities [1], with a similar change [2]. Then I powered both on at the same time and started a stopwatch. I measured how long it takes for the XOs to reach the stage of boot where the XO stick figure and the activity icons are visible. 1255565448 power up both XOs 1255565533 modified XO boot complete 1255565539 unmodified XO boot complete The one with the modification reached this point *55* seconds faster than the other one! In my case, about 6 seconds. I feel that even this small time was worth it, so I plan to patch this for the friends' kids I've got laptops deployed to. Is there a collection of 802 performance improvement patches? Notes: 1. the activities installed were from G1G1 Activities for 8.2 and were Browse Calculate Chat Distance Etoys Implode Maze Measure Memorize Moon Paint Pippy Read Record Ruler Scratch Speak TamTamMini TamTamSynthLab Terminal TurtleArt Write 2. the change was to activitybundle.py in /usr/lib/python2.5/site-packages/sugar/bundle/ and removed all code in read_manifest(), leaving just pass: def read_manifest(self): pass -- James Cameron http://quozl.linux.org.au/ --- activitybundle.py.orig 2009-10-15 00:09:04.0 + +++ activitybundle.py 2009-10-15 00:09:40.0 + @@ -79,43 +79,7 @@ return ret def read_manifest(self): -read_manifest: sets self.manifest to list of lines in MANIFEST, -with invalid lines replaced by empty lines. - -Since absolute order carries information on file history, it should -be preserved. For instance, when renaming a file, you should leave -the new name on the same line as the old one. - -lines = self._raw_manifest() - -# Remove trailing newlines, they do not help keep absolute position. -while lines and lines[-1] == : -lines = lines[:-1] - -for num, line in enumerate(lines): -if not line: -continue - -# Remove duplicates -if line in lines[0:num]: -lines[num] = -logging.warning(Bundle %s: duplicate entry in MANIFEST: %s -% (self._name,line)) -continue - -# Remove MANIFEST -if line == MANIFEST: -lines[num] = -logging.warning(Bundle %s: MANIFEST includes itself: %s -% (self._name,line)) - -# Remove invalid files -if not self.is_file(line): -lines[num] = -logging.warning(Bundle %s: invalid entry in MANIFEST: %s -% (self._name,line)) - -self.manifest = lines + pass def get_files(self, manifest = None): files = [line for line in (manifest or self.manifest) if line] ___ 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 Wed, Oct 14, 2009 at 4:42 PM, Michael Stone mich...@laptop.org wrote: Simon wrote: On 10/13/2009 04:36 AM, Bernie Innocenti wrote: I'm loving how the menus suddenly are now snappy and responsive. From: Michael Stone ... Subject: Make various palette animations happen more quickly. ... Can you describe what the patch will change from the user point of view? Of course I can. In fact, I believe that Bernie and I already did, in the lines of your message that I quoted above. Do you actually find these lines to be obscure? (I inquire most particularly because I'm nearly certain that you could have learned the user-visible effect of the patch more quickly and more easily by trying out the change yourself than by asking. Maybe you had a more complex goal in mind than simply learning the nature of the user-visible change which justifies the additional delay and round-trips that your request incurs?) Is this to get rid of the delayed build up of palettes when hovering over icons? Yes, this is the purpose of setting the length of the build-up animation to be 0.0 seconds. The delay is on purpose. Of course it is. Unfortunately, that does not make it good. Now, after trying out the patched version vs. the unpatched version, do you actually find that you prefer the current behavior? Kind regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Can the delay of showing the right-click menu be user configurable via control panel just like the frame sensitivity? I've seen both use cases: right click and hover to access the menu. Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Mentor request for PyDebug Activity
From: George Hunt georgejh...@gmail.com I'm very excited to hear about this project, and I hope you'll keep us updated with your progress. Anything that makes Sugar a better self-hosting development environment is tremendously valuable for us. At this point I'm debating whether to substitute gedit for the functionality of abiword. IMHO, your best option is to use gtksourceview [1]. This is the GTK source code editing widget that is used by gedit. gtksourceview provides syntax highlighting, line numbers, and undo/redo functionality. You can see it in use in Sugar in the Pippy source code [2]. Unlike gedit, gtksourceview is guaranteed to be present in any Sugar installation. Good luck! --Ben [1] http://projects.gnome.org/gtksourceview/ [2] http://git.sugarlabs.org/projects/pippy/repos/mainline/blobs/master/pippy_app.py#line123 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] RFC: Kill the delayed menus for good
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.) 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 3. Applying a 6-line patch to a jhbuild root, to a Sugar chroot produced with my scripts, or to a live Sugar install is a hell of a lot easier (and more valuable to know how to do) than my cooking up a SoaS image just for interested people to try out said patch. (For the record, I'm more sympathetic to the SoaS argument with rainbow stuff but the rainbowish work that I'm doing at the moment lies in the area of network isolation and community-building [c.f. my new playground at sandboxing.org] rather than in Sugar integration.) Now, as for what better look like: ... I'm having trouble getting your proposal, maybe some mockups would help. A fair request, but one that is probably doomed to wait until someone with graphics and/or animation skills comes along to help me transform my words into pictures and movies. (Interested folks should please contact me; I'd be very happy to work with you on obtaining such visual materials.) Regards, Michael P.S. - For even more humor, count how many words have gone into this thread so far in
Re: [Sugar-devel] incremental activity update
2009/10/15 Martin Langhoff martin.langh...@gmail.com: For the F9 series (8.2.1) my current plan is to work to polish the imagecreator scripts so that it is easier for deployents to - prepare a custom image (mostly covered) - base on an existing image (in place, even if the tar isn't available) - create and inject signatures with the local keys (ofw, initramfs, kernel) 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. I feel that for making such customizations, the deployments should clone the build setup (pilgrim) and make changes there. It's more complex but works well and doesn't leave such a bad taste in the mouth. 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/13 Bernie Innocenti ber...@codewiz.org: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. I haven't tried it, and your mail also lacks an explicit explanation of what your patch actually does, but based on the hints you have provided, : It makes all menus that currently have a delay appear instantly? I don't like the idea, as I think that the delay has influenced Sugar's UI design quite heavily. For example, a user is on the home screen with ring view enabled, and the mouse cursor is on the left side of the screen. The user wants to shut down the XO. He moves the cursor towards the XO figure in the middle of the screen, but while doing so passes over an activity icon in the ring. The menu immediately appears, completely obscuring the XO figure that he was going to click on. 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
Daniel wrote: 2009/10/13 Bernie Innocenti ber...@codewiz.org: Hello, Michael just passed by the Acetarium and, since the dinner was late, we found the time to test and review his latest prototype^W patch. I'm loving how the menus suddenly are now snappy and responsive. I haven't tried it, and your mail also lacks an explicit explanation of what your patch actually does, but based on the hints you have provided, : It makes all menus that currently have a delay appear instantly? It makes the menus appear and disappear much more quickly by setting the length of their animations to be 0.0 seconds, thereby simulating snappy and responsive. Whether or not their appearance and disappearance is instantaneous depends on your processor; Python and GTK are still surprisingly slow. I don't like the idea, as I think that the delay has influenced Sugar's UI design quite heavily. You're obviously entitled to your opinion. I'd still appreciate it if you tried out the patch. For example, a user is on the home screen with ring view enabled, and the mouse cursor is on the left side of the screen. The user wants to shut down the XO. He moves the cursor towards the XO figure in the middle of the screen, but while doing so passes over an activity icon in the ring. The menu immediately appears, completely obscuring the XO figure that he was going to click on. I have actually tried to produce this behavior. In practice, I can't find anyway to make it frustrating because the menus also *disappear* quickly when the cursor leaves their boundary. (I would nevertheless be interested in hearing about actual experience reports from frustrated users.) Regards, Michael ___ 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 Michael Stone mich...@laptop.org: the menus also *disappear* quickly when the cursor leaves their boundary. In the field I actually have considered on various occasions doing the opposite. I've seen many children struggle to keep the mouse inside the menu while navigating to the item they want to click on, and having 1 or 2 more seconds to reposition the mouse before the menu disappears might help a lot. (of course it might bring in some other undesirable effects, these are just some initial thoughts from field frustration) 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
On Wed, Oct 14, 2009 at 11:12 PM, Michael Stone mich...@laptop.org wrote: Eben, First, thanks for the interesting and detailed history of your vision. I very much appreciate your ability to generate thought experiments describing other ways that the world could be. Next... Eben wrote: Simon Schampijer si...@schampijer.de wrote: You can use right click to get the menu immediately. The delay is on purpose. We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. So try it, and encourage your friends to do the same! :) I don't feel inclined to myself, as I've never had a problem with the delay, and actually used to find the speed with which these palettes obstructed my view of the screen frustrating before the delay was increased. I assume there is a group of individuals — developers and kids alike — who feel the same as I do, and others who feel the same as you. Those that feel as you do, of course, should definitely try it and provide feedback, which I'd be happy to hear. I have no itch. (NB: merging it is a good way to accomplish this!) The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. This is a good story, but a bad implementation. A better implementation would be to provide the extra options in a *visible but unobtrusive I disagree that this is an obviously better implementation. It's better if you're one who frequently has needs for the additional complexity. It's arguably not if you use only (or mostly) primary actions. form* or, if you absolutely must hide them, to make them visible with a device like a complexity slider or like the new toolbar's transient hover; lock on click behavior. Adding a preference for the delays for these palettes, as we have for the frame, is a another reasonable possibility, and a literal incarnation of the complexity slider you suggest. Remember -- comparisons should be made in a fixed visual field, not across multi-second long gulfs of time, cursor positioning, and fine motor control. 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. A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. Understandable, but as you say, the result isn't great. This makes it better. Try it! Merge it! (Then come up with something better.) We had lots of trouble with palettes obscuring other elements of the UI even with short delays, including, potentially, the desired target. I can't imagine that this issue has gone away in the intervening months, and removing the delay entirely seems it would exacerbate the issue. Do you have any experiences to report in this regard? 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? It's better than the present. Again, merge it, then find something better. You keep saying it's better, but fail to provide adequate reasoning or heuristics for why you feel this to be so. Could you elaborate on the problems you identified and the way in which this resolves them? Also, again, it's only arguably better (though I don't fully comprehend the argument) for those that want or need all of the secondary functionality, yourself included, and the ability to right-click to invoke palettes immediately exists to enable those who feel more comfortable with the system and desire the added level of depth it can provide to access these options without the delay. Just for fun, I might suggest an alternate possibility which actually decreases the discoverability of the secondary palette. We could reveal the primary palette (label) on a delay as we do now, with some indication of more options that can be clicked
Re: [Sugar-devel] RFC: Kill the delayed menus for good
Eben wrote: We should definitely get feedback. I wouldn't be entirely opposed to a change, but I do want to make sure that we make such a change for the right reasons, and that it's actually the right change to make. So try it, and encourage your friends to do the same! :) I don't feel inclined to myself, as I've never had a problem with the delay, and actually used to find the speed with which these palettes obstructed my view of the screen frustrating before the delay was increased. Do I correctly understand that a) when you wrote we should definitely get feedback up above, you actually meant YOU should get feedback and bring it to me. and that b) when you wrote I definitely want to make sure that we make such a change for the right reasons you were not, in fact, considering does it feel good to use? to be a critical part of the right reasons? I have no itch. You don't need to have an itch to try to help someone else accomplish a reasonable goal that you do not actively oppose. That's called Encouraging Contribution. The initial design intent was to develop a system which worked in a sufficiently complete manner without needing palettes at all. Kids should be able to start activities, resume activities, join activities, write, paint, stop, etc. without ever seeing a palette at all. [1] This is the low floor. For kids with more experience or curiosity, we decided to provide contextual palettes which grouped related actions and provided more complex interactions with the system. This is no ceiling. Furthermore, we wanted to help introduce kids to the availability of additional options in a discoverable way, which is why the hover effect was chosen to provide increasing levels of detail and interaction for a given object. This is a good story, but a bad implementation. A better implementation would be to provide the extra options in a *visible but unobtrusive I disagree that this is an obviously better implementation. Which of the following do you disagree with? a) visible but unobtrusive is a lower floor than hover b) visible but unobtrusive is a higher ceiling than hover c) visible but unobtrusive is provides increasing levels of detail better than hover d) other objection It's better if you're one who frequently has needs for the additional complexity. I'm actually claiming that it's uniformly better: hover without a lock open as is available in the new toolbars is Just A Bad Idea, particularly as we see more devices with touchscreens. It's arguably not if you use only (or mostly) primary actions. Having the sub actions be always available in the same field of view but unobtrusive, e.g. by means of effective use of color, contrast, and size just seems like a better solution to me. I'm sorry that I don't have the code or animations necessary to demonstrate this today. However, that lack should in no way alter our consideration of the current patch. form* or, if you absolutely must hide them, to make them visible with a device like a complexity slider or like the new toolbar's transient hover; lock on click behavior. Adding a preference for the delays for these palettes, as we have for the frame, is a another reasonable possibility, and a literal incarnation of the complexity slider you suggest. It's one choice, but it's a bad one. We can do better. Also, it is not a complexity slider, most notably because it is not visible in the same field of view as the interface it controls. Remember -- comparisons should be made in a fixed visual field, not across multi-second long gulfs of time, cursor positioning, and fine motor control. You didn't respond to this principle. Do you accept it or feel that it misses some important cases? 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. A agree that hovering in one place to click in another isn't great; but that's also not the intended primary means of interaction, and should only really be done when one of the secondary actions is desired. Understandable, but as you say, the result isn't great. This makes it better. Try it! Merge it! (Then come up with something better.) We had lots of trouble with palettes obscuring other elements of the UI even with short delays, including, potentially, the desired target. I can't imagine that this issue has gone away in the intervening months, and removing the delay entirely seems it would exacerbate the issue. Do you have any experiences to report in this regard? As I wrote to Daniel, my experience was that the overall increased responsiveness of the UI more than made up for any annoyance that I experienced as a result of its occasionally poor layout choices.
