Re: [Sugar-devel] [Dextrose] Pending patchs for Paint
Excerpts from Martin Langhoff's message of Fri Oct 22 20:58:22 +0200 2010: I certainly hope that each bundle released by Sugar Labs or associated Sure. Not everything's perfect. Let's make sure we drag things back to normality. Re-reading my sentence and reading your reply makes me wonder whether it was too strong wording. If so, please accept my apologies and attribute this to the fact that I'm not a native speaker. As a developer, it's important to me that the corresponding source code for each released object (e.g. activity bundles) is easily accessible. If someone forgets to add the tag, that's simply a mistake and part of normal operation (we are just humans after all). What upset me was the fact that apparently some tags were left out _on_ _purpose_ and this is what I argued against (because without discussion we cannot agree on doing things differently in the future). If something's controversial it may not be on 'master' but there's no reason to have it in the sugarlabs git repos where everyone looks for src. I suppose this should have read *not* to have it? 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 v5 sugar] Downgrading activities not allowed. (#2164)
On Sat, Oct 23, 2010 at 01:11:18AM +0530, anub...@seeta.in wrote:
Downgrading an activity is now made possible. When a .xo file of a version
older
than the currently installed version is clicked, a downgrading option is made
available, by popping up of a confirmation alert. Depending upton the choice
selected you can downgrade the activity.
upton is a brand of tea here. Perhaps you mean upon.
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
+def older_version_clicked(metadata):
+alert = ConfirmationAlert()
+alert.props.title = _('Newer Version Found')
+alert.props.msg = _('Newer version of the chosen activity is available \
+do you still want to continue with the installation? \
+ If Yes click Ok and the activity icon of the older \
+.xo file in the Journal')
Huh? I don't understand what this text means, it seems to be an
incomplete english sentence. Let me remove the program code to expose
the message the user will get:
Newer Version Found: Newer version of the chosen activity is available
do you still want to continue with the installation? If Yes click Ok
and the activity icon of the older .xo file in the Journal
Problems with this english text are:
0. Newer Version Found doesn't really describe the situation, that of
an update reversal, or downgrade,
1. the first sentence is incorrectly formed; it actually contains two
sentences without separating punctuation,
2. the second sentence ends abruptly without completing the phrase,
3. the second sentence asks the user to click the activity icon of the
older .xo file in the Journal, which doesn't seem right,
4. the chosen activity might be replaced by the name of the activity,
5. the version number already installed and the version number
requested are not mentioned,
6. while one might guess that clicking Cancel will stop and unwind the
operation, it isn't clear what clicking Ok will do.
It is very important to get this message correct and succinct, since it
needs to be translated into other languages.
--
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] Edit/audit wikipedia activity
Hi Martin, Martin Langhoff martin.langh...@gmail.com writes: Do we have any easy way to do this? Is any of the many static wikipedia project already working on audit/edit/polish facilites we can reuse (that accepts our format)? FYI I forwarded your question to the maintainer of Kiwix (http://www.kiwix.org/) - he is currently actively working on a kiwix.xo activity, and I agree your point is important. I'll follow-up with answers, if any. Best, -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar 09/21] style cleanup: prefer ' for strings
Excerpts from James Cameron's message of Mon Oct 18 06:29:45 +0200 2010: [src/jarabe/util/emulator.py] -os.environ['DISPLAY'] = :%d % (display) +os.environ['DISPLAY'] = ':%d' % (display, ) /me raises eyebrow ... wasn't done in extensions/deviceicon/network.py GsmPalette.update_stats(). I've reverted the format part of the above change. It caught my eye (pylint didn't detect it) while doing the string changes, but we should probably rather check and fix all format strings as a separate clean-up later. Anything else you'd like changed or do you think it's ready to go in? 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 sugar 00/21] style cleanup series
Excerpts from Aleksey Lim's message of Thu Oct 21 00:58:33 +0200 2010: Whats the satatus of pylint patches? I'm waiting for an OK from Simon and you. James was already kind enough to review both pending patch series. I'm planing to propose another set of patches that are scatered among glucose modules and it would be useful to base them on pylint commits. What are you planning (just so I know where to expect conflicts)? btw maybe push pylint patches by one commit? Technically possible (and easy enough), but I'm not sure it's a good idea. With split patches it's easy to see what each individual commit changed and repeat the change even in a diverged code base. OTOH git combines all the commits before merging anyway... 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 sugar 00/21] style cleanup series
On Sat, Oct 23, 2010 at 01:21:06PM +0200, Sascha Silbe wrote: Excerpts from Aleksey Lim's message of Thu Oct 21 00:58:33 +0200 2010: Whats the satatus of pylint patches? I'm waiting for an OK from Simon and you. James was already kind enough to review both pending patch series. I've already applied your patches to ds, and ok w/ the rest. I'm planing to propose another set of patches that are scatered among glucose modules and it would be useful to base them on pylint commits. What are you planning (just so I know where to expect conflicts)? http://lists.sugarlabs.org/archive/sugar-devel/2010-October/028196.html They are based on old code, will tweak them after applying these ones. btw maybe push pylint patches by one commit? Technically possible (and easy enough), but I'm not sure it's a good idea. With split patches it's easy to see what each individual commit changed and repeat the change even in a diverged code base. OTOH git combines all the commits before merging anyway... np, I'm just used to push such patches by one commit. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Re-initiate Packaging Team
On Thu, Oct 21, 2010 at 08:02:40AM +, Aleksey Lim wrote: Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. I've initiated http://wiki.sugarlabs.org/go/Platform_Team with this statement (which is different by meaning w/ previous one): The mission of Platform Team is providing, as unified as possible, runtime and development time environments for all sugar doers. In contrast with Development and Activity teams, Platform Team mission is not about development process itself but about supporting developers by providing the same set of possible dependencies and giving a common distribution method. Platform Team will work closely with GNU/Linux distributions that provide sugar and will try to round all differences between them to make sugar doers' life easier. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar BTW, maybe Packaging is not appropriate name, any ideas? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Mailing list digest mode (was: RE: [PATCH sugar 03/21] pep8 cleanup: fix number of blank lines)
Excerpts from John Tierney's message of Sun Oct 17 00:37:42 +0200 2010: jt4sugar or JT here. I'm signed up on Sugar-Devel but only digest. I just got about 20 emails with [Sugar-devel] [Patch...] since I'm only signed up as digest I believe something is out of kilter. Sorry for the late reply, I forgot to revisit your mail as it was buried within the patch series (which I was waiting for feedback on). We recently disabled digest mode for sugar-devel because it caused a lot of trouble (breaking threads, especially during patch review). Most modern MUAs (mail programs) provide methods to deal with high-traffic mailing lists that are superior to digest mode. Even simple webmailers usually provide at least some basic filtering to folders capabilities. If you need help setting it up, feel free to ask on #sugar. While I don't know Hotmail myself, but there's a step-by-step guide for setting up folder filters on [1]. The best way to check for mails on sugar-devel is to do a substring match on sugar-devel.lists.sugarlabs.org for the List-Id: header or a full match on mailto:sugar-devel@lists.sugarlabs.org for the List-Post: header. Second best is matching the envelope sender (Return-Path:) against sugar-devel-boun...@lists.sugarlabs.org. Filtering by subject is possible, but will also catch private replies to a thread started on sugar-devel. Sascha [1] http://email.about.com/od/windowslivehotmailtips/qt/How_to_Set_Up_an_Incoming_Mail_Filter_in_Windows_Live_Hotmai.htm -- 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] How to copy something from the Journal to a pendrive? FotoToon export?
Excerpts from tom.staub...@fhtw-berlin.de's message of Sun Oct 17 16:44:40 +0200 2010: So what would be the right medium to interchange data between Sugar systems? That's a good question I'm afraid. Even file transfer (sending entries from the Journal to a friend) doesn't preserve most of the metadata, though it does at least transmit the MIME type. I've filed an RFE (Request for enhancement) [1] so we remember to fix this. [registering MIME types for activities] Does this mean that in the FotoToon example I could manually add a mimetypes.xml to the .zip file, remove the zip extension and FotoToon should be able to recognize this again? No. The mimetypes.xml needs to be part of the activity bundle, i.e. the program code. Putting it inside a random data store entry won't have an effect. There is a way to transfer a data store entry including all of its metadata: Journal Entry Bundles [3]. Unfortunately the only way (that I know of) to _create_ such a bundle is my Backup activity [4] and it stores the entire data store instead of a single entry. Would the copy-from-journal / copy-to-journal scripts do the trick? Even copy-to-journal can only set the MIME type, but not the ID of the activity, I'm afraid. Filed another RFE [2] about that. It also uses a different MIME type and file extension (to make sure that these bundles are handled by the Restore activity [5] which can cope with JEBs containing multiple entries, unlike the Journal) but that would be easy enough to work around (by renaming the file). But it would mean that if I'm doing a Backup on User1's XO and doing a Restore on User2's XO, User2's data is lost and she's got all the stuff from User1 in her journal, right? Only if you're using the Dextrose Journal Backup Feature [3]. The Backup [4] and Restore [5] activities however have been carefully designed not to destroy user data. Entries are never deleted and only overwritten if the backup bundle contains an (apparently) more recent version than the Journal. Sascha [1] https://bugs.sugarlabs.org/ticket/2473 [2] https://bugs.sugarlabs.org/ticket/2472 [3] https://wiki.sugarlabs.org/go/Dextrose/Resources/Journal-backup [4] http://activities.sugarlabs.org/en-US/sugar/addon/4326 [5] http://activities.sugarlabs.org/en-US/sugar/addon/4327 -- 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 v5 sugar] Downgrading activities not allowed. (#2164)
James and Aleksey,
Appreciate your feedback.
We have made quite a number of mistakes in our previous patch. We have
incorporated your recommendations, and are sending a new revised patch to
the list serv.
Kindly let us know whether it meets all the requirements. Thanks again for
reviewing the patch submissions.
Regards,
Anubhav
On Sat, Oct 23, 2010 at 3:00 PM, James Cameron qu...@laptop.org wrote:
On Sat, Oct 23, 2010 at 01:11:18AM +0530, anub...@seeta.in wrote:
Downgrading an activity is now made possible. When a .xo file of a
version older
than the currently installed version is clicked, a downgrading option is
made
available, by popping up of a confirmation alert. Depending upton the
choice
selected you can downgrade the activity.
upton is a brand of tea here. Perhaps you mean upon.
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
+def older_version_clicked(metadata):
+alert = ConfirmationAlert()
+alert.props.title = _('Newer Version Found')
+alert.props.msg = _('Newer version of the chosen activity is
available \
+do you still want to continue with the installation? \
+ If Yes click Ok and the activity icon of the
older \
+.xo file in the Journal')
Huh? I don't understand what this text means, it seems to be an
incomplete english sentence. Let me remove the program code to expose
the message the user will get:
Newer Version Found: Newer version of the chosen activity is available
do you still want to continue with the installation? If Yes click Ok
and the activity icon of the older .xo file in the Journal
Problems with this english text are:
0. Newer Version Found doesn't really describe the situation, that of
an update reversal, or downgrade,
1. the first sentence is incorrectly formed; it actually contains two
sentences without separating punctuation,
2. the second sentence ends abruptly without completing the phrase,
3. the second sentence asks the user to click the activity icon of the
older .xo file in the Journal, which doesn't seem right,
4. the chosen activity might be replaced by the name of the activity,
5. the version number already installed and the version number
requested are not mentioned,
6. while one might guess that clicking Cancel will stop and unwind the
operation, it isn't clear what clicking Ok will do.
It is very important to get this message correct and succinct, since it
needs to be translated into other languages.
--
James Cameron
http://quozl.linux.org.au/
___
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 v6 sugar] Downgrading activities not allowed. (SL #2164)
Activity can be downgraded on the availability of an older .xo version of an
activity. An alert pops up on downloading an older .xo file of an activity,
which asks the user to make a selection on whether to move to an older
activity version or not.
Co-authored-by: Anubhav Aggarwal anub...@seeta.in, Shanjit Singh Jajmann
shan...@seeta.in
---
v1 - v2. Inline function used, signal emission condition revised and global
variables removed. Recommendations by James Cameron and Aleksey Lim added.
v2 - v3. Used misc.resume.
v3 - v4. Changes in the copyright of the new file.
v4 - v5. Alert shown in the same window as the journal.
v5 - v6. Static variable removed, name of the functions changed.
Recommendations by James Cameron and Aleksey Lim added.
src/jarabe/journal/journalactivity.py |6 ++--
src/jarabe/journal/journalwindow.py | 33 +++
src/jarabe/journal/misc.py| 56 +++--
src/jarabe/model/bundleregistry.py|7 +++-
4 files changed, 87 insertions(+), 15 deletions(-)
create mode 100644 src/jarabe/journal/journalwindow.py
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..a48063b 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -44,6 +44,7 @@ from jarabe.journal.journalentrybundle import
JournalEntryBundle
from jarabe.journal.objectchooser import ObjectChooser
from jarabe.journal.modalalert import ModalAlert
from jarabe.journal import model
+from jarabe.journal.journalwindow import JournalWindow
J_DBUS_SERVICE = 'org.laptop.Journal'
J_DBUS_INTERFACE = 'org.laptop.Journal'
@@ -102,11 +103,10 @@ class JournalActivityDBusService(dbus.service.Object):
def ObjectChooserCancelled(self, chooser_id):
pass
-class JournalActivity(Window):
+class JournalActivity(JournalWindow):
def __init__(self):
logging.debug(STARTUP: Loading the journal)
-Window.__init__(self)
-
+JournalWindow.__init__(self)
self.set_title(_('Journal'))
self._main_view = None
diff --git a/src/jarabe/journal/journalwindow.py
b/src/jarabe/journal/journalwindow.py
new file mode 100644
index 000..957f1eb
--- /dev/null
+++ b/src/jarabe/journal/journalwindow.py
@@ -0,0 +1,33 @@
+#Copyright (C) 2010 Software for Education, Entertainment and Training
Activities
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+import gtk
+from sugar.graphics.window import Window
+
+
+_journal_window = None
+
+
+class JournalWindow(Window):
+
+def __init__(self):
+global _journal_window
+Window.__init__(self)
+_journal_window = self
+
+
+def get_journal_window():
+return _journal_window
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
index 32a2847..388837c 100644
--- a/src/jarabe/journal/misc.py
+++ b/src/jarabe/journal/misc.py
@@ -27,8 +27,10 @@ from sugar.activity import activityfactory
from sugar.activity.activityhandle import ActivityHandle
from sugar.graphics.icon import get_icon_file_name
from sugar.graphics.xocolor import XoColor
+from sugar.graphics.alert import ConfirmationAlert
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
+from sugar.bundle.bundle import AlreadyInstalledException
from sugar.bundle.contentbundle import ContentBundle
from sugar import util
@@ -36,6 +38,7 @@ from jarabe.view import launcher
from jarabe.model import bundleregistry, shell
from jarabe.journal.journalentrybundle import JournalEntryBundle
from jarabe.journal import model
+from jarabe.journal import journalwindow
def _get_icon_for_mime(mime_type):
generic_types = mime.get_all_generic_types()
@@ -150,6 +153,7 @@ def get_activities(metadata):
def resume(metadata, bundle_id=None):
registry = bundleregistry.get_registry()
+version_downgrade = False
if is_activity_bundle(metadata) and bundle_id is None:
@@ -159,19 +163,24 @@ def resume(metadata, bundle_id=None):
bundle = ActivityBundle(file_path)
if not registry.is_installed(bundle):
logging.debug('Installing activity bundle')
-registry.install(bundle)
+try:
+registry.install(bundle)
+except AlreadyInstalledException:
+
Re: [Sugar-devel] [Dextrose] [PATCH v3 PaintActivity]Paint - Rect. Marquee icon changes erratically(olpc #5882)
On Thu, 2010-10-21 at 14:37 -0300, Gonzalo Odiard wrote: Much better. Now you can change if self.area.text_in_progress == True: by if self.area.text_in_progress: and if self.area.text_in_progress == True: by if not self.area.text_in_progress: You surely meant False here :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
On Fri, 2010-10-22 at 04:19 +0530, Manusheel Gupta wrote: Please us know if the patch meets the requirements. If yes, can we add the documentation of the approach followed by us at the wiki? If we're still taking about the v5 patch that was posted to the list, I don't understand how this change is supposed to fix the bug: +if self._count 2: + self.update() +self._count = self._count + 1 Skipping the first frame of the animation unconditionally is wrong and isn't the same thing of skipping frames dynamically, based on the time elapsed to render the previous frame. I feel like we're trying a number of random tweaks without addressing the root cause of the problem. Perhaps Anurag could work on a fix in team with other Seeta developers? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity updates
On Thu, 2010-10-21 at 14:47 +0100, Gary Martin wrote: 0.90 has been a little rough so far on Activities, not really Sugar changes, but all the churn going on in F14 dependencies. 0.92 is likely going to be much, much more painful, with perhaps the majority of existing activities breaking, and requiring a maintenance release just to launch. :( We can't do much about API breakage caused by the OS, but we don't ever need to break the API of sugar-toolkit. We could just retain the old toolkit and install new versions in parallel. An simpleminded way to do it would be switching the module name from sugar to sugar2. A slightly better approach would be hiding the new sugar-toolkit in a separate directory that would be added to the PYTHONPATH before launching the activity, but only if the activity.info advertises compatibility with the new API. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] looking to contribute
Gary, Thanks for the help - it provided all the clarification we needed :)! Our group will be meeting up in the upcoming week to figure out the best plan of attack. We look forward to contributing to this Activity. Thanks, WSU CS401 Group On Fri, Oct 22, 2010 at 9:59 AM, Gary C Martin garycmar...@googlemail.comwrote: Hi Jon et al, Hope you don't mind me cc:ing the sugar-devel mail-list, it helps give other folks a head's up on likely activity. Folks may want to join the mail-list as it's useful for posting questions, getting help – though traffic can be a little noisy at times. On 20 Oct 2010, at 19:24, WSU CS401 wrote: On Wed, Oct 20, 2010 at 2:04 PM, Gary C Martin garycmar...@googlemail.com wrote: Hi Lindsey, On 19 Oct 2010, at 19:51, WSU CS401 wrote: Hello, We are four college students looking to contribute to sugar activities. Your activities caught our eye and we were wondering, as you are a maintainer, if you have any projects/fixes (small at first) that we could help with as we are new to sugar. Did you have an activity in mind? Physics, Clock, Labyrinth, Calculate, Moon are the ones I try specifically to help maintain in my free time, though Moon is the only one I originally wrote, the others are all adopted. There are quite a few activities out there that could do with some minimal maintenance/release effort, perhaps a few feature additions if something grabs your interest and your time allows. One quick example: I've been hoping to pick up Bridge at some point: http://wiki.laptop.org/go/Bridge It's based on the same code as Physics and I've plenty of patches there that I'm sure could be easily made to Bridge with minimal effort. It's a fun little game that needs a bit of tidy-up (was originally written as part of a game jam over a few days). As far as features, it could do with some game level progression (only one level at the moment), perhaps a budget system where you only have so many coins to spend on building materials. Someone did at least upload the Bridge-2 bundle to activities.sugarlabs.org: http://activities.sugarlabs.org/en-US/sugar/addon/4231 But they made no changes and didn't make a git repository for the source code, would be a fine candidate to help out on. Shout if it doesn't grab your interest, sure there are other I can find that are in need of help. That sounds excellent, just the kind of thing we were looking for. How should we go about starting this project? We have done a lot of research, but we are still unsure of how sugar's development cycle actually works. Thanks a lot for your reply! :) Good question ;) OK, so I've created some Sugar Labs resources for Bridge to get things going. First a quick wiki page template, nothing too exciting but feel free to tinker and add to it as needed: http://wiki.sugarlabs.org/go/Activities/Bridge The git source repository is here http://git.sugarlabs.org/projects/bridge Each member of the team that's going to work on code should create a user account on git.sugarlabs.org. On the machine/home directory you each intend to work from you'll need to create a SSH key pair, and add the public key to your git.sugarlabs.org accounts, this allows you to git push your changes back to the main repository. Once you have accounts, I can either add commit privileges for you to the Bridge mainline, or initially the best workflow is usually to create your own clone or clones to experiment with first: http://git.sugarlabs.org/projects/bridge/repos/mainline (login to see the Clone repository link to the right) I've filed a request for a Trac component, we use this to collect bug/enhancement/task tickets, if you also create accounts at bugs.sugarlabs.org tickets can easily be assigned so we know who working on what issue (useful if there are a number of folks all wanting to work in parallel): http://bugs.sugarlabs.org/ticket/2470 The usual workflow when there is more than one of you working is something like: - file some Trac tickets for various bugs/enhancements/tasks making sure the component is set to Bridge. - assign tickets you want to work on to yourself so others can see who is doing what - make yourself a local clone of a repository ready to work on - make the _minimal_ code changes necessary for your assigned ticket - once your happy and tested locally, push your clean changes back to the public repository - request a merge of your public repository into mainline - wait for review feedback or notification that your change was accepted and merged - repeat BTW I'm no master git user, I try to stick to a simple git workflow so as not to get into a source code tangle :) Have a skim through the Activity Team wiki pages, it has various FAQs and links to using git and other useful topics that may help get things up and running:
Re: [Sugar-devel] [Dextrose] [PATCH v3 PaintActivity]Paint - Rect. Marquee icon changes erratically(olpc #5882)
Yes, was a copy paste error, but the developers are smart enough :) Gonzalo On Fri, Oct 22, 2010 at 11:29 AM, Bernie Innocenti ber...@codewiz.orgwrote: On Thu, 2010-10-21 at 14:37 -0300, Gonzalo Odiard wrote: Much better. Now you can change if self.area.text_in_progress == True: by if self.area.text_in_progress: and if self.area.text_in_progress == True: by if not self.area.text_in_progress: You surely meant False here :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- Gonzalo Odiard ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] stepping down as maintainer
On Tue, Oct 19, 2010 at 11:50 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, for personal reasons have to drastically reduce my involvement in the project. Will be leaving maintenance of my modules and unsubscribing from the mailing lists. My place on the board is vacant from now on and I'll be adding to the wiki the new vacancies: http://wiki.sugarlabs.org/go/Vacancies Cheers and good luck, Tomeu Sugar Labs lost its lead developer. It is unfortunate that no-one has done a public review of the reasons and implications of Tomeu quiting. Tomeu's leaving is significant enough that Sugar Labs should take a hard look at what is working, what is not working, and how to fix the pieces that are not working. At the risk of angering pretty much everybody Sugar Labs has three fundamental problems. Sugar Labs is optimistic to the point of untruthfulness. Sugar Labs is lead by veto rather than vision. There is a lack of accountability to stakeholders. Sugar Labs is optimistic to the point of untruthfulness. The main _symptom_ of this is the current state of Sugar Labs. Sugar is not perfect. Sugar Labs is not perfect. The _disease_ is an adherence to faulty premises rather then the use of the Scientific Method of: Ask a question. Do background research. Construct a hypothesis. Test your hypothesis by doing an experiment. Analyze your data and draw a conclusion. Communicate your results. Premise 1. Sugar is open source, written in python, and the source is easily available. Therefore kids will develop and improve Sugar. What fraction of useful and usable improvements have been committed into sugar by the target users. The key metric is commit ratio. Everyone has an antidote about some budding hacker. As with the patch acceptance process, developing Sugar requires more than solving logic problems. In theory this premise is sound, and desirable, the overall technical capabilities of a nation will improve as more people are exposed to Sugar at an early age. The question become what is the time lag between exposure to Sugar and useful contribution to Sugar? Premise 2. Sugar is open source, written in python, and the source is easily available. Therefore deployments will develop Sugar. What fraction of useful and usable improvements have been committed into sugar by deployments. In theory this premise is sound, and desirable, Sugar deployments and their associated support infrastructure provide a catalyst for building local technical capability. The question becomes, considering the limited resources of deployments, is the benefit of contributing upstream worth the cost? Premise 3. Any problems with Sugar are because the user, teacher, or deployment is not smart or motivated enough. What are the usability concerns of users, teachers, and deployments? How are those concerns being addressed? In theory this is true yet undesirable. A significantly motived person _can_ figure out just about anything. The primary decision making factor for users, teachers, and deployments is marginal benefit. Does using and learning to use the laptop/Sugar prove a marginal benefit over other learning opertunities. Sugar Labs is lead by veto rather than vision. A _symptom_ is the development process. It it easy to have fix commited to Fedora or OLPC. It is hard to have a fix commited to Sugar Labs. When someone sends a useful fix to either OLPC or Fedora, a senior developer takes the patch, review it, fixes it up (if necessary) and thanks the contributor. This provides an incentive and on-ramp for less experienced developers to participate and contribute. Sugar Labs rejects most patches. Once a patch is technically correct, which can take several iterations for a new developer, it is forward to another developer for their vote of approval. The end result is that very few people bother to submitted patches upstream. The _disease_ is a marginalization of anyone who dissents. As a result no one is willing to take a risk. There is an unwritten checklist for participation. 1) Are you a knowledgeable, experienced, and patient open source developer? 2) Is your goal open source advocacy? 3) Are you a strict constructionist? 4) This results in very low participation in Sugar Labs. There is the lack of accountability to stakeholders. The Board of Directors of an non-profit organization the board reports to stakeholders, particularly the local communities which the nonprofit serves. The Executive Director is responible for carrying out the strategic plans and policies as established by the board of directors. As a starting point for bringing Sugar Labs out its current crisis, I suggest the following plan: 1. Each Oversight board member, or candidate, identify a stakeholder and spend the next 12 months advocating for that stakeholder. Advocating includes: Identify the specif needs and goals of the stakeholder. Identify the resources that stakeholder can contribute to Sugar Labs. Identify how
