[Sugar-devel] [RELEASE] sugar-0.84.23

2010-10-06 Thread Simon Schampijer
== 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

2010-10-06 Thread Simon Schampijer
== 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

2010-10-06 Thread Sugar Labs Activities
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

2010-10-06 Thread Simon Schampijer
== 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

2010-10-06 Thread Simon Schampijer
== 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

2010-10-06 Thread Gonzalo Odiard
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

2010-10-06 Thread simon
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

2010-10-06 Thread simon
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

2010-10-06 Thread Bernie Innocenti
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

2010-10-06 Thread Simon Schampijer
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

2010-10-06 Thread Sascha Silbe
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

2010-10-06 Thread Simon Schampijer
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

2010-10-06 Thread Simon Schampijer
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

2010-10-06 Thread Simon Schampijer
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

2010-10-06 Thread Sascha Silbe
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

2010-10-06 Thread Lucian Branescu
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

2010-10-06 Thread Simon Schampijer
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

2010-10-06 Thread Simon Schampijer
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

2010-10-06 Thread Simon Schampijer
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

2010-10-06 Thread Anurag Chowdhury
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

2010-10-06 Thread James Simmons
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

2010-10-06 Thread Tomeu Vizoso
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

2010-10-06 Thread Sascha Silbe
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

2010-10-06 Thread Sascha Silbe
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

2010-10-06 Thread Sascha Silbe
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

2010-10-06 Thread Lucian Branescu
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

2010-10-06 Thread Sascha Silbe
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

2010-10-06 Thread C. Scott Ananian
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

2010-10-06 Thread Gonzalo Odiard
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

2010-10-06 Thread Martin Langhoff
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

2010-10-06 Thread C. Scott Ananian
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

2010-10-06 Thread James Cameron
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