Re: [Sugar-devel] On Zeroinstall and Sugar packages
On Mon, Oct 19, 2009 at 11:42:32PM -0400, Benjamin M. Schwartz wrote: 0compile, combined with Zeroinstall's support for source bundles, enables us (1) to approach true platform-independence and (2) to provide users the opportunity to modify the source code of a package and rebuild it in a natural way. So unless the sender and receiver architecture match, the receiver needs to build the package from source and requires the usual tools (gcc, autoconf, etc) for that? How much space would those take up on the XO-1? I'm not arguing against it, BTW, quite the contrary: I've suggested a similar scheme [1] in the past. [1] http://wiki.sugarlabs.org/go/Activity_Team/Packaging_Ideas#combined_Source.2BBinary_package CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] help
I have never tried to set the theme in Sugar. Perhaps someone on IRC has had some experience with it.? -walter On Tue, Oct 20, 2009 at 7:11 AM, Esteban Arias esteban.arias...@gmail.com wrote: Hello Walter, I need to set contrast theme in the sugar xo. when the sistem run, /usr/bin/sugar-shell set the enviroment GTK2_RC_FILES = /usr/share/sugar/data/sugar- 100.gtkrc in this path, the sistem apply the theme. but this them is apply on only activities Terminal or control panel for example. Activities Write or Calculate for example this theme not applay. I set GTK2_RC_FILES in /etc/enviroment, but persist the problem -- 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] help
Hi Esteban, have you tried editing the gtk-theme-name property in /usr/share/sugar/data/sugar-100.gtkrc ? Please reply. Thanks, Tomeu On Tue, Oct 20, 2009 at 12:22, Walter Bender walter.ben...@gmail.com wrote: I have never tried to set the theme in Sugar. Perhaps someone on IRC has had some experience with it.? -walter On Tue, Oct 20, 2009 at 7:11 AM, Esteban Arias esteban.arias...@gmail.com wrote: Hello Walter, I need to set contrast theme in the sugar xo. when the sistem run, /usr/bin/sugar-shell set the enviroment GTK2_RC_FILES = /usr/share/sugar/data/sugar- 100.gtkrc in this path, the sistem apply the theme. but this them is apply on only activities Terminal or control panel for example. Activities Write or Calculate for example this theme not applay. I set GTK2_RC_FILES in /etc/enviroment, but persist the problem -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Bolzano 2009 - Schedule draft
I am pleased to report that I shall be present at Bolzano from late Tuesday evening the 10th until the evening of the Friday the 13th (!) While there, with a little help from my friends I wouldn't mind taking baby steps in Python ;-) Sean On Thu, Oct 15, 2009 at 2:24 PM, Simon Schampijer si...@schampijer.de wrote: 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 ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On Zeroinstall and Sugar packages
Sascha Silbe wrote: On Mon, Oct 19, 2009 at 11:42:32PM -0400, Benjamin M. Schwartz wrote: 0compile, combined with Zeroinstall's support for source bundles, enables us (1) to approach true platform-independence and (2) to provide users the opportunity to modify the source code of a package and rebuild it in a natural way. So unless the sender and receiver architecture match, the receiver needs to build the package from source and requires the usual tools (gcc, autoconf, etc) for that? How much space would those take up on the XO-1? I'm not arguing against it, BTW, quite the contrary: I've suggested a similar scheme [1] in the past. I think my answer is sometimes. There are many possible scenarios. For example, if there is good internet access, and the package maintainer has compiled the package for many platforms, then the sender only needs to send the package's name (which is a URL) and then the receiver can install the arch-appropriate bundle from the internet. If there is no internet access, but the sender has kept binaries (and all dependencies) for both architectures, then the receiver can get all needed binaries from the sender. If there is a school server, it can act as a 0mirror [2], maintaining a cache of many Activity packages, including their dependencies, for all the school's architectures. If there is no school server, and the sender does not have the arch-appropriate packages, the receiver may use 0share [3] to see if there is anyone else on the network who has them. Bundles are GPG-signed for security. Only after all those things fail do we need to talk about compiling from source. Then we have interesting questions like whether it's worth the space overhead to require all bundles to include source, and whether to include things like compilers that are needed to rebuild them. My feeling is that all Activity bundles should probably come with source code, but automatically downloading all the build-time dependencies should be a configuration option that can be disabled on systems with constrained disk space or bandwidth. [1] http://wiki.sugarlabs.org/go/Activity_Team/Packaging_Ideas#combined_Source.2BBinary_package Yeah, what I'm describing is very much like that ... except somebody already did all the work for us! [2] http://0install.net/0mirror.html [3] http://0install.net/0share.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Issues running FoodForce2 on Soas Strawberry
Hi, I tried running FoodForce2 on Soas. The game ran fine, but there were some issues regarding the display of the game, it was too much distorted. Later I noticed that Soas comes with python 2.6, but I have done most of the development on python 2.5.4. I ran the game through terminal directly from the code itself and the following log was generated: /usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: Connection refused Any ideas about what could be possible reason for the error? Regards, Mohit Taneja ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Issues running FoodForce2 on Soas Strawberry
One more issue which i figured out after a little more debugging is that the check for Sugar platform is also failing on Soas. I am using the following check on Soas: #Flag to check the operating system FLAG_XO = False try: import olpcgames, olpcgames.util if not olpcgames.ACTIVITY: raise RuntimeError FLAG_XO = True except (RuntimeError,ImportError): FLAG_XO = False The same check is working fine on XO1. Regards, Mohit Taneja On Tue, Oct 20, 2009 at 8:25 PM, Mohit Taneja mohitge...@gmail.com wrote: Hi, I tried running FoodForce2 on Soas. The game ran fine, but there were some issues regarding the display of the game, it was too much distorted. Later I noticed that Soas comes with python 2.6, but I have done most of the development on python 2.5.4. I ran the game through terminal directly from the code itself and the following log was generated: /usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: Connection refused Any ideas about what could be possible reason for the error? Regards, Mohit Taneja ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] two kinds of delay (was: RFC: Kill the delayed menus for good)
Michael Stone writes: Good suggestion for discoverability, inadequate suggestion for fast access to the actually rather important information hidden on the secondary palettes (e.g. disk space availability, battery status, etc.) That trumps all. There are two kinds of delay. Type 1 is stuff like drop-down menus that remain even if the mouse briefly goes out of bounds. This kind of delay normally doesn't waste a nanosecond of the user's time. Type 2 is stuff like start-up animations, sliding menus, and these delayed menus. Type 2 is in the critical path of user interaction. It's normally a source of frustration, permanently preventing users from becoming efficient. Type 2 delays are almost never acceptable. The only case I can think of is when something is about to cause a sudden screen change that may be disorienting to the user. In that case, a very fast transition effect (perhaps 0.1 second) can help the user follow what is happening. I doubt the XO-1 hardware is capable of providing this; certainly the current software situation is far too slow to even attempt it. Since the delayed menus are a type 2 delay with no excuse, they really need to go. Right now, users are forced to be essentially incompetent. You'll never navigate quickly in sugar no matter how proficient you are. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] two kinds of delay (was: RFC: Kill the delayed menus for good)
There are two kinds of delay. Type 1 is stuff like drop-down menus that remain even if the mouse briefly goes out of bounds. This kind of delay normally doesn't waste a nanosecond of the user's time. Type 2 is stuff like start-up animations, sliding menus, and these delayed menus. Type 2 is in the critical path of user interaction. It's normally a source of frustration, permanently preventing users from becoming efficient. The second delay is not only slow, but non-intuitive. I've failed to discover that functionality myself until someone told me about it. :( I think, that if the first delay shows only info (a tag, description, or whatever), and the second one (which for an extra dash of frustration might exist or not) adds the interaction, it would not harm to simply show both together in just one small delay. That way it is easy to use and non obtrusive. My two cents. pgpLGSfCf83M8.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Issues running FoodForce2 on Soas Strawberry
do you know which statement is failing in that try statement? is it the import olpcgames, import olpcgames.util, or the olpcgames.ACTIVITY access? bobby On Tue, Oct 20, 2009 at 1:38 PM, Mohit Taneja mohitge...@gmail.com wrote: One more issue which i figured out after a little more debugging is that the check for Sugar platform is also failing on Soas. I am using the following check on Soas: #Flag to check the operating system FLAG_XO = False try: import olpcgames, olpcgames.util if not olpcgames.ACTIVITY: raise RuntimeError FLAG_XO = True except (RuntimeError,ImportError): FLAG_XO = False The same check is working fine on XO1. Regards, Mohit Taneja On Tue, Oct 20, 2009 at 8:25 PM, Mohit Taneja mohitge...@gmail.comwrote: Hi, I tried running FoodForce2 on Soas. The game ran fine, but there were some issues regarding the display of the game, it was too much distorted. Later I noticed that Soas comes with python 2.6, but I have done most of the development on python 2.5.4. I ran the game through terminal directly from the code itself and the following log was generated: /usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: Connection refused Any ideas about what could be possible reason for the error? Regards, Mohit Taneja ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
Eben Eliason writes: palettes, we aimed to reduce accidental invocation of them without entirely eliminating discovery by increasing the delay. ... I'm more worried about immediately revealing of all secondary actions, which pull attention from the more efficient manner in which basic actions can be performed - namely, clicking on the big icons. If we can do this in a manner which doesn't distract from the primary interaction methods and encourage inefficient paths through the UI, that would be great. I believe this was first solved by Kid Pix, a few decades ago. One button bar swaps out another button bar. Microsoft's ribbon looks like the same thing, though I've never used it so I can't say for sure. Tux Paint certainly uses this model. In that case, it works fine for kids **way** below sugar's target age. (smart 2-year-old or regular 4-year-old for sure, possibly younger) Another possibility would be to educate children about right click somehow. On the one hand, I think it's really important to do this. Besides the human-compatibility issue and the extra expressive power, I think using a second button will help to develop the mind a bit. (you're not just grabbing or poking when you click; you're performing an action that could be determined by which button you click) On the other hand, I think both buttons should be the left button by default. Kids have trouble hitting the correct button. Button mistakes should not be something kids face from the moment go. Perhaps, as suggested by Wade, we could allude to the availability of more information immediately on hover, and perhaps even try making the right button the only means of invoking the secondary actions. This does work today, but the lack of discoverability is a definite problem. It's no less discoverable than the left button. Right-click menus need to work two ways though: a. Press and hold down right button, move, release b. Click (press and release) right button, move, click either button ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.86.3
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.86.3.tar.bz2 == News == * Sporadic freezes while scrolling journal #1506 * Suppress race condition with Journal appearing on sugar startup #1373 * Alt+Space not working to show/hide the tray #1476 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan acaha...@gmail.com wrote: Eben Eliason writes: palettes, we aimed to reduce accidental invocation of them without entirely eliminating discovery by increasing the delay. ... I'm more worried about immediately revealing of all secondary actions, which pull attention from the more efficient manner in which basic actions can be performed - namely, clicking on the big icons. If we can do this in a manner which doesn't distract from the primary interaction methods and encourage inefficient paths through the UI, that would be great. I believe this was first solved by Kid Pix, a few decades ago. One button bar swaps out another button bar. Microsoft's ribbon looks like the same thing, though I've never used it so I can't say for sure. Tux Paint certainly uses this model. In that case, it works fine for kids **way** below sugar's target age. (smart 2-year-old or regular 4-year-old for sure, possibly younger) Yeah. This is very similar to the now implemented redesign of the toolbar system for activities, which feedback has indicated is a huge improvement. However, it doesn't instantly solve the issue for freely positioned UI elements, such as people and activities within the various zoom levels. There may be a variation on the technique that could work in these contexts, of course, and some interesting possibilities have already been suggested. Another possibility would be to educate children about right click somehow. On the one hand, I think it's really important to do this. Besides the human-compatibility issue and the extra expressive power, I think using a second button will help to develop the mind a bit. (you're not just grabbing or poking when you click; you're performing an action that could be determined by which button you click) On the other hand, I think both buttons should be the left button by default. Kids have trouble hitting the correct button. Button mistakes should not be something kids face from the moment go. Yup. The hardware design was done before a UI team was organized at OLPC. One of the first suggestions, though it was already too late, was to limit the hardware to one button. Since we didn't have the opportunity to change that, we opted to provide a more traditional right-click functionality both because it did provide a way to offer more contextual actions in a manner consistent with other interfaces that already exist, and because we thought it could actually be perplexing to have two buttons that always appeared to do the same thing. If that's proving problematic for children in practice, we could make a change there. I hadn't heard much on that particular issue, so I don't know how common (or persistent) it is. Perhaps, as suggested by Wade, we could allude to the availability of more information immediately on hover, and perhaps even try making the right button the only means of invoking the secondary actions. This does work today, but the lack of discoverability is a definite problem. It's no less discoverable than the left button. Right-click menus True. need to work two ways though: a. Press and hold down right button, move, release b. Click (press and release) right button, move, click either button Agreed. This would be a good improvement to the behavior. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.86.2
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.86.2.tar.bz2 == News == * Do not stop processing motion-notify-event #1507 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Should we care about non readers and kids with motor skill issues?
Caroline Meeks writes: 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. You don't want to keep them non-readers forever, do you? That's what happens when you don't push them to use text. There are 2-year-old kids using Tux Paint. They don't read AFAIK, yet nearly every Tux Paint icon comes with text. There is even an area at the bottom of the screen where Tux constantly spews text. The less a kid is able to read, the more he desperately needs text. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
On Tue, Oct 20, 2009 at 4:19 PM, Eben Eliason e...@laptop.org wrote: On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan acaha...@gmail.com wrote: Eben Eliason writes: Another possibility would be to educate children about right click somehow. On the one hand, I think it's really important to do this. Besides the human-compatibility issue and the extra expressive power, I think using a second button will help to develop the mind a bit. (you're not just grabbing or poking when you click; you're performing an action that could be determined by which button you click) On the other hand, I think both buttons should be the left button by default. Kids have trouble hitting the correct button. Button mistakes should not be something kids face from the moment go. Yup. The hardware design was done before a UI team was organized at OLPC. One of the first suggestions, though it was already too late, was to limit the hardware to one button. The hardware needs two buttons so that it can support the kid as he grows older. The only button issue I can see is that there is no space between the buttons; there should be a gap or the buttons should be on opposite sides of the track pad. (not that a track pad is OK with filthy kid fingers) The software should map the buttons together by default. Here's a config proposal: By default, the buttons are mapped together and there are hover menus. There is a config switch that enables distinct buttons and changes hover menus to right-click menus. Here is an alternate default: The right button shows an animation of clicking on the left button or similar, correcting the user. (this is currently the default for Tux Paint; an adult is expected to change to both-are-left for 2-year-old kids) provide a more traditional right-click functionality both because it did provide a way to offer more contextual actions in a manner consistent with other interfaces that already exist, and because we thought it could actually be perplexing to have two buttons that always appeared to do the same thing. If that's proving problematic for children in practice, we could make a change there. I hadn't heard much on that particular issue, so I don't know how common (or persistent) it is. It's not that they don't understand. Their fingers land in the wrong spot. They may click right in the middle, hitting both buttons at once. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
On Tue, Oct 20, 2009 at 04:40:28PM -0400, Albert Cahalan wrote: It's not that they don't understand. Their fingers land in the wrong spot. They may click right in the middle, hitting both buttons at once. I've seen this. I've a theory. In other life experiences, kids often have to press at a spot that gives tactile feedback prior to the press. Across the front of the XO those spots include the left edge of the left button, the right edge of the right button, *and* the interface between the two. Close your eyes, clear your mind, and run your finger along. -- 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] Is Analyze compatible with 0.86.2 Sugar?
Hi Thomas, On 21 Oct 2009, at 00:30, Thomas C Gilliard wrote: I have been using Analyze in several versions of sugar. soas02 Fedora 12(rawhide) and trisquel3.0-sugar (ubuntu). both 0.86.2 Sugar Analyze seems to work, but I am getting a number of avitars XO where the Pubkey and color fields are filled with ?. When this happens, the avitars with ? assume the color of My ./sugar identity. (I may have 4-6 or more showing my colors) Bug #1517 I am not sure if this is due to: 1.) changes in the presence service from 084 to 086 2.) a slow and overloaded jabber (this seems to occur when it takes over 1 minute to add an avitar, and there are many users on the jabber.) 3.) Possibly incompatibility of the Analyze activity with the 0.86 versions of Sugar. I note that when I use the Activities site and search for 0.86 activities your Analyze disappears. But it is present when all is selected. Any help you can give would be appreciated. Just tested jabber.sugarlabs.org here and with 0.86.1 under an F11 sugar-jhbuild I'm currently seeing two other buddy icons just as you describe (same colour as me, and Analyse lists them with Pubkey=? and their colour entries empty) the buddy names were rafael, and Gustavo. My initial gut reaction is that the jabber server is playing up, I tried to connect with an XO running 0.84 for comparison but I couldn't coax it into connecting at all. I'm also not aware of any presence service compatibility breaks in 0.86. One other (slight) possibility to consider is perhaps some folks are logged into the server with a non-Sugar jabber client, or perhaps a modified version of Sugar. I'll try and do some more tests tomorrow. Anyone else seeing this? I've been working in Salut for a while now (~5 local Sugar sessions collaborating) and haven't ever seen this particular issue there. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release XO Help-1
Activity Homepage: http://activities.sugarlabs.org/addon/4051 Sugar Platform: from 0.82 to 0.86 Download Now: http://activities.sugarlabs.org/downloads/version/29286 Release notes: 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
[Sugar-devel] [ASLO] Release XO Help-1
Activity Homepage: http://activities.sugarlabs.org/addon/4051 Sugar Platform: from 0.82 to 0.86 Download Now: http://activities.sugarlabs.org/downloads/version/29286 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