[Sugar-devel] [RELEASE] sugar-0.84.23
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.23.tar.bz2 == News == * Release 0.84.23 (Simon Schampijer) * Journal: Show alert when error occurs while writing to external devices #10312 (Simon Schampijer) * AP: separate signal strength from status #10347 (Simon Schampijer) * Add default Ad-hoc networks #9845 (Simon Schampijer) * Connect to gabble immediatly when possible #10350 (Simon Schampijer) * Unable to register a laptop after trying on the wrong network #6857 (Martin Langhoff) * Feedback when deleting files on an external device #10351 (Simon Schampijer) All those patches have been landed in master as well. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Memorize-35
== Source == http://download.sugarlabs.org/sources/honey/Memorize/Memorize-35.tar.bz2 == News == * Release 35 (Simon Schampijer) * Game not transfered when loading a created game #10302 (Simon Schampijer) * Commit from Sugar Labs: Translation System by user carlo.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user thangam.ar...@gmail.com.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user Myckel.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user samybt.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user Clytie.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user anderson861.: 49 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user mschlager.: 57 of 61 messages translated (4 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user Clytie.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user khaled.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user carlo.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Adding language tvl via Pootle (Pootle daemon) * Adding language fil via Pootle (Pootle daemon) * Commit from Sugar Labs: Translation System by user samybt. 61 of 61 messages translated (0 fuzzy). (samy boutayeb) * Commit from Sugar Labs: Translation System by user korakurider. 28 of 61 messages translated (0 fuzzy). (korakurider) Thanks to all the contributors to this new release, espacially the translators. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Memorize-35
Activity Homepage: http://activities.sugarlabs.org/addon/4063 Sugar Platform: 0.82 - 0.90 Download Now: http://activities.sugarlabs.org/downloads/file/27059/memorize-35.xo Release notes: * Release 35 (Simon Schampijer) * Game not transfered when loading a created game #10302 (Simon Schampijer) * Commit from Sugar Labs: Translation System by user carlo.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user thangam.arunx at gmail.com.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user Myckel.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user samybt.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user Clytie.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user anderson861.: 49 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user mschlager.: 57 of 61 messages translated (4 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user Clytie.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user khaled.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user carlo.: 61 of 61 messages translated (0 fuzzy). (Pootle daemon) * Adding language tvl via Pootle (Pootle daemon) * Adding language fil via Pootle (Pootle daemon) * Commit from Sugar Labs: Translation System by user samybt. 61 of 61 messages translated (0 fuzzy). (samy boutayeb) * Commit from Sugar Labs: Translation System by user korakurider. 28 of 61 messages translated (0 fuzzy). (korakurider) 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] [RELEASE] sugar-presence-service-0.84.2
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-presence-service/sugar-presence-service-0.84.2.tar.bz2 == News == * Release 0.84.2 (Simon Schampijer) * Connect to gabble immediatly when possible #10350 (Simon Schampijer) All the above patches did land in master as well. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.84.13
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.13.tar.bz2 == News == Release 0.84.13 (Simon Schampijer) Do not break if the string contains no conversion specifier #10372 (Simon Schampijer) Save title when closing #1948 (Simon Schampijer) Commit from Sugar Labs: Translation System by user juliano.: 36 of 36 messages translated (0 fuzzy). (Pootle daemon) All the above patches did land in master as well. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Tue, Oct 5, 2010 at 9:49 PM, C. Scott Ananian csc...@laptop.org wrote: If you're going to use something other than simple integers, I suggest either: a) a string of dotted integers. You should *always* be able to subdivide a release if necessary. Strings like peru belong (in my opinion) in release notes or the name of the activity or anywhere else. They don't tell you anything about version ordering. If the problem is that you can't put a new release between 0 and 1, why are you creating a system that causes the same problem, except between 0.0.0 and 0.0.1? Yes, you are right. The string part don't tell us anything about version ordering The idea is use a string of dotted integers to indicate the order and the string part only to indicate a customization. Why? We have activity groups today for this. Because a teacher, a kid or a technician from Uruguay can see Peru have a customization, download, test and use. But the customization part does not imply order because it's not logic use the alphabetic order (Peru Ruanda Uruguay?) Then I plan to ignore the customization when I compute the order. b) use the debian version numbering system *exactly*. It has been shown to work in the real world, and it is well documented. The current proposal is neither (yet). We do not need to burden the world with yet another ad-hoc numbering system. Please build on other people's work instead of re-inventing the wheel. Just because the debian system has features you don't *think* you need (yet) is not a reason to bypass it. There are great benefits to sharing a commons. I agree with not reinvent the wheel, but not with using the debian versions. Why not the Fedora, Gentoo or OSX? If you want, we will be using the linux kernel numbering system :) Of course, my preference is to keep the existing simple integers and solve the version precedence problem in other ways. Perhaps important activities should be encouraged to count by ten when increasing verson numbers -- or perhaps the tight dependency of Browse on a given Sugar version should be fixed. Integer number does not solve the problems we have today. Not the problems of the developers, but the downstreams. I am working with OLPC fixing Browse in sugar 0.84. The version we are using is Browse 108, but I cant release Browse 109 because already exists. The same problem we have, will have Dextrose or anybody who maintains a older branch. And count by ten it's not a good idea. A truely forward-thinking replacement would replace the integer version numbers with a git-style version tree. Just say, this activity replaces the activity bundle with manifest hash abcdef. That is more decentralized, and more accurate. Each activity could/should contain a list of URLs describing the canonical source for both itself (authoritative) and its (say) 10 immediate parents (non-authoritative). This proposal could be elaborated -- and it paves the way for a truely decentralized activity repository, where activities are created *and hosted* by children *on their own machines*. (Isn't this stil the vision of Sugar?) No. Git it's fantastic but it's not the solution to all. That would be a clear example of Second system effect [1] Gonzalo [1] http://en.wikipedia.org/wiki/Second-system_effect --scott ___ 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] [PATCH] Autocomplete functionality for the address does not work #2406
From: Simon Schampijer si...@schampijer.de see as well #2291 for more info. This one is important for 0.90. --- webtoolbar.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/webtoolbar.py b/webtoolbar.py index 69a3c8e..20616a4 100644 --- a/webtoolbar.py +++ b/webtoolbar.py @@ -160,7 +160,7 @@ class WebEntry(AddressEntry): def __view_button_press_event_cb(self, view, event): model = view.get_model() -path, col_, x_, y_ = view.get_path_at_pos(event.x, event.y) +path, col_, x_, y_ = view.get_path_at_pos(int(event.x), int(event.y)) if path: uri = model[path][self._COL_ADDRESS] self.activate(uri) -- 1.7.2.2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Hardcode env variable TERM to xterm #2394
From: Simon Schampijer si...@schampijer.de Patch needed in 0.90 --- terminal.py |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/terminal.py b/terminal.py index a0f97ba..4f05ed3 100644 --- a/terminal.py +++ b/terminal.py @@ -51,6 +51,9 @@ class TerminalActivity(activity.Activity): self.max_participants = 1 +# Hardcode to xterm due to a change in vte #2394 +os.environ['TERM'] = 'xterm' + toolbar_box = ToolbarBox() activity_button = ActivityToolbarButton(self) -- 1.7.2.2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] lists.sugarlabs.org relocation -- Wed, Oct 06 2010 20:00 GMT
All Sugar Labs mailing-lists are being relocated from the current listserver (solarsail) to our main server sunjammer.sugarlabs.org. The scheduled cut-off date is Wed, Oct 06 2010, at 20:00 GMT (16:00 EDT). We don't foresee any noticeable service interruption, but please watch out for missing posts and promptly report any anomaly to the service administrative contacts: http://wiki.sugarlabs.org/go/Service/lists This is the complete list of affected lists: ASLOActivity Library editors coordination list. BugsE-mail feed from the Sugar Labs bug tracking system. ColombiaLocal Labs Colombia Community-news Sugar community news weekly digest Dextrose[no description available] FourthGradeMath [no description available] GSoCSugarlabs' Google Summer of Code list IAEPA discussion list for Sugar and the learning theories that it espouses Italia Sugar Italia coordination Marketing Marketing discussion for the Sugar Learning Platform and its parent organization, Sugar Labs. SoaSDevelopment of live Sugar distributions somosazucar Lista de correo del equipo Somos-Azúcar Sugar-Desarrollo [no description available] Sugar-devel Discussion of Sugar development and other technical matters. Sugar-reports [no description available] Systems System administrators coordination -- // 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] [ANNOUNCE] Sucrose 0.90 Final Release
Dear Sugar community, Sucrose 0.90 is the latest version of the Sugar learning platform: Sugar promotes collaborative learning through Sugar Activities that encourage critical thinking, the heart of a quality education. Designed from the ground up especially for children, Sugar offers an alternative to traditional “office-desktop” software. Furthermore it provides a flexible and powerful platform for activity developers. Sugar is Free and Open Source Software and consists of Glucose, the base system environment; and Fructose, a set of demonstration activities. This new release contains many new features, performance and code improvements, bug fixes, and translations. Full release notes can be found at: http://wiki.sugarlabs.org/go/0.90/Notes Thanks everyone for your great contributions! On behalf of the Sugar community, Your Release Team ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406
Excerpts from simon's message of Wed Oct 06 13:57:20 +0200 2010: see as well #2291 for more info. This one is important for 0.90. A bit more background information would be nice. A one-line summary of the analysis in #2291 (i.e. input vs. screen, sub-pixel vs. whole- pixel coordinate systems) would suffice. Also the summary should be more active (e.g. fix address completion). Please adjust these before pushing. Thanks! Acked-By: Sascha Silbe sascha-...@silbe.org Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Alt-tab key does not work in F14 and sugar-emulator #2300
Hi, I have been bumping into [1] and Sascha pointed out that this is likely the same issue that we see in [2]. What is the status of this? Has this been taken upstream already? Regards, Simon [1] http://bugs.sugarlabs.org/ticket/2404 [2] http://bugs.sugarlabs.org/ticket/2300 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406
On 10/06/2010 03:20 PM, Sascha Silbe wrote: Excerpts from simon's message of Wed Oct 06 13:57:20 +0200 2010: see as well #2291 for more info. This one is important for 0.90. A bit more background information would be nice. A one-line summary of the analysis in #2291 (i.e. input vs. screen, sub-pixel vs. whole- pixel coordinate systems) would suffice. Also the summary should be more active (e.g. fix address completion). Please adjust these before pushing. Thanks! Acked-By: Sascha Silbesascha-...@silbe.org Sascha Thanks for the review. Will address your comments. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406
On 10/06/2010 03:23 PM, Simon Schampijer wrote: On 10/06/2010 03:20 PM, Sascha Silbe wrote: Excerpts from simon's message of Wed Oct 06 13:57:20 +0200 2010: see as well #2291 for more info. This one is important for 0.90. A bit more background information would be nice. A one-line summary of the analysis in #2291 (i.e. input vs. screen, sub-pixel vs. whole- pixel coordinate systems) would suffice. Also the summary should be more active (e.g. fix address completion). Please adjust these before pushing. Thanks! Acked-By: Sascha Silbesascha-...@silbe.org Sascha Thanks for the review. Will address your comments. Regards, Simon Hmm, Lucian was to quick. Lucian you should leave the ticket number in the comment. Actually, you should probably take it as is unless there is a reason to not do so. 'git-am' will do so for you. http://git.sugarlabs.org/projects/browse/repos/mainline/commits/e8130523d74e24be64362c723a9ebed1087fc521 Btw, the other commits were all intended to go on master and sucrose-0.90? You might want to branch off at this stage [1], if you have things that are not intended to land in 0.90. Regards, Simon http://wiki.sugarlabs.org/go/Development_Team/Release#Branching ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Alt-tab key does not work in F14 and sugar-emulator #2300
Excerpts from Simon Schampijer's message of Wed Oct 06 15:21:29 +0200 2010: I have been bumping into [1] [...] Just to avoid confusion: This has nothing to do with how you run Sugar (i.e. it will occur both with sugar-emulator and running Sugar as a regular desktop session). It is (according to Bernie - I didn't quite grok the code) a bug in some versions of Xorg and will appear on some distro versions, independent of how you installed Sugar (native distro packages or sugar-jhbuild). It's supposed to be fixed (haven't checked myself yet) in recent Xorg versions. Bernie has also written a patch that lets metacity work around the bug. With that patch applied, metacity-message disable-keybindings works fine again. ISTR somebody got in touch with the metacity maintainers to land the workaround, but don't know what got of it. To get the workaround (or an Xorg fix) into distros we will also need to report this bug to them. For Debian nobody did this so far and for Ubuntu there has been no follow-up from the reporter so the ticket is marked as Incomplete. [1] Sascha [1] https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/634415 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406
On 6 October 2010 14:31, Simon Schampijer si...@schampijer.de wrote: On 10/06/2010 03:23 PM, Simon Schampijer wrote: On 10/06/2010 03:20 PM, Sascha Silbe wrote: Excerpts from simon's message of Wed Oct 06 13:57:20 +0200 2010: see as well #2291 for more info. This one is important for 0.90. A bit more background information would be nice. A one-line summary of the analysis in #2291 (i.e. input vs. screen, sub-pixel vs. whole- pixel coordinate systems) would suffice. Also the summary should be more active (e.g. fix address completion). Please adjust these before pushing. Thanks! Acked-By: Sascha Silbesascha-...@silbe.org Sascha Thanks for the review. Will address your comments. Regards, Simon Hmm, Lucian was to quick. Lucian you should leave the ticket number in the comment. Actually, you should probably take it as is unless there is a reason to not do so. 'git-am' will do so for you. I don't think git-am works with gmail. http://git.sugarlabs.org/projects/browse/repos/mainline/commits/e8130523d74e24be64362c723a9ebed1087fc521 Btw, the other commits were all intended to go on master and sucrose-0.90? You might want to branch off at this stage [1], if you have things that are not intended to land in 0.90. Regards, Simon http://wiki.sugarlabs.org/go/Development_Team/Release#Branching There's no patches I wanted to apply that I wouldn't want in 0.90. Should I branch anyway? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406
On 10/06/2010 03:41 PM, Lucian Branescu wrote: On 6 October 2010 14:31, Simon Schampijersi...@schampijer.de wrote: On 10/06/2010 03:23 PM, Simon Schampijer wrote: On 10/06/2010 03:20 PM, Sascha Silbe wrote: Excerpts from simon's message of Wed Oct 06 13:57:20 +0200 2010: see as well #2291 for more info. This one is important for 0.90. A bit more background information would be nice. A one-line summary of the analysis in #2291 (i.e. input vs. screen, sub-pixel vs. whole- pixel coordinate systems) would suffice. Also the summary should be more active (e.g. fix address completion). Please adjust these before pushing. Thanks! Acked-By: Sascha Silbesascha-...@silbe.org Sascha Thanks for the review. Will address your comments. Regards, Simon Hmm, Lucian was to quick. Lucian you should leave the ticket number in the comment. Actually, you should probably take it as is unless there is a reason to not do so. 'git-am' will do so for you. I don't think git-am works with gmail. Maybe Tomeu has some helpful info on that: http://blog.tomeuvizoso.net/2010/09/fetching-patches-from-gmail.html http://git.sugarlabs.org/projects/browse/repos/mainline/commits/e8130523d74e24be64362c723a9ebed1087fc521 Btw, the other commits were all intended to go on master and sucrose-0.90? You might want to branch off at this stage [1], if you have things that are not intended to land in 0.90. Regards, Simon http://wiki.sugarlabs.org/go/Development_Team/Release#Branching There's no patches I wanted to apply that I wouldn't want in 0.90. Should I branch anyway? I am about to send this, but you get a sneaky preview :) Let me know if it does not make sense. To give a short answer to your question: No. === Branching === After the final release of a module, a branch should be created to host further stable development. If you do not have an 'unstable' commit yet you can leave your branch as is, as this ease the work for translators by not having to translate for two branches. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Autocomplete functionality for the address does not work #2406
On 10/06/2010 04:32 PM, Lucian Branescu wrote: On 6 October 2010 15:26, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Simon Schampijer's message of Wed Oct 06 15:31:07 +0200 2010: Hmm, Lucian was to quick. Hehe. No problem; I don't think this particular patch is going to matter when hunting down some issue and there's enough information in the description, even if just through an indirection (bug tracker). I just want to make sure we move in the right general direction. Good commit messages are getting more important as the number of contributors increases since no single person will have an overview of all the code (changes) anymore. This is why I pester new contributors and core developers alike with my complaints about commit messages. Yes, it's a good thing you do keep pestering people. And I should know better, too. +1 That is what reviews are for, to keep the quality high. Please keep on. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Schedule after Sugar 0.90.0 is released --- or After the game is before the game
Dear Sugar community, after successfully releasing 0.90 there should be a to celebrate what has been achieved and then we can start thinking what to do next. Some items are rather near term goals but there is as well the long road that leads to a new release --- 0.92 (1.0). === Branching === After the final release of a module, a branch should be created to host further stable development. If you do not have an 'unstable' commit yet you can leave your branch as is, as this ease the work for translators by not having to translate for two branches. The details about branching are described at [1]. === Bug fix release === To make sure we have the latest packages in F14 before the Final Change deadline happens the 18th of October [2], I added another bug fix release [3]. As Fedora is the bleeding edge at the moment we just backpack on this date. * 0.90.1 will be the 15th of October * 0.90.2 will be the 27th of October === Testing 0.90 === So far we have not seen much testing of 0.90 yet, that is why the bug fix releases noted above are so important to us. We need as well your help to actually discover the bugs! There are basically three ways how you can test as of today (besides using sugar-jhbuild): * Install Fedora 14 on a machine and install the Sugar desktop * Test using Sugar on a stick: Get one of the nightly snapshots [4] and put it on a usb key. You can find instructions about it at [5]. It is good to subscribe to the Soas mailing list (low traffic) [6] for announcement and discussions in that case. * If you have an XO (XO-1 or XO-1.5) you can use an image from [7]. If you are aware of any other distribution where Sugar 0.90 can be tested easily please comment. === 0.92 === Based on the GNOME schedule I made a first draft of the 0.92 roadmap. I reintroduced the Feature Acceptance milestone. The idea is that the discussion about a feature does not start one day before the feature freeze. As stated in the Feature policy [9] the acceptance is a sanity check, presumed in most cases to be a formality, to ensure that new features compliment Sugar guidelines and is manageable, prior to publicizing as officially targeted for the next release. The actual code must be ready by the Feature Freeze and is reviewed by the module maintainer. On behalf of the Sugar community, Your Release Team [1] http://wiki.sugarlabs.org/go/Development_Team/Release#Branching [2] https://fedoraproject.org/wiki/Releases/14/Schedule [3] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [4] http://alt.fedoraproject.org/pub/alt/nightly-composes/soas [5] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation [6] http://lists.sugarlabs.org/listinfo/soas [7] http://dev.laptop.org/~erikos/F14_builds/ [8] http://wiki.sugarlabs.org/go/0.92/Roadmap#Schedule [9] http://wiki.sugarlabs.org/go/Features/Policy#Acceptance_of_a_feature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Pulsing icon delayed by 5 seconds or so SL#2080
When we click on the icon of an activity we see a pulsing icon of that activity before the activity starts and usually there is a time delay between the clicking of the icon and appearance of the pulsing icon , where tha amount of delay differs by the complexity of the icon i.e. more complex the icon is larger is the delay. So here we tried to reduce that delay if not completely obliterate it , by making the duration of the first 5 pulses larger and during these 5 times the icon will only be zoomed in and not zoomed out so as to reducethe frame calculation load on the processor, Hence reducing the delay. --- src/sugar/graphics/animator.py |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/sugar/graphics/animator.py b/src/sugar/graphics/animator.py index 8fb298b..2bec8ff 100644 --- a/src/sugar/graphics/animator.py +++ b/src/sugar/graphics/animator.py @@ -25,7 +25,7 @@ import gobject EASE_OUT_EXPO = 0 EASE_IN_EXPO = 1 - +i=1 class Animator(gobject.GObject): @@ -140,6 +140,10 @@ class Animation(object): # last frame frame = self.end else: +for i in range(0,5): + easing = EASE_IN_EXPO + duration = duration*100 + i=i+1 if easing == EASE_OUT_EXPO: frame = change * (-pow(2, -10 * t / duration) + 1) + start elif easing == EASE_IN_EXPO: -- 1.7.2.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Developing Sugar - Help
Dhananjay, A reasonably good place to start learning about Sugar development would be this FLOSS Manual: http://en.flossmanuals.net/ActivitiesGuideSugar/Introduction This is about creating Activities that run under Sugar. James Simmons Date: Wed, 6 Oct 2010 19:01:34 +0530 From: Dhananjay Navaneetham mb.dhanan...@gmail.com Subject: [Sugar-devel] Developing Sugar - Help To: sugar-devel@lists.sugarlabs.org Message-ID: aanlktin1avlo+8635ixvub1w=yqsdwxj0kudg6lvs...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hi All, My name is Dhananjay, From India. I am currently pursuing my undergraduate degree. I would like to help build the sugar project. I can talk python and have a basic knowledge in C and pyQt development. I am open to learn any new technologies neede for my work. It would be very helpful if you can guide me to the development process. -- Regards, Dhananjay. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] multitouch on linux
Hi, this post makes very interesting points about multitouch UIs and its implementation in X. http://who-t.blogspot.com/2010/10/thoughts-on-linux-multitouch.html Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] A nice example
Hi! We could take one or two leaves out of Google Chromiums book [1]... Sascha [1] http://www.google.com/googlebooks/chrome/ [2] http://sandboxing.org/?page_id=13 sudo aptitude install bsdgames || sudo yum install bsd-games rot13 EOF Jbexvat vfbyngvba (if. artyrpgrq Envaobj) Havg grfgvat Nhgbzngrq HV grfgvat (cerqrsvarq grfgf + enaqbz vachg) Zhygvcebprffvat sbe vaqrcraqrag gnfxf HV srrqonpx ba penfurf EOF -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Freeing resources when switching away from activity (was: Re: [Bugs] #2413 UNSP: Hovering over the new activity toolbar activity icon so that sub toolbar appears triggers focus_out_event
Excerpts from Sugar Labs Bugs's message of Wed Oct 06 18:16:49 UTC 2010: I decided to keep poking at this for Physics and there does seem to be an activity level fix. As per a long, long lost email from Tomeu (thanks Tomeu, only took me two years to re-investigate and take action). I'm connecting a callback to the visibility-notify-event and then testing if data.state == gtk.gdk.VISIBILITY_FULLY_OBSCURED. Took me ages to track this down, but seems to be working a treat, I'm about to test outside of my VM dev environment and onto an XO-1: FWIW, this is what I do in one of my activities (a simple digital wall clock): class BigDigiClockActivity(activity.Activity): def __init__(self, handle): [...] self.can_freeze = True self._freeze_scheduled = False [...] self.time_label.connect('size-allocate', self._size_allocate_cb) self._unmap_cb_handler = None self.time_label.connect('unmap-event', self._unmap_cb) self.set_canvas(self.time_label) self.time_label.show() [...] # for debug output only _vis_map = { gtk.gdk.VISIBILITY_UNOBSCURED: 'unobscured', gtk.gdk.VISIBILITY_PARTIAL: 'partial', gtk.gdk.VISIBILITY_FULLY_OBSCURED: 'fully obscured', } def _visibility_cb(self, widget, event, *args): X window has changed. logging.debug('visibility = %r', self._vis_map.get(event.state, event.state)) self._set_may_freeze(event.state == gtk.gdk.VISIBILITY_UNOBSCURED) def _unmap_cb(self, *args): X window has been unmapped (i.e. is invisible now). logging.debug('unmap') self._set_may_freeze(False) def _size_allocate_cb(self, widget, allocation, *args): Size for self.time_label has been (re)set. Recalculate font size if necessary. [...] if self._unmap_cb_handler is None: window = self.time_label.get_parent() self._unmap_cb_handler = window.connect('unmap-event', self._unmap_cb) window.connect('visibility-notify-event', self._visibility_cb) window.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK) [...] def _set_may_freeze(self, may_freeze): self._hide_cursor(may_freeze) self.may_freeze = may_freeze if may_freeze: self._schedule_freeze() else: self._set_dcon_freeze(False) For other activities there might be a better match than size-allocate for when to connect the callbacks to the window. Perhaps we could move some of this to sugar.activity.activity.Activity so activity authors could concentrate on the resource freeing part? Maybe even coupled with a timer to prevent us from slowing down quick activity switches (i.e. the user switching forth and back between two activities in quick succession). Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Hardcode env variable TERM to xterm #2394
Excerpts from simon's message of Wed Oct 06 14:11:04 +0200 2010: Patch needed in 0.90 AFAICT it's needed on Fedora 14, not Sugar 0.90. Are we sure yet this was an intentional change by libvte and not just a mistake? In the latter case we should probably make the setting depend on specific libvte versions so we don't break if they decide to use a different set of control codes (= different $TERM) in the future. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse SL#1106, OLPC#8857: Re: Help with pending reviews
On 6 October 2010 20:19, Sascha Silbe si...@sugarlabs.org wrote: [Moving this to sugar-devel as I don't see any need to keep it private] Excerpts from Simon Schampijer's message of Tue Oct 05 14:58:24 +0200 2010: #1106 Browse: No preview in Journal for downloaded image https://patchwork.sugarlabs.org/patch/273/ I checked the pixbuf API and there is only composite-color-simple but in the end you need two buffers here as well. I think what we have is absolutely fine now. So if you don't object I would like Gonzalo to push it, so we can land it in 0.84 as well. #8857 - Browse fails to download some files with non-ascii characters https://patchwork.sugarlabs.org/patch/267/ This one looks good to me, too. I looked at the patch Tomeu already did, and this one just does the same thing. I think we can land that one, too. OK, then let's land both patches now (unless Lucian vetoes), but keep the tickets open so we can give a closer look later. Fine by me. Will you do it Sascha, or shall I? Please fix the summaries before pushing. E.g.: fix downloading files with non-ASCII characters (OLPC#8857) generate preview image for downloaded images (SL#1106) Thanks for taking a look, Simon! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse SL#1106, OLPC#8857: Re: Help with pending reviews
Excerpts from Lucian Branescu's message of Wed Oct 06 21:30:44 +0200 2010: OK, then let's land both patches now (unless Lucian vetoes), but keep the tickets open so we can give a closer look later. Fine by me. Will you do it Sascha, or shall I? Gonzalo, you already have push rights, so please push yourself. Please remember: Please fix the summaries before pushing. E.g.: fix downloading files with non-ASCII characters (OLPC#8857) generate preview image for downloaded images (SL#1106) git commit --amend should do the trick. If you have dirty history (i.e. other patches that are not in mainline yet) please create a branch carrying only those two patches and push that branch: git checkout -b to-push origin/master git cherry-pick commit ID of first patch git commit --amend (fix summary) git cherry-pick commit ID of second patch git commit --amend (fix summary) git push origin to-push:master You can remove the branch afterwards: git checkout master git branch -d to-push Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 6:58 AM, Gonzalo Odiard gonz...@laptop.org wrote: Then I plan to ignore the customization when I compute the order. So why is it there? b) use the debian version numbering system *exactly*. It has been shown to work in the real world, and it is well documented. The current proposal is neither (yet). We do not need to burden the world with yet another ad-hoc numbering system. Please build on other people's work instead of re-inventing the wheel. Just because the debian system has features you don't *think* you need (yet) is not a reason to bypass it. There are great benefits to sharing a commons. I agree with not reinvent the wheel, but not with using the debian versions. Why not the Fedora, Gentoo or OSX? If you want, we will be using the linux kernel numbering system :) Yes, please. Using anything from the *commons* instead of inventing a new *bespoke* system is preferable. Build connected communities, not islands. I am working with OLPC fixing Browse in sugar 0.84. The version we are using is Browse 108, but I cant release Browse 109 because already exists. The same problem we have, will have Dextrose or anybody who maintains a older branch. And count by ten it's not a good idea. Seems like count by ten solves the particular problem you have. It's the simplest possible solution that could work, which is a surefire way to avoid Second system effect [1] [1] http://en.wikipedia.org/wiki/Second-system_effect Either solve the problem correctly, or solve it as simply as possible. The current proposal does neither, and just adds a new layer of poorly documented ad-hoc-ery. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse SL#1106, OLPC#8857: Re: Help with pending reviews
Thanks Sasha, I will push them. Gonzalo On Wed, Oct 6, 2010 at 5:37 PM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Lucian Branescu's message of Wed Oct 06 21:30:44 +0200 2010: OK, then let's land both patches now (unless Lucian vetoes), but keep the tickets open so we can give a closer look later. Fine by me. Will you do it Sascha, or shall I? Gonzalo, you already have push rights, so please push yourself. Please remember: Please fix the summaries before pushing. E.g.: fix downloading files with non-ASCII characters (OLPC#8857) generate preview image for downloaded images (SL#1106) git commit --amend should do the trick. If you have dirty history (i.e. other patches that are not in mainline yet) please create a branch carrying only those two patches and push that branch: git checkout -b to-push origin/master git cherry-pick commit ID of first patch git commit --amend (fix summary) git cherry-pick commit ID of second patch git commit --amend (fix summary) git push origin to-push:master You can remove the branch afterwards: git checkout master git branch -d to-push Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ 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] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 4:47 PM, C. Scott Ananian csc...@laptop.org wrote: On Wed, Oct 6, 2010 at 6:58 AM, Gonzalo Odiard gonz...@laptop.org wrote: Then I plan to ignore the customization when I compute the order. So why is it there? To allow identification. But what Gonzalo pointed out is that in the case of 1.1-peru vs 1.1-argentina, vs 1.1, it makes sense to match them as equal. They shouldn't trigger an upgrade from one to the other. I had a long chat with Gonzalo on the topic of versioning. Initially, I advocated strongly for something with the expresiveness of dpkg's versioning. However, that's wrong. We need to use a clear _subset_ of what dpkg, rpm, portage(... etc) can do, so the distro packager retains its flexibility (see: epoch). It is true, dpkg considers 1.1-peru to be an upgrade over 1.1-argentina, due to alpha ordering. But that has no useful meaning. Either solve the problem correctly, or solve it as simply as possible. This solves it as simply as possible. 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] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 5:00 PM, Martin Langhoff martin.langh...@gmail.com wrote: Initially, I advocated strongly for something with the expresiveness of dpkg's versioning. However, that's wrong. We need to use a clear _subset_ of what dpkg, rpm, portage(... etc) can do, so the distro packager retains its flexibility (see: epoch). Defining the version string as identical to the pre-epoch portion of a debian version string says a lot more in 11 words -- and with more precision -- than the entirely of the dotted version string proposal so far. This is the power we get from *building* on other's work, instead of reinventing it. (But we should remember what problem debian is solving with epoch numbers, and think really hard about why this could never ever ever happen to us before getting rid of them.) You could make a similar proposal based on redhat version strings, etc. We all *think* we need a subset right now. And then you'll find that subset grow, and mutate, etc, etc. We are all better off if we implement a well understood standard, even if we don't think we need all of its power immediately. It is true, dpkg considers 1.1-peru to be an upgrade over 1.1-argentina, due to alpha ordering. But that has no useful meaning. My personal feeling is that the peru and argentina part isn't really a version number, it's something else, which is misplaced here. But I don't feel as strongly about that. Either solve the problem correctly, or solve it as simply as possible. This solves it as simply as possible. I've outlined several simpler solutions. QED. Again, I think either the slightly more complicated (but more precise and easier to describe) solution (debian version numbers, exactly), or a simpler solution (say, just use only even version numbers for upstream releases, save odd numbers for localization teams) is preferred to the present proposal, which I think is both too complicated (by defining its own ad-hoc version string semantics) and too simple (0.1 possible, 0.0.1 impossible, at least according tohttp://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions). I think that's exactly the wrong way to optimize. Sugar doesn't need yet another ad-hoc undocumented scheme. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
I support the proposal for dotted activity version numbers, but I don't like at all the idea of using -peru or -something on the end that isn't a version number. It should go in some other metadata. I agree with Scott too. -- James Cameron System Test Coordinator One Laptop per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel