Re: [sugar] Report on OLPC in Ethiopia
Hi Gary, what about stemming the words? You may be able to use an english stemmer from xapian using the python bindings (not sure though). Regards, Tomeu On Tue, May 20, 2008 at 3:38 AM, Gary C Martin [EMAIL PROTECTED] wrote: Hi Yamandu, I fed this into my self organising map (SOM) code. Here's the summary map generated for the report content: http://garycmartin.com/som/ethiopiareport_080227a-mh.jpg Oh, I was asked for a legend (on another list): http://garycmartin.com/som/SOM_legend.jpg --Gary On 9 May 2008, at 19:34, Yamandu Ploskonka wrote: AFAIK this is the first published report in a format somewhat akin to what people want to see when they ask for documented proof on how OLPC is actually operating in the field. I contrast that to blogs and PR efforts around the day of distribution of XOs. http://www.eduvision.ch/en/meta/documents/ethiopiareport_080227a- mh.pdf The producer is a for-profit (?) consulting firm in Switzerland. Ed Cherlin has mentioned he has access to some other unpublished reports that might give a more complete picture Yama ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versions
On Mon, May 19, 2008 at 4:33 PM, Morgan Collett [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: * Cannot have two versions of an activity bundle installed at once (dev and stable) while debugging - esp. necessary for working on Develop itself. Also, you are forced to churn the activity.info version number (upwards or downwards, it doesn't matter) every debug cycle, because same version silently fails to install. This reminds me of my pet issue about activity version numbers: There is no way to branch development. This is especially relevant with activities decoupled from the builds. For instance: Chat-35.xo is included in the Update.1 activity repo (http://mock.laptop.org/repos/local.update1/XOS/index.html). Chat-38 will be the next development release, and will probably depend on new features in Sugar introduced since Update.1. What if we need a bugfix release for Update.1? What version will that be? If it is Chat-39, then Chat-38 and Chat-40 (perhaps another development release) would not be related to Chat-39 in any way. I think this is also an issue once Develop is available, since if I were to edit an activity in Develop and produce a bundle with the next version number as Jameson described, it would conflict with the next real release done by that activity's author. Since we struggle to get consensus on issues like a release name/number, can we get a discussion on the following bite sized pieces of an issue? * Is the current activity version numbering inadequate, as I am proposing? * Is changing it to (or allowing) a dotted numeric scheme (Chat-38.2) a good way to go? (For example, I might use odd numbers for development series and even numbers for stable releases - Chat-37.2 next, Chat-38 for Sucrose 0.82 / OLPC 8.02) and Chat-35.1 for a bugfix for Update.1) I'm ok with all this, even if I haven't devoted a good deal of thought to it. * Would that be an intrusive change? Not using dotted version numbers, but supporting several versions of the same bundle would be a bit invasive, although we certainly need to do it at some point. We would need for the PS to support it though. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] 8.1.1 bugfix release and sugar
Hi, I'm going to work on rpms for sugar based on the ones in 703 but whith the following changes: - Emit palette popup only after the window is mapped. This fixes ticket #3486. (Benjamin Berg) - Fix #3611 and parts of #4084 by setting the palette to be a transient window of the actiity. (Benjamin Berg) - In spread layout always get width/height request to not confuse hippo. Eventually we will have to deal with size changes in a better way. Fix flakes count in SnowflakeLayout. Fix #5904 (Marco Pesenti Gritti) Anything else? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 8.1.1 bugfix release and sugar
On Tue, May 20, 2008 at 2:53 PM, Dennis Gilmore [EMAIL PROTECTED] wrote: On Tuesday 20 May 2008, Tomeu Vizoso wrote: Ok, these three fixes have been pushed to the update-1 branch in git. Anything else? Dennis, in which koji branch should I build this rpm? OLPC-2 once its built i can tag it into olpc2-update1 and untag from dist-olpc2 And what about cvs? Should I get an old spec and commit it? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 8.1.1 bugfix release and sugar
On Tue, May 20, 2008 at 4:23 PM, Dennis Gilmore [EMAIL PROTECTED] wrote: On Tuesday 20 May 2008, Tomeu Vizoso wrote: On Tue, May 20, 2008 at 2:53 PM, Dennis Gilmore [EMAIL PROTECTED] wrote: On Tuesday 20 May 2008, Tomeu Vizoso wrote: Ok, these three fixes have been pushed to the update-1 branch in git. Anything else? Dennis, in which koji branch should I build this rpm? OLPC-2 once its built i can tag it into olpc2-update1 and untag from dist-olpc2 And what about cvs? Should I get an old spec and commit it? CVSROOT=cvs.fedoraproject.org/cvs/pkgs cvs co -r sugar-0_75_14-1_olpc2 sugar you will then need to copy sources sugar-0.65-jabberserver.patch and sugar.spec into your working checkout. making sure you keep a backup copy of the files so you can revert to them once your done. Built: http://koji.fedoraproject.org/koji/buildinfo?buildID=49864 Patches: http://dev.laptop.org/git?p=sugar;a=commit;h=56137d3493209e005e68a973d0da64f21f33754f http://dev.laptop.org/git?p=sugar;a=commit;h=edac3e893f8752b4fade256234cbaef3225aad5c http://dev.laptop.org/git?p=sugar;a=commit;h=60c8ee51d32724960bddff05236f1aeccb605fd2 Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar-datastore 0.8.1 released
Hi all, I have tarred and uploaded a new datastore release: http://dev.laptop.org/pub/sugar/sources/sugar-datastore/sugar-datastore-0.8.1.tar.bz2 But take in account that this is the same code that got shipped in Update.1 as 0.7.3. It's called 0.8.1 just because of some confusion during the last release. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Journal v88 is out
Hi, just uploaded a new release of the Journal: http://dev.laptop.org/pub/sugar/sources/journal-activity/journal-activity-88.tar.bz2 Changes: - Eben fixed the appearance of activity bundles. - Pootle brought us an update of the translation to Italian. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Sun, May 18, 2008 at 5:50 PM, Gary C Martin [EMAIL PROTECTED] wrote: Hi Eben/Tomeu, On 18 May 2008, at 15:37, Eben Eliason wrote: Attached,with launchbox.py included. - Eben I'm trying to apply you patch directly to an Xo with joyride 1946 (I don't have access to any other build environment so my tests are limited to patching an Xo B4). The patch seems to be mainly happy, except a few of failed hunks in model/homemodel.py and view/frame/activitiestray.py. Now I'm pretty sure you don't work on like this on an Xo, but any suggestions? I didn't notice any relevant changes between joyride 1946 and the most recent 1950, or have I misunderstood the source stream you guys work from? No, but there seems to have been some change not yet release on master that creates that conflict. Is the git source and a custom Fedora build server the only way to be involved? I'm hoping it's just that joyride has got a little behind the git source due to the current missing builds due to disk space. For small changes, just updating the affected files may work, but this patch is now a bit big for that. Also, not having been a release since a while ago doesn't help things. I've done some new rpms, but the joyride builds are not being built, looks like :/ You can get them from koji.fedoraproject.org and install them manually, though. After I finish testing the rpm with Eben's launcher stuff I'll post here the url. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Sun, May 18, 2008 at 6:10 PM, Eben Eliason [EMAIL PROTECTED] wrote: Sorry for the spam. This includes the necessary change to the makefile, and also fixes a few small bugs in the former versions. I'm still testing the rpm, but at a first glance, the pulsing is taking too much CPU. Looks like the whole full screen window is being redrawn and X takes 20% cpu. I remember something about a bug in hippo causing the whole canvas to be redrawn every time. Any news on this? As a quick workaround, the canvas could be just big enough to contain the icon, this should improve things considerably. I like it in general, though. Good work! Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Mon, May 19, 2008 at 11:43 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 11:33 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Sun, May 18, 2008 at 6:10 PM, Eben Eliason [EMAIL PROTECTED] wrote: Sorry for the spam. This includes the necessary change to the makefile, and also fixes a few small bugs in the former versions. I'm still testing the rpm, but at a first glance, the pulsing is taking too much CPU. Looks like the whole full screen window is being redrawn and X takes 20% cpu. What are we redrawing exactly? I thought the launching screen was mostly blank? Only a pulsing icon in the middle of the screen is drawn, but if time is in X, I guess it is just pushing white pixels around with some conversion in the middle. But this only happens in the faster builds that have composition enabled. Wonder what can be going on in there... On joyride, the shell just takes a few percents of cpu during launch, so perhaps it's good enough for now. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Mon, May 19, 2008 at 11:55 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On joyride, the shell just takes a few percents of cpu during launch, so perhaps it's good enough for now. Correction, takes 7%, enough to give it a look. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] activity.py: dirty flag and fix create_jobject == False case.
Hi,
+class WarningDictionary(dict):
+def __getitem__(self,key):
+warnings.warn(Trying to get key %s in unallocated activity
metadata dictionary %s%(key,self),
+RuntimeWarning, stacklevel=2)
+return None
+def __setetitem__(self,key,value):
+warnings.warn(Trying to set key %s in unallocated activity
metadata dictionary %s%(key,self),
+RuntimeWarning, stacklevel=2)
+return dict.__setitem__(self,key,value)
Why do you think this is needed?
+self.dirty = bool(handle or create_jobject) #do not save if not dirty.
Why bool() and why not just initialize it to True? What do you think
about using is_dirty instead so it's clearer that it's a flag?
+#Individual activities responsible for setting and clearing
+#this flag, but activity.py respects it.
Perhaps this should be a pydocs comment?
+logging.debug('Activity.save: %r' % self._jobject.object_id
if self._jobject else 'NOTHING')
...
+if self._jobject:
Wouldn't be better to make sure that this method doesn't get executed
if there's no jobject?
+logging.info('Activity.save: no need, nothing has
happened since last save.')
Should be logging.debug instead?
One concern I have about the general approach is that the activity
author needs to set dirty to False after a successful save, but that
info (when a save has finished successfully) is not available to the
activity.
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Code review (was: Pippy VS Develop)
On Mon, May 19, 2008 at 2:40 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: I also would like to understand if this is happening generally or just for the patches you are mentioning. I had not heard people complaining about slow reviews so far. No, I told Jameson that I'd review his patches because they affect code that has been maintained primarily by me. What happened is that I never found time to review those as higher priority items appeared in my TODO list, but Jameson has been patiently reminding me to do that. So more than a flaw in the process there has been shortage of resources or bad judgement of priorities by me. About slow reviews, I'd appreciate if someone reviewed the patches _I_ have in the review queue :P Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Implement installation dates in the activity list
From d9cf67dd382b492e93549344273658860e2410ae Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso [EMAIL PROTECTED]
Date: Mon, 19 May 2008 18:04:24 +0200
Subject: [PATCH] Add ActivityBundle.installation_time and format the date in the activity list
---
service/activityregistryservice.py |3 ++-
src/view/home/activitieslist.py|4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/service/activityregistryservice.py b/service/activityregistryservice.py
index 7746877..bf98ef9 100644
--- a/service/activityregistryservice.py
+++ b/service/activityregistryservice.py
@@ -132,7 +132,8 @@ class ActivityRegistry(dbus.service.Object):
'path': bundle.get_path(),
'command': bundle.get_command(),
'show_launcher': bundle.get_show_launcher(),
-'favorite': favorite}
+'favorite': favorite,
+'installation_time': bundle.get_installation_time()}
def _bundle_added_cb(self, bundle_registry, bundle):
self.ActivityAdded(self._bundle_to_dict(bundle))
diff --git a/src/view/home/activitieslist.py b/src/view/home/activitieslist.py
index ebdf1ec..48f16ee 100644
--- a/src/view/home/activitieslist.py
+++ b/src/view/home/activitieslist.py
@@ -20,6 +20,7 @@ import hippo
from sugar import profile
from sugar import activity
+from sugar import util
from sugar.graphics import style
from sugar.graphics.icon import CanvasIcon
@@ -134,7 +135,8 @@ class ActivityEntry(hippo.CanvasBox, hippo.CanvasItem):
expander = hippo.CanvasBox()
self.append(expander, hippo.PACK_EXPAND)
-date = hippo.CanvasText(text='3 weeks ago',
+timestamp = activity_info.installation_time
+date = hippo.CanvasText(text=util.timestamp_to_elapsed_string(timestamp),
xalign=hippo.ALIGNMENT_START,
font_desc=style.FONT_NORMAL.get_pango_desc(),
box_width=ActivityEntry._DATE_COL_WIDTH)
--
1.5.2.5
From 2c06e6be16492990601f51d25fbbedd4f0ab1a02 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso [EMAIL PROTECTED]
Date: Mon, 19 May 2008 18:03:04 +0200
Subject: [PATCH] Move timestamp_to_elapsed_string to sugar.util and add ActivityBundle.installation_time
---
src/sugar/activity/registry.py |8 +++--
src/sugar/bundle/activitybundle.py |5 +++
src/sugar/util.py | 69
3 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/src/sugar/activity/registry.py b/src/sugar/activity/registry.py
index 5f5aefc..d5d0529 100644
--- a/src/sugar/activity/registry.py
+++ b/src/sugar/activity/registry.py
@@ -31,11 +31,12 @@ def _activity_info_from_dict(info_dict):
return ActivityInfo(info_dict['name'], info_dict['icon'],
info_dict['bundle_id'], info_dict['version'],
info_dict['path'], info_dict['show_launcher'],
-info_dict['command'], info_dict['favorite'])
+info_dict['command'], info_dict['favorite'],
+info_dict['installation_time'])
class ActivityInfo(object):
-def __init__(self, name, icon, bundle_id, version,
- path, show_launcher, command, favorite):
+def __init__(self, name, icon, bundle_id, version, path, show_launcher,
+ command, favorite, installation_time):
self.name = name
self.icon = icon
self.bundle_id = bundle_id
@@ -44,6 +45,7 @@ class ActivityInfo(object):
self.command = command
self.show_launcher = show_launcher
self.favorite = favorite
+self.installation_time = installation_time
class ActivityRegistry(gobject.GObject):
__gsignals__ = {
diff --git a/src/sugar/bundle/activitybundle.py b/src/sugar/bundle/activitybundle.py
index 5f1fb7b..db30555 100644
--- a/src/sugar/bundle/activitybundle.py
+++ b/src/sugar/bundle/activitybundle.py
@@ -163,6 +163,11 @@ class ActivityBundle(Bundle):
Get the activity user visible name.
return self._name
+def get_installation_time(self):
+Get a timestamp representing the time at which this activity was
+installed.
+return os.stat(self._path).st_mtime
+
def get_bundle_id(self):
Get the activity bundle id
return self._bundle_id
diff --git a/src/sugar/util.py b/src/sugar/util.py
index 12f6824..f885523 100644
--- a/src/sugar/util.py
+++ b/src/sugar/util.py
@@ -21,6 +21,8 @@ import sha
import random
import binascii
import string
+from gettext import gettext as _
+import gettext
def printable_hash(in_hash):
Convert binary hash data into printable characters.
@@ -168,3 +170,70 @@ class LRU:
yield j
def keys(self):
return self.d.keys()
+
+units = [['%d year', '%d years', 356 * 24 * 60 * 60],
+ ['%d month', '%d months', 30 * 24 * 60 * 60],
+ ['%d week
Re: [sugar] OLPC priorities for Sugar in the August release
On Wed, May 14, 2008 at 1:46 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: * More responsive UI - faster launch of activities Is the solution currently in joyride satisfactory for the August release? I use a recent Joyride on my G1G1. My average time to launch Browse (from the time I click in the F3 Activity Ring on the Browse icon, to the time when I can click on the entry field in Browse itself (so that I can start typing in an URL) is 25 seconds. Is that satisfactory ? Certainly not. Could you do an experiment for me? Can you kill the journal activity and then try launching? If my suspicion is correct, the journal+DS is competing for the cpu, so without the journal it should start much faster. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar in LinuxTag 2008
On Sun, May 18, 2008 at 6:22 PM, Holger Levsen [EMAIL PROTECTED] wrote: On Tuesday 13 May 2008 11:57, Tomeu Vizoso wrote: Do you have a sugar workshop / meeting planned at a specific date as well? Or do you plan to just meet for the whole 4 days? ;) We'll also get 2m^2 space at the Debian Edu / Skolelinux.de booth. I think we just plan to hang around together and have a good face-to-face time interchanging experiences about this last year and the way forward. Perhaps we should set a couple of hours specifically for meeting with the broadest community? When would work better for the most time-constrained people? Perhaps would be most interesting after the talks, so new people can jump to say hi. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] pyc files in activity startup time (was Re: OLPC priorities for Sugar in the August release)
On Wed, May 14, 2008 at 4:37 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: One low-hanging fruit for faster activity start is having activity install compile .pyc files, with (tiny) extra points if the .pyc gets hints to not use jffs2 compression. Hi Chema, do you know how much this could improve startup of an activity like Chat? If you could find time to do some measurements, that would be great. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Thu, May 15, 2008 at 10:23 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 4:16 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 10:03 PM, Eben Eliason [EMAIL PROTECTED] wrote: how do we get the patch into the rpm without actually pushing the changes to git master? In any case, I know little about how any of these steps work. What does your suggestion imply I need to do myself to make this happen? Nope, but you will need someone to make an rpm for you in any case. OK, so can I be off the hook on this, and assume that you or someone else will apply the patch and make the rpm? It would be great to see it in a build before the weekend so we can make sure it operates well enough before the demos on Tuesday. Would you actually prefer to run it only on a few specific laptops? I was thinking that developers community feedback (through joyride) would be also valuable here. No, I agree that it would be better to have more people try it. Hi Eben, I think that the last patch doesn't include the launchbox.py file. Can you make a new one with this file? I intend to do the rpms today. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release management for upcoming bug fix releases and August release
Hi, On Tue, May 13, 2008 at 1:41 AM, Kim Quirk [EMAIL PROTECTED] wrote: A high level view of this process: 1) Prioritize feature and bug fix requests from deployments, developers, support, our sales/marketing group 2) Triage bugs to determine which bugs are critical to fix to meet the priorities 3) Translate these requests into requirements, use cases, and trac items (bug fixes or task items). Any news on this? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Providing more information on battery palette?
On Fri, May 16, 2008 at 4:48 AM, Eduardo H Silva [EMAIL PROTECTED] wrote: Mel Chua is developping a Power Activity, which will show various statistics like voltage, amperage, wattage that the charger is currently supplying to the laptop, to help those in the field developing and using alternative energy sources to charge their laptops. And I guess such an activity would have a considerable pedagogic value. Great idea! Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] scroll activity list with the arrow keys
On Thu, May 15, 2008 at 12:56 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Any reason to not use key_press events or similar? I don't think we should patch gtk.ScrolledWindow behavior. Well, I guess that Eben will want this behavior in all the list views (mesh, group, activity, more?). Tomeu On Thu, May 15, 2008 at 12:38 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi, the patch below adds the Up and Down arrow keys to the gtk.ScrolledWindow key bindings in the activity list as requested by Eben. But, if I understand correctly, this code alters the behavior of _all_ the gtk.ScrolledWindow instances in the shell. Two questions: - To Eben: Is this desired? - To anyone: Which place would be best for this code? Thanks, Tomeu diff --git a/src/view/home/activitieslist.py b/src/view/home/activitieslist.py index f638738..7264852 100644 --- a/src/view/home/activitieslist.py +++ b/src/view/home/activitieslist.py @@ -15,6 +15,7 @@ # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA import gobject +import gtk import hippo from sugar import profile @@ -31,7 +32,17 @@ class ActivitiesList(hippo.CanvasScrollbars): def __init__(self): hippo.CanvasScrollbars.__init__(self) self.set_policy(hippo.ORIENTATION_HORIZONTAL, hippo.SCROLLBAR_NEVER) - + +gtk.binding_entry_add_signal(gtk.ScrolledWindow, gtk.keysyms.Up, 0, + 'scroll-child', + gtk.ScrollType, gtk.SCROLL_STEP_BACKWARD, + bool, False) + +gtk.binding_entry_add_signal(gtk.ScrolledWindow, gtk.keysyms.Down, 0, + 'scroll-child', + gtk.ScrollType, gtk.SCROLL_STEP_FORWARD, + bool, False) + self._box = hippo.CanvasBox( \ background_color=style.COLOR_WHITE.get_int()) self.set_root(self._box) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Its.an.education.project] Freedom is a good deal (Was: Ivan's latest blog entry on OLPC)
Hi, Bernie's post resonates so well with my experience, that I need to comment on it. On Thu, May 15, 2008 at 2:23 PM, Bernie Innocenti [EMAIL PROTECTED] wrote: Martin Langhoff wrote: No quite :-) but, I've been through the early linux-linux power user-pissed off by linux, got a powerbook-pissed off by OSX, back to linux cycle. Ah, me too! My OSX period lasted almost 2 years, and yours? ~1 year, bought a PPC Mac Mini for coding in ObjC + Cocoa as I was a big fan of OpenSTEP, but ended dedicating more time to python and pyCocoa when I knew that OLPC had decided to go with pygtk. The just works of OSX on Apple hardware was nice, but I chose to trade a bit of convenience (not much, IMO) for helping the efforts to bring software production capacity to the masses. I also had a 4-5 years Windows development period. A prerequisite for me to become profoundly disgusted by the whole proprietary software ecosystem. Same here, with Borland Delphi. We contracted very expensive professional support from some serious companies and frankly, its quality lacked tons behind what you get today from the FOSS communities. It seems to me that new users who have grown in this golden era cannot truly appreciate the amount of freedom they enjoy these days, after 10 years of steady growth of FOSS have increasingly forced proprietary vendors away from their worst practices. Yup. Who remembers daisy chaining 3 hardware dongles to my parallel port just to use the software they needed at work? And juggling a dozen different CDs just to install everything they required to use a new computer? Each time a machine would reboot, you'd get plenty of annoying splash screens of which you couldn't get rid. Not to mention searching for cracks on astalavista so you could use a text editor and a zip archiver :-) Believe it or not, this is how computers really looked like in the '90s, when Microsoft was still dominating the (computing) world. Matches my own experience. Now OSX is 80% open source, and Microsoft is forced to give away server applications unencumbered with per-seat licenses. Would this have happened also without GNU, Linux, Apache, Samba...? I doubt it. My opinion as well. Most users, especially the non technical ones, feel more comfortable using a convenient mixture of free and proprietary software that solves their immediate computing needs. Fine, but they should be aware how much they are actually benefiting from the efforts of thousands who stand still and work on providing alternative solutions. Yes, some effort needs to be done in order to see the situation in perspective. I guess journalists (or rather publications) are too busy announcing products to analyze what happened during the last two decades. If Rob Savoye and his friends were content with using Adobe's Flash, now we'd not have Gnash which works pretty decently, is portable to different CPUs, and can start the movies paused by default (a nice anti-ad feature). Check it out and help the Gnash hackers by reporting bugs or sending your patches. Freedom is not a theoretical issue. It has very important practical consequences too, but these are sometimes harder to see, even when they are right in front of your nose. Yes, freedom may not be for free... but it's usually a good investment. In my own words, FOSS in this education project has two main benefits: - Short term benefit: communities ranging in size from international organizations to regional administrations can be in charge of the software, without having to depend on foreign corporations that have very different goals and that _will_ abuse their disproportionate power. What OLPC has invested in Sugar to date is in reach of any government and of most regional organizations in the world. This is like that because Sugar is built on top of the work of thousands of individuals and companies that chose to contribute their work to the whole community. - Long term benefit: the recipients of the machines can understand how software and content can be created and distributed _by themselves_. People can use knowledge to their own benefit without having to depend on channels controlled by others. At the end, it's a matter of giving power to the people, I guess that's what makes me a fundamentalist and a terrorist. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Implement search in the activity list.
Hi,
this is very similar to the mesh view search.
Thanks,
Tomeu
From fdad7268e4c39e277d75fa82c1eda1972467f9b8 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso [EMAIL PROTECTED]
Date: Thu, 15 May 2008 18:21:58 +0200
Subject: [PATCH] Implement search in the activity list.
---
src/view/home/HomeBox.py| 43 +++---
src/view/home/activitieslist.py | 19 +++-
2 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/src/view/home/HomeBox.py b/src/view/home/HomeBox.py
index 181849f..c9effa6 100644
--- a/src/view/home/HomeBox.py
+++ b/src/view/home/HomeBox.py
@@ -15,9 +15,10 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
from gettext import gettext as _
+import logging
-import gtk
import gobject
+import gtk
import hippo
from sugar.graphics import style
@@ -30,6 +31,8 @@ from view.home.activitieslist import ActivitiesList
_RING_VIEW = 0
_LIST_VIEW = 1
+_AUTOSEARCH_TIMEOUT = 1000
+
class HomeBox(hippo.CanvasBox, hippo.CanvasItem):
__gtype_name__ = 'SugarHomeBox'
@@ -41,12 +44,18 @@ class HomeBox(hippo.CanvasBox, hippo.CanvasItem):
self._enable_xo_palette = False
self._toolbar = HomeToolbar()
-#self._toolbar.connect('query-changed', self.__toolbar_query_changed_cb)
+self._toolbar.connect('query-changed', self.__toolbar_query_changed_cb)
self._toolbar.connect('view-changed', self.__toolbar_view_changed_cb)
self.append(hippo.CanvasWidget(widget=self._toolbar))
self._set_view(_RING_VIEW)
+def __toolbar_query_changed_cb(self, toolbar, query):
+if self._list_view is None:
+return
+query = query.lower()
+self._list_view.set_filter(query)
+
def __toolbar_view_changed_cb(self, toolbar, view):
self._set_view(view)
@@ -120,6 +129,9 @@ class HomeToolbar(gtk.Toolbar):
def __init__(self):
gtk.Toolbar.__init__(self)
+self._query = None
+self._autosearch_timer = None
+
self._add_separator()
tool_item = gtk.ToolItem()
@@ -131,8 +143,8 @@ class HomeToolbar(gtk.Toolbar):
'system-search')
self._search_entry.add_clear_button()
self._search_entry.set_width_chars(25)
-#self._search_entry.connect('activate', self._entry_activated_cb)
-#self._search_entry.connect('changed', self._entry_changed_cb)
+self._search_entry.connect('activate', self.__entry_activated_cb)
+self._search_entry.connect('changed', self.__entry_changed_cb)
tool_item.add(self._search_entry)
self._search_entry.show()
@@ -172,3 +184,26 @@ class HomeToolbar(gtk.Toolbar):
self.insert(separator, -1)
separator.show()
+def __entry_activated_cb(self, entry):
+if self._autosearch_timer:
+gobject.source_remove(self._autosearch_timer)
+new_query = entry.props.text
+if self._query != new_query:
+self._query = new_query
+self.emit('query-changed', self._query)
+
+def __entry_changed_cb(self, entry):
+if not entry.props.text:
+entry.activate()
+return
+
+if self._autosearch_timer:
+gobject.source_remove(self._autosearch_timer)
+self._autosearch_timer = gobject.timeout_add(_AUTOSEARCH_TIMEOUT,
+ self.__autosearch_timer_cb)
+
+def __autosearch_timer_cb(self):
+self._autosearch_timer = None
+self._search_entry.activate()
+return False
+
diff --git a/src/view/home/activitieslist.py b/src/view/home/activitieslist.py
index f638738..c04b967 100644
--- a/src/view/home/activitieslist.py
+++ b/src/view/home/activitieslist.py
@@ -31,7 +31,8 @@ class ActivitiesList(hippo.CanvasScrollbars):
def __init__(self):
hippo.CanvasScrollbars.__init__(self)
self.set_policy(hippo.ORIENTATION_HORIZONTAL, hippo.SCROLLBAR_NEVER)
-
+
+self._query = ''
self._box = hippo.CanvasBox( \
background_color=style.COLOR_WHITE.get_int())
self.set_root(self._box)
@@ -57,7 +58,14 @@ class ActivitiesList(hippo.CanvasScrollbars):
return
def _add_activity(self, activity_info):
-self._box.append(ActivityEntry(activity_info))
+entry = ActivityEntry(activity_info)
+self._box.append(entry)
+entry.set_visible(entry.matches(self._query))
+
+def set_filter(self, query):
+self._query = query
+for entry in self._box.get_children():
+entry.set_visible(entry.matches(query))
class ActivityEntry(hippo.CanvasBox, hippo.CanvasItem):
__gtype_name__ = 'SugarActivityEntry'
@@ -81,6 +89,7 @@ class ActivityEntry(hippo.CanvasBox, hippo.CanvasItem):
self._bundle_id = activity_info.bundle_id
self._version = activity_info.version
Re: [sugar] [PATCH] Merge activities.default into favorites.
Can somebody review this patch? I'd like to implement the date field in the activity list, but that will conflict heavily with this patch. Thanks, Tomeu 2008/5/13 Tomeu Vizoso [EMAIL PROTECTED]: [re-adding sugar to cc] 2008/5/12 Eben Eliason [EMAIL PROTECTED]: I glanced at this, and I *think* that it does what I want it to, but I wanted to clarify. (The comment # Activities to be automatically added to the ring after an upgrade worried me). What I expect this to do is merge a list of specified default activities D with a list of favorite activities F, such that the ring contains F ∪ D, where F is the up to date list of user chosen favorites and D is a list of defaults as specified /by the latest upgrade/. So I guess a clear point I'm questioning is if the activities.defaults is a) specified by the countries at time of customization and b) read from an activity pack upon future updates, such that it is not actually a hard coded list (except, perhaps, as a default when no other list has been provided via the above methods). Yes, the activities.defaults file is read and merged in the way you describe every time it changes. This will happen in the scenarios you mentioned. It also appears that that the implementation performs the merge of F and D once each time a new defaults file appears (via an activity pack update), which is desired behavior, but I just wanted to confirm that. Right. PS. Can someone give me a clearer idea of the activity pack and how they actually work? My personal interpretation of the idea is that it consists a bundle of activity bundles, and a file which specifies the new activities.defaults. I furthermore assume that the activities.defaults file included should *only* reference activities included in the activity pack. Could I get confirmation on this? Yes, this is my understanding as well, although I have no first-hand info on that. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] scroll activity list with the arrow keys
Hi,
this new patch uses key-press-event.
Thanks,
Tomeu
On Thu, May 15, 2008 at 5:08 PM, Eben Eliason [EMAIL PROTECTED] wrote:
On Thu, May 15, 2008 at 7:04 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
On Thu, May 15, 2008 at 12:56 PM, Marco Pesenti Gritti
[EMAIL PROTECTED] wrote:
Any reason to not use key_press events or similar? I don't think we
should patch gtk.ScrolledWindow behavior.
Well, I guess that Eben will want this behavior in all the list views
(mesh, group, activity, more?).
Confirmation on that. All list views should behave the same.
- Eben
From e3ff1c398a20d019b6da49fdd61b0d8d1ed1 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso [EMAIL PROTECTED]
Date: Thu, 15 May 2008 18:55:50 +0200
Subject: [PATCH] Make arrows scroll up and down in scroll views.
---
src/view/home/activitieslist.py | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/src/view/home/activitieslist.py b/src/view/home/activitieslist.py
index f638738..ebdf1ec 100644
--- a/src/view/home/activitieslist.py
+++ b/src/view/home/activitieslist.py
@@ -15,6 +15,7 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
import gobject
+import gtk
import hippo
from sugar import profile
@@ -31,7 +32,8 @@ class ActivitiesList(hippo.CanvasScrollbars):
def __init__(self):
hippo.CanvasScrollbars.__init__(self)
self.set_policy(hippo.ORIENTATION_HORIZONTAL, hippo.SCROLLBAR_NEVER)
-
+self.props.widget.connect('key-press-event', self.__key_press_event_cb)
+
self._box = hippo.CanvasBox( \
background_color=style.COLOR_WHITE.get_int())
self.set_root(self._box)
@@ -59,6 +61,24 @@ class ActivitiesList(hippo.CanvasScrollbars):
def _add_activity(self, activity_info):
self._box.append(ActivityEntry(activity_info))
+def __key_press_event_cb(self, widget, event):
+keyname = gtk.gdk.keyval_name(event.keyval)
+
+vadjustment = self.props.widget.props.vadjustment
+if keyname == 'Up':
+if vadjustment.props.value vadjustment.props.lower:
+vadjustment.props.value -= vadjustment.props.step_increment
+elif keyname == 'Down':
+max_value = vadjustment.props.upper - vadjustment.props.page_size
+if vadjustment.props.value max_value:
+vadjustment.props.value = min(
+vadjustment.props.value + vadjustment.props.step_increment,
+max_value)
+else:
+return False
+
+return True
+
class ActivityEntry(hippo.CanvasBox, hippo.CanvasItem):
__gtype_name__ = 'SugarActivityEntry'
--
1.5.2.5
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 7:17 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 6:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: I agree that limiting the number of components released as a whole brings important benefits. Can we explicitly enumerate the benefits? Coordinating a release requires effort from the release team and from each of the component maintainers. If we reach a sufficiently high number of components to coordinate, we'll need to increase the sophistication of our process, making it potentially more cumbersome. On one extreme, we have an open source project in which every release has one or two rpms, debs, etc. On the other a linux distribution with thousands of packages. In the middle, GNOME or KDE. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 7:33 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Tomeu Vizoso wrote: | I agree that limiting the number of components released as a whole | brings important benefits. I think that the idea of releasing some | activities as part of Sugar is because they provide services that | are considered a basic part of the user experience inside Sugar. Could you name an example of such an Activity? It seems to me that the presence of any such Activity represents a design bug in Sugar. In the case of Chat and Journal, these are known design bugs. Chat will eventually be rendered mostly obsolete by pervasive overlay chat, and the Journal is planned to be merged into the Sugar interface itself. The question of whether activities are included by default refers either to prefabricated disk images or packages for distros like Fedora and Ubuntu. Regarding disk images, the answer is clear: do both. We should have minimal disk images, with just the Sugar base, and also demo images with all the activities we think someone might want. Obviously, it depends on what meaning Sugar release has to you. I agree in that the Sugar shell + API shouldn't depend on any activity, but some definition of Sugar may include some activities. If we consider that browsing the web is an important use case to be considered inside the Sugar experience, then it may make sense to consider releasing Sugar along with a Browse activity. Same for Read or Write. Of course that the line needs to be drawn somewhere, that's what I was asking. Determining what to do in the case of packages for other distros, the situation is much muddier. The plan for Activity packaging is designed around the idea of thousands of unknown authors writing code that installs and runs with minimal privileges. Users will be able to install multiple distinct activities with the same name, distinguished by cryptographic authorship and history, upgrade or downgrade them, and modify their source code, all without superuser access. It's already difficult to harmonize this with yum/rpm and apt/deb, and it's only going to get harder with the new Activity bundle system. I think our best option is to let Sugar retain control of Activity installation, even when running on a system with its own package management. Not sure about it, I see arguments on both sides. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] OLPC priorities for Sugar in the August release
Hi all, have some doubts about http://wiki.laptop.org/go/Priorities-2008 * More responsive UI - faster launch of activities Is the solution currently in joyride satisfactory for the August release? * More notifications? How can we know which areas in the UI are in most need of more feedback? * New Sugar UI? Should continue with some specific goals on how to roll out the new features so it won't be difficult for people. Wad brought up the issue that Peru has already started printing a manual based on the old UI. How can I help regarding this? * May help push the bug patch release in order to get some of these other features out without requiring a new UI. Can you please expand on this? Which new features can be offered without the new UI? * Datastore upgrade Which are the requirements for the DataStore in the August release? * Groups, models for groups (Peru, Hernan) Is this groups in Sugar? Do we have some kind of requirements? * Sugar on other distro (mgmt) On which other distro? Which are the requirements? What means (mgmt)? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
Hi, sorry for the delay.
On Tue, May 13, 2008 at 12:43 AM, Martin Dengler
[EMAIL PROTECTED] wrote:
+def get_mute(self):
You use 'muted' instead of 'mute' below, which one is more correct?
+if not self._mixer or not self._master:
+logging.error('Cannot get the mute status')
+return False
Shouldn't we return True if there's no way to get the volume?
diff --git a/src/model/devices/Makefile.am b/src/model/devices/Makefile.am
index 5440eeb..3124144 100644
--- a/src/model/devices/Makefile.am
+++ b/src/model/devices/Makefile.am
@@ -5,4 +5,6 @@ sugar_PYTHON = \
__init__.py \
device.py \
devicesmodel.py \
- battery.py
+ battery.py \
+ speaker.py
Just as a comment, the convention is to sort files alphabetically (it
was already wrong).
@@ -54,6 +55,13 @@ class DevicesModel(gobject.GObject):
for udi in hal_manager.FindDeviceByCapability('battery'):
self.add_device(battery.Device(udi))
+try:
+self.add_device(speaker.Device())
+except Exception, speaker_fail_msg:
+logging.error(could not initialize speaker device: %s %
+ speaker_fail_msg)
+logging.debug(traceback.format_exc())
I would add the speaker device in the constructor, instead of in
_observe_hal_manager().
Perhaps we should add try..except blocks to all the add_device calls?
Not in this patch, though.
+def get_type(self):
+return 'speaker'
Maybe should be a constant at the module level?
+def do_get_property(self, pspec):
+if pspec.name == level:
+return self._get_level()
+elif pspec.name == muted:
+return self._get_muted()
See above comment about muted vs mute.
+self._adjustment = gtk.Adjustment(
+self._model.props.level, 0.0, 101.0, 1, 1, 1)
Not the most common of breaking an arg list, but I don't particularly care.
Thanks!
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Wed, May 14, 2008 at 10:56 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 13.05.2008, at 19:33, Benjamin M. Schwartz wrote: Tomeu Vizoso wrote: | I agree that limiting the number of components released as a whole | brings important benefits. I think that the idea of releasing some | activities as part of Sugar is because they provide services that | are considered a basic part of the user experience inside Sugar. Could you name an example of such an Activity? It seems to me that the presence of any such Activity represents a design bug in Sugar. In the case of Chat and Journal, these are known design bugs. Chat will eventually be rendered mostly obsolete by pervasive overlay chat, and the Journal is planned to be merged into the Sugar interface itself. I pretty much agree with that. With the exception of activities that Ben listed there is no reason to include more in Sugar itself. For example the browse activity - this endorses one specific browser implementation, it pulls in one huge chunk of code, etc. It is likely that if hooks are added for opening URLs that they are specific to that one browse implementation. If there were several browsers, developers were forced to agree on some API. Competition is good, so we should not pick one flavor over another. IMHO it is better to clearly separate the core from the activities. This also forces clean interfaces, you cannot as easily chicken-out when breaking the API (and silently fixing the included activities). We want to encourage third-party activity development, keeping the core as small as possible seems beneficial to me. I agree on this, the Sugar core shouldn't depend on any activity and should also (aim to) give equal chances to all activity authors. That said, does this mean that the full-time Sugar team should stop maintaining any activities and focus on the core? I would love to do so, but I'm afraid that Sugar won't reach its goals if we don't make sure that some very basic activities keep growing. As an example, yesterday I assumed Read maintenance because Reinier is busy with school these days. I did this because we know that Read fulfills very important use cases and cannot be left until someone else appears and takes its maintenance. And I plan to follow the Sugar release process with it because I want that when the next stable release of Sugar comes along, Read has been tested with the rest of Sugar and perhaps a new version will be released that implements generic Sugar goals like could be reduced memory usage and keyboard bindings. Does it make sense? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity proposal: Read
* Short description of the features: No new features currently scheduled for Update.2. * Screenshots or screencasts: Mockup: http://wiki.laptop.org/go/Image:Activity_read.jpg * Are you willing to follow the Schedule? Yup. * System components the activity depends on: sugar, evince-olpc, evince-python * Members of the developer team: Tomeu Reinier? Marco * Status of internationalization: In pootle * Code repository: git://dev.laptop.org/read-activity * Bug tracking system: read-activity in dev.laptop.org Trac Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Mon, May 12, 2008 at 7:03 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 7:01 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 5:37 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: As any new module/activity will add some overhead to the release team, perhaps we should ask that any module included in the release process has to provide functionality that the community believes is important to the project goals? So maybe we should ask such a new point: * Provide functionality that the community judges as important for reaching the goals of the project. Yeah, I think we will need to define some relevance criteria. I wanted to let those emerge from the concrete activities discussions rather than defining them upfront... but your generic definition sounds pretty good, please add it to the wiki so that we keep this in mind. Btw I think a good way to start defining some of those criteria concretely might be a discussion on its.an.education.project list. Also Walter wrote some criteria to determine the core activities which we could reuse in this context. Will initiate such a thread. One thing I don't have completely clear is the meaning of an activity being part of the Sugar release. Which implications has? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Tue, May 13, 2008 at 6:24 PM, Walter Bender [EMAIL PROTECTED] wrote: I think we need to decouple the release cycles between activities and Sugar to whatever degree possible. Activities should be able to change at whatever pace is dictated by the activity developers. Since activities depend upon Sugar, the Sugar schedule needs to be more predictable. The only time it seems there would be a conflict is when an incompatible change in a Sugar module is made, which, with the emerging process, is hopefully rare and well known in advance. Note that the above says nothing about what constitutes a core activity. But we do want to make sure we are not leaving activity developers in the dust as we make changes. Sugar without activities is not very interesting. I agree that limiting the number of components released as a whole brings important benefits. I think that the idea of releasing some activities as part of Sugar is because they provide services that are considered a basic part of the user experience inside Sugar. I think this is the reason why GNOME releases applications along with desktop components? Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] hot corners
On Mon, May 12, 2008 at 9:48 AM, Simon Schampijer [EMAIL PROTECTED] wrote: Wade Brainerd wrote: If we are adding a delay, would it be acceptable to enable the frame activation along the edges of the screen in addition to the corners? This was why the corners where chosen: http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/The_Frame#Hot_Corners With the new frame design where activities are placed in the upper frame I trapped myself trying to invoke the frame where I know the activities are placed in the frame to switch between activities. For me that seem to be convenient to add activation at least to the upper frame. Same here. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Sat, May 10, 2008 at 5:03 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello, I wrote some notes about the process for the next Sugar release. http://wiki.sugarlabs.org/go/Release http://wiki.sugarlabs.org/go/Roadmap [...] Looks pretty good to me. What's the next step? Should we move now to propose features for the next releases? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
On Sat, May 10, 2008 at 5:03 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: == New features proposal == At the beginning of each release cycle, maintainers will write a proposal for each major new feature they plan to develop. These will be discussed on the Sugar mailing list, revised on the base of the feedback and made available on the wiki. New modules will require explicit approval by the release team. As part of this process new activities will be proposed for inclusion. Criteria for approval will be: * The maintainer is willing to follow the Sugar schedule. * Supports internationalisation and localisation. * Does not duplicate the functionalities of other activities. * ... Not required but preferred: * Use the sugarlabs infrastructure. As any new module/activity will add some overhead to the release team, perhaps we should ask that any module included in the release process has to provide functionality that the community believes is important to the project goals? So maybe we should ask such a new point: * Provide functionality that the community judges as important for reaching the goals of the project. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Merge activities.default into favorites.
From 7f9eb78b2585504669d3ebe648e8ee3b356a5d6e Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso [EMAIL PROTECTED]
Date: Mon, 12 May 2008 20:42:24 +0200
Subject: [PATCH] Merge activities.default into favorites.
---
data/Makefile.am |1 +
data/activities.defaults | 19 +++
service/bundleregistry.py | 128 +++--
3 files changed, 108 insertions(+), 40 deletions(-)
create mode 100644 data/activities.defaults
diff --git a/data/Makefile.am b/data/Makefile.am
index 7771ce9..698721d 100644
--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -8,6 +8,7 @@ sugar-xo.gtkrc: gtkrc.em
sugardir = $(pkgdatadir)/data
sugar_DATA = \
+ activities.defaults \
kbdconfig \
mime.defaults \
$(GTKRC_FILES)
diff --git a/data/activities.defaults b/data/activities.defaults
new file mode 100644
index 000..fe229a1
--- /dev/null
+++ b/data/activities.defaults
@@ -0,0 +1,19 @@
+# Activities to be automatically added to the ring after an upgrade
+
+org.laptop.Chat
+org.laptop.WebActivity
+org.laptop.AbiWordActivity
+org.laptop.RecordActivity
+org.laptop.Oficina
+org.laptop.TamTamMini
+org.vpri.EtoysActivity
+org.laptop.TurtleArtActivity
+org.laptop.Pippy
+org.laptop.Calculate
+org.laptop.Terminal
+org.laptop.MeasureActivity
+org.laptop.AcousticMeasure
+org.laptop.Memorize
+org.laptop.TamTamJam
+org.laptop.TamTamEdit
+org.laptop.TamTamSynthLab
diff --git a/service/bundleregistry.py b/service/bundleregistry.py
index 88060c3..133ffbf 100644
--- a/service/bundleregistry.py
+++ b/service/bundleregistry.py
@@ -26,20 +26,6 @@ from sugar import env
import config
-def _load_mime_defaults():
-defaults = {}
-
-f = open(os.path.join(config.data_path, 'mime.defaults'), 'r')
-for line in f.readlines():
-line = line.strip()
-if line and not line.startswith('#'):
-mime = line[:line.find(' ')]
-handler = line[line.rfind(' ') + 1:]
-defaults[mime] = handler
-f.close()
-
-return defaults
-
class BundleRegistry(gobject.GObject):
Service that tracks the available activity bundles
@@ -54,22 +40,89 @@ class BundleRegistry(gobject.GObject):
def __init__(self):
gobject.GObject.__init__(self)
-
+
+self._mime_defaults = self._load_mime_defaults()
+
self._bundles = []
-self._search_path = []
-self._mime_defaults = _load_mime_defaults()
+for activity_dir in self._get_activity_directories():
+self._scan_directory(activity_dir)
-path = env.get_profile_path('favorite_activities')
-if os.path.exists(path):
+self._last_defaults_mtime = -1
+self._favorite_bundles = self._load_favorites()
+self._merge_default_favorites()
+
+def _get_activity_directories(self):
+directories = []
+if os.environ.has_key('SUGAR_ACTIVITIES'):
+directories.extend(os.environ['SUGAR_ACTIVITIES'].split(':'))
+
+directories.append(env.get_user_activities_path())
+
+return directories
+
+def _load_mime_defaults(self):
+defaults = {}
+
+f = open(os.path.join(config.data_path, 'mime.defaults'), 'r')
+for line in f.readlines():
+line = line.strip()
+if line and not line.startswith('#'):
+mime = line[:line.find(' ')]
+handler = line[line.rfind(' ') + 1:]
+defaults[mime] = handler
+f.close()
+
+return defaults
+
+def _load_favorites(self):
+favorite_bundles = []
+favorites_path = env.get_profile_path('favorite_activities')
+if os.path.exists(favorites_path):
try:
-self._favorite_bundles = simplejson.load(open(path))
-print 'loaded %r' % self._favorite_bundles
+favorites_data = simplejson.load(open(favorites_path))
+# Old structure was a list instead of a dictionary.
+if isinstance(favorites_data, list):
+favorite_bundles = favorites_data
+else:
+favorite_bundles = favorites_data['favorites']
+self._last_defaults_mtime = favorites_data['defaults-mtime']
except ValueError, e:
-logging.error('Error while loading favorite_activities: %r.'
- % e)
-self._favorite_bundles = []
-else:
-self._favorite_bundles = []
+logging.error('Error while loading favorite_activities: %r.' %
+ e)
+
+return favorite_bundles
+
+def _merge_default_favorites(self):
+default_activities = []
+defaults_path = os.path.join(config.data_path, 'activities.defaults')
+if os.path.exists(defaults_path):
+file_mtime = os.stat(defaults_path).st_mtime
+if file_mtime self._last_defaults_mtime:
+f = open
Re: [sugar] Sugar Interface on Classmate PC
On Thu, May 8, 2008 at 11:18 AM, Chuka Uzoegwu [EMAIL PROTECTED] wrote: Hi, My major concern about the platform I am working on is the disk space which is 2GB for the Classmate PC. I don't know if there is a scaled down version of the Fedora or Ubuntu kernel. Thanks for the help. Yes, as far as I know, both Fedora and Ubuntu can be installed in less than 2GB, but you may need to do a less than standard installation. Distro-focused forums may help you better on this. Good luck, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Its.an.education.project] Sugar on the EEE PC
On 5/6/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yes I made it work on a EEE PC using a dual boot configuration. Sugar runs, but activities suffer because of the limited screen resolution. Which resolution it has? I can give it a look next week when I get back to a working jhbuild install. Eben, is there a plan with overflowing toolbars? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New Design - problem with Circle of Activities
On 5/7/08, Mikus Grinbergs [EMAIL PROTECTED] wrote: The 'ring' view in Activity Management needs fixing -- when MULTIPLE Activity instances with the same name exist in the system, each instance should be treated (and shown) independently. Yes, this is known and will be fixed hopefully soon. We don't intend to ship so flagrant bugs, we just haven't had time to fix those. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] make width/text of battery palette look nicer
r+
Thanks!
Tomeu
On 5/2/08, Martin Dengler [EMAIL PROTECTED] wrote:
---
src/view/devices/battery.py |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/view/devices/battery.py b/src/view/devices/battery.py
index a97d014..e4d82d3 100644
--- a/src/view/devices/battery.py
+++ b/src/view/devices/battery.py
@@ -84,6 +84,8 @@ class BatteryPalette(Palette):
self._level = 0
self._progress_bar = gtk.ProgressBar()
+self._progress_bar.set_size_request(
+style.zoom(style.GRID_CELL_SIZE * 4), -1)
self._progress_bar.show()
self._status_label = gtk.Label()
self._status_label.show()
@@ -120,7 +122,6 @@ class BatteryPalette(Palette):
'min': remaining_minpart})
else:
secondary_text = _('Charged')
-status_text = ''
self.props.secondary_text = secondary_text
self._status_label.set_text(status_text)
--
1.5.4.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] On improving Sugar performance
On Mon, Apr 28, 2008 at 7:21 PM, Gary C Martin [EMAIL PROTECTED] wrote: Sure, but rather than a useful tool, I would call measuring as the only possible base on which decide actual work that needs to be done. We could be refactoring and recoding for years and don't get any noticeable improvement, if we don't measure. Not that I want to start a CS grad war here, but with more than one foot in the UI camp, I just wanted to request that more than just 'clock watching' is done when selecting/implementing optomisations – though 'clock watching' is a very good place to start. http://www.codinghorror.com/blog/archives/001058.html Catering for subjective human response is tricky, but once you've passed some minimum threshold for utility** you can often win more hearts and minds going for the subjective. A concrete example I'd point to is smooth animation; activity switching with no nasty redraw flicker; pulsing icons with no visible strobe; and frame/notification transitions that glide smoothly onto the display giving the illusion of effortlessness. I agree with this. We need to choose which code paths need to be optimized based on (subjective) user reports. But once we know there's a point where we are not giving enough feedback or where things just should be done faster, we should measure in order to set goals and choose the best approach. I don't think we have enough resources to rewrite things and find out later that we haven't improved user experience at all. **how many hours must I have spent as a kid, excitedly waiting for some software to load up off a magnetic tape, only to have it fail a fair portion of the time and have to start the tape over again... and some folks here moan about a ~6sec launch time for an activity. Though it's true to argue that those old machines did have instant on, even if you were left to ponder a BASIC prompt and spend the next 5min trying to tune your TV in to get a clear signal :-) ;) Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
The idea is that we have a complex system, and that value can be seen in having this system degrading gracefully when an unexpected error happens. Even more when is an area where kids are supposed to play with (adding device icons to the shell). Adding just one try..except block before gtk.main won't give us this graceful degradation. Tomeu On Tue, Apr 29, 2008 at 2:24 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: I'm not really sure about the value of this kind of try/except blocks. If the target is to avoid the shell exiting in any case, we could as well try/except the whole code executed before gtk.main(). Marco On Tue, Apr 29, 2008 at 2:12 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Apr 29, 2008 at 1:37 AM, Martin Dengler [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 06:12:31PM -0400, Michael Stone wrote: On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote: On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote: Can calls to self._mixer or self._master fail even when these attributes are not None? It doesn't appear a concern from the existing hardwaremanager.py code, and not in practice: I've tested checking/changing the volume in a few activities. I seem to recall having encountered situations where sugar startup would fail (in early versions of the QEMU image, before sound began working) as a result of unchecked use of sound hardware. I fixed the problem by commenting out volume control in the sugar shell. It was a particularly annoying problem because it was persistent, which meant that X entered an infinite reboot loop. Yes, that problem exists and my patch is no worse in this respect - I meant to make both points very explicit later in the email to which you replied. Given the clear implication that we should do better, I'll change my patch. If you, or marco, or anyone has an opinion about where the best place to introduce the real paranoia, please let me know. OTTOMH, given we obviously want to make Sugar not crash and (secondarily) minimize spamming of 'try:...except's, hardwaremanager.py's where I would introduce the bulk of the changes (rather than make speaker.py, randomactivity.py, presence-palette-that-wants-to-make-a-dinging-noise.py, etc. do this). If anyone thinks that's controversial let me know. The original author of the hardwaremanager.py trusted the gst classes just as much as I am... also keep in mind that I actually saw and worked around two failures (#6933, #6934) of exactly these attributes/implementations, In your opinion, did the original author of hardwaremanager.py (or authors of the clients of hardwaremanager.py?) exercise the degree of caution necessary to deliver a solid, reliable Sugar experience to our present audience? (I say present audience because I think that our audience has changed from one which consisted primarily of developers to one which consists primarily of semi-literate children.) As a rhetorical question I think I understand the point. As a non-rhetorical question, I'll decline to answer due to lack of context/familiarity with the conditions. Also, what happens if an exception is thrown by, say, Device.__init__()? Given the current state of error checking, sugar (the shell) will fail to start and matchbox will exit (I saw this during testing, and just now tried 'raise Exception(we love m_stone)' to confirm.) Is the exception properly recorded? I'm sorry, I will have to research the proper way to record such an exception. I don't know. Is it possible (easy?) to send the traceback upstream to us? Very interesting idea. Is there a plan for aggregating such data? cscott's FISL presenation had some (http-sourced?) usage graphs...is there a Send Microsoft a Report- (or We Share Your Pain :)) like server to which our code could send such reports? Do you want automated/staged trac submissions? The design/architecture/maintenance solution space is well beyond my time to explore. Lacking any leads therein I'm going to answer to your question as I know not this 'upstream', would be happy to use one, but have no resources to build one. Device.__init__() is four lines of code, and depends on util.unique_id() and gobject.GObject.__init__(). Device.__init__() sounds like the sort of thing that I expect will be overridden by subclasses in interesting ways and it sounds like the sort of thing that will break when people try to run Sugar on platforms we
Re: [sugar] [PATCH] tweak battery charging (progress) bar
On Tue, Apr 29, 2008 at 5:46 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Apr 29, 2008 at 8:56 AM, Martin Dengler [EMAIL PROTECTED] wrote: On Tue, Apr 29, 2008 at 02:03:21PM +0200, Marco Pesenti Gritti wrote: On Tue, Apr 29, 2008 at 1:59 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler [EMAIL PROTECTED] wrote: +self.set_size_request(style.zoom(style.GRID_CELL_SIZE * 4), -1) Sounds good to me, but I think Marco dislikes set_size_request. Marco, what do you think? I don't think we should set palette size to a fixed width. The whole gtk layout logic is dynamic, so that, for example, you can increase the font size without screwing up... There is indeed little point in having a nice auto-sizing GUI if code is going to fix assumptions about sizes. In case you/anyone can think of something that might be acceptable, I want to make the motivation clear: 1) many of the palettes in the mockups at http://wiki.laptop.org/go/Designs/Frame seem to have a fixed size; and 2) on IRC eben mentioned he liked the palettes a bit wider (IIRC), and I, after trying it out on my XO, found the same. To make my goal clear: I have no intention of requiring all of the device palettes to be a fixed width. For that matter, I don't care to specify an absolute size for any of them individually. I do, however, want to ensure that the sliders and meters and such within them have enough horizontal space to accurately portray the info they contain. I think that the battery meter should be about twice as wide as it is currently. As such, there must be a way to tell it to be *at least* some width, since below that width it's less readable. This is not a fixed assumption. The palette can naturally expand as necessary to allow room for longer text, etc. Perhaps setting the request size of the progressbar may be better? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 6:10 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Apr 29, 2008 at 8:02 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Eben, Ben, are you ok with this? I'm certainly all for removing alt-n and alt-p. We don't need redundant shortcuts here, and alt-tab and alt-shift-tab will work fine. Also, I'm the one who mentioned that we should use alt-shift-tab instead of ctrl-alt-tab for going backwards, to be consistent with the modifier semantics we are aiming for, so I approve of that change. Fine. Ctrl-Q is likewise redundant with the ctrl-esc shortcut, which is a mostly non-standard shortcut, but somehow makes sense in this context anyway. (Hey, it beats alt-F4, right?...there's no logic there that I can see) In other news, after looking it up, it turns out that ctrl-esc used to be used to reveal the task manager in Windows, allowing one to terminate running programs (semantically aligned with our use here). Oddly, it has since been remapped to invoke the Windows start menu, with opposite semantics. This despite the fact that many PC keyboards even have a Windows key which does this anyway. In any case, I support our interpretation of ctrl-esc and think it serves the purposes without need for redundancy. Cool. In general, I would say that it's silly to use basic shortcuts for actions that have a dedicated button on the XO (rotate, frame), which means in general I approve of making alt-f and alt-r more complex for emulator users. On the other hand, if we do have a goal of making Sugar portable to other hardware, we can't make these assumptions as easily. Is it possible to define the shortcuts in a dynamic way, based upon some settings which determine what type of platform we are running on/in? I'm a bit worried by having different shortcuts depending on the machine. If we could find acceptable shortcuts for those (hopefully few) shortcuts that need to be global that were effective everywhere, that would be awesome. My only other comment applies to the comment itself, which I feel is slightly presumptuous. I would cut off the stuff after the comma, and leave it at that. Who knows, maybe kids in the field will install Fedora and emulate Sugar themselves! ;) Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:01 PM, Michael Stone [EMAIL PROTECTED] wrote: We have a completely different approach to activity launching in the works (I've been hacking it up myself...I need some help from the pros to finish it!) Why are we building a splash screen instead of speeding up activity launch? We know that programs can put up full-screen windows in 0.1-0.5s. We cannot presume that _all_ activities will be able to put a window in 0.1-0.5s, and probably don't want all the activity authors to implement something like that. I see as a good thing to improve both feedback and launch performance. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:44 PM, Michael Stone [EMAIL PROTECTED] wrote: On Tue, Apr 29, 2008 at 07:26:12PM +0200, Tomeu Vizoso wrote: We cannot presume that _all_ activities will be able to put a window in 0.1-0.5s, I think we are better served by presuming that activities which fail to start quickly are broken need to be fixed. For goodness' sake, we have a processor clocked at over 400 MHz that can play full-screen video. Does someone here actually wish to argue that it's acceptable for process creation, X connection setup, window creation, and painting to take long enough to require secondary feedback mechanisms? In a perfect world, you would be right. But that doesn't seem to be the world we are living in, because so many apps seem to need a banner while they launch (openoffice, gimp, banshee, etc.). I'm not 100% sure that we need such a strong feedback during launching, but just saying that we'll make everything fast enough and slow activities won't bite us is a bit courageous, at least. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:42 PM, Paul Fox [EMAIL PROTECTED] wrote:
tomeu wrote:
We cannot presume that _all_ activities will be able to put a window
in 0.1-0.5s, and probably don't want all the activity authors to
implement something like that.
I see as a good thing to improve both feedback and launch performance.
in the time i'd have otherwise wasted is free department, is
there currently (or planned) a mechanism to always launch
designated activities (either fixed choices, or choices based on
recent journal entries) at startup? i.e., if i always want
Terminal and/or Read running, then it would be good if their
startup time simply added to the boot time, rather than being
felt as an additional delay before i'm productive. i'm not a
fan of restore session mechanisms -- i usually want to start
from a known, fixed, state -- but it might similarly accomplish
the goal of folding actiivity startup into boot time.
(forgive me if this feature has been under my nose for some time
without me noticing it.)
I don't think this feature is planned for any time soon, but you can
easily hack the shell code for adding more activities to start:
/usr/share/sugar/shell/view/Shell.py :
if registry.get_activity('org.laptop.JournalActivity'):
self.start_activity('org.laptop.JournalActivity')
Good luck,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] DS possibilities
On Thu, Apr 24, 2008 at 1:36 AM, Martin Langhoff [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 7:42 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Reports from the field, especially from Carla and Bryan, have indicated that the datastore can get into a corrupted state from which it cannot recover. The corruption persists over a reboot. After corruption, Can we get copies of the corrupt DS files? You have one here: http://dev.laptop.org/ticket/6864 As per the irc discussion today, I think we can - teach the DS backend how to recover gracefully if it finds a corrupt entry - tweak the most vulnerable points of the DS code to be more atomic Agreed. My only doubt is if we should refactor or rewrite. One thing that I'd like to make clear is that I have never seen a corrupted Xapian index, nor have I heard of anything that points to this. The problems we have had with uninitializable datastores were due to trying to open an index with a too old release and with the 'config' file corrupted (http://dev.laptop.org/ticket/5494 and http://dev.laptop.org/ticket/6864). That file is not part of xapian but of the high-level python bindings (secore), and we are using a quite old copy of that. A good trick is to start yanking the power (or kill-9'ing the DS process) while something is being saved. Most of the times I've seen this kind of corruption, changing some open calls to make a copy beforehand was enough. If one document is lost due to powerloss, tough, the important thing is that on reboot everything still works, even if we lost that document. subsequent datastore calls usually raise exceptions, which are not handled by the Activities (including the Journal) and so no Activities will load, and Sugar is unusable. Activities should handle errors returned by the DS :-/ those are activity bugs. But we assume a generally working DS for a working Sugar environment. Agreed. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] DS possibilities
On Wed, Apr 23, 2008 at 10:19 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Based on these options, I personally recommend that the priorities be: 1. Write a new datastore implementation to the same API. 1. Set up a datastore test system. 2. Improve logging. - --- Future --- 3. Write a new datastore implementation with a new API. 3. Notify the user when things go wrong. My recommendation is not very strong. I can see many other reasonable arguments. However, I prefer this one: After glancing at Michael's Simple Data Store code, I am convinced that it would be easy to turn it into a complete implementation of the current datastore API, with a backend that is simply individual files in the filesystem. Where would metadata be stored? Search could be implemented by grep -R, or something of similar complexity. Hmm, I see filtering and fulltext search as really important features. Do we really want to grep instead of using some kind of index? I would be perfectly happy to replace the current datastore layer with this one (though the upgrade mechanism will take some careful thought). If some code from the existing implementation is still applicable, then it may of course be reused. Indeed, the rewrite vs. fix distinction is something of a false dichotomy; the major issue is whether or not to use Xapian and other advanced algorithmic designs. I think that most of our problems come from using Xapian for storing the metadata, but not from using it as what it is intended: a fulltext search engine. I actually think that it has worked quite well for that purpose. The principle objection to this path, it seems to me, is the possibility of introducing new (worse) bugs. A datastore test system would greatly increase confidence in any new implementation. If the test system can also reproduce crashes in the current implementation, then we may determine with some confidence whether the new implementation is more reliable (under those circumstances). Logging goes hand-in-hand with testing; it is needed in order to determine the results. Having better logging in production laptops will be a positive side benefit. Agreed, but I would like to note that the DS is (to my knowledge) the component in Sugar with most extensive unit tests. I recognize the importance of providing version control functionality within the datastore, but the deadline for this work appears to be July, pending an August release. It seems unlikely to me that any future-proofed version control system could be completed, and integrated with the rest of the system, in two months. If anyone wishes to argue the opposite point, I will be happy to listen, since I desire this feature greatly. If the version control project is sufficiently important, it may be acceptable to place an expert (presumably Scott) on this full-time targeting a December release. I think that it depends on which features we wish to add. This scheme may be enough to provide the user experience that Eben has devised: - Store a version number as a metadata property. Create a branch every time that a non-tip revision is resumed. Suggested format: 3.1.1. - Use xdelta to store backwards deltas between versions of the same file. Probably calculate a hash of the content so we can optimize out the no-changes case. - That's all ;) See here for the last work from Ben Saller related to versions: http://dev.laptop.org/git?p=projects/datastore;a=shortlog;h=version_prototype Notifying the user when critical system components stop working is a good goal as long as it doesn't distract from the more important work of making the critical system components work reliably. It seems to me that the UI team's work on the wide variety of frequent, user-interaction notifications is far more important, and also sets the stage for this work later. Yes, the journal full notification is one example. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Fix appearance of activity bundles (in Journal)
r+
On Sat, Apr 26, 2008 at 4:53 PM, Eben Eliason [EMAIL PROTECTED] wrote:
After much ado, here is the resulting patch.
- Eben
On Fri, Apr 25, 2008 at 2:17 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
On Wed, Apr 23, 2008 at 10:05 PM, Eben Eliason [EMAIL PROTECTED] wrote:
On Wed, Apr 23, 2008 at 3:52 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
On Wed, Apr 23, 2008 at 9:45 PM, Eben Eliason [EMAIL PROTECTED]
wrote:
Hmm, you mean:
if jobject.metadata.get('title', ''):
title_text = jobject.metadata.get('title', '')
else
title_text = _('Untitled')
title.props.text = title_text
...
Do I not need to declare title_text outside the scope of the
condition
first? For that matter, is the null string always treated as
False in
conditions, even though it's distinct from None type?
(Sorry...didn't
play in Python much before.)
Sorry, didn't meant that as a literal solution.
I supposed there's also:
title_text = _('Untitled')
if jobject.metadata.get('title', ''):
title_text = jobject.metadata.get('title', '')
title.props.text = title_text
This I don't like much, the person that reads needs to make more
effort to see that you are overriding the var.
This is what I would do:
if jobject.metadata.get('title', ''):
title.props.text = jobject.metadata['title']
else
title.props.text = _('Untitled')
I'm not sure I like that much either, since I have to set two things
to the values.
if jobject.metadata.get('title', ''):
self._title.props.text = jobject.metadata['title']
self._title_entry.props.text = jobject.metadata['title']
else
self._title.props.text = _('Untitled')
self._title_entry.props.text = _('Untitled')
Hence, the reason to use a variable instead. Do you prefer this?
Yes, a 'title' variable is better in this case.
if jobject.metadata.get('title', ''):
title = jobject.metadata['title']
else
title = _('Untitled')
self._title.props.text = title
self._title_entry.props.text = title
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] jumpy cursor problem and sugar issue
On Sun, Apr 27, 2008 at 4:50 PM, Bryan Berry [EMAIL PROTECTED] wrote: thanks Carol, this instruction for disabling the corner sensitivity is extremely useful! I may use it in the custom build I roll out, some 3-4 months from now. We plan to work on this soon. The plan is to have a delay since the mouse enters in the corner and before the frame is brought up. This delay will be configurable with an slide in the control panel. Thanks for the feedback, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 9:59 AM, John Gilmore [EMAIL PROTECTED] wrote: I'll say that the impression that I have received as an outsider is that the people working on Sugar have not at all been interested in compatibility with normal linux software. It's more accurate to say that while they are somewhat interested in that as an abstract idea, they are much more interested in making their interface whizzier, which is fun, and in rewriting the most obviously braindead parts of the Journal/Datastore, which staves off programmer and end-user insanity. (I'm paraphrasing drastically, from having watched a bit of their goal-setting for the next release from afar.) All this sarcasm only makes things even muddier. Please raise your concerns in a clearer way. If someone came along with clean patches to make Sugar work better with normal Linux/Unix software, I think they'd accept them. (Some patches to Gnome, KDE, and other window managers are also going to be needed, at least if Sugar apps want to show their current SVG icons; no other window manager supports drawing SVG icons.) Yes. If the community waited around til the two? three?-person Sugar team got around to implementing these features itself, they might have to wait til 2010 or so. Maybe not so long. But please send the patches anyway. [...] That has been patched, but just barely; the API still comes with terrible assumptions like of course the application will make a copy of every file it touches. This is plain false. Where did you get that idea? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Fri, Apr 25, 2008 at 11:50 PM, Martin Dengler
[EMAIL PROTECTED] wrote:
+self.palette = SpeakerPalette(_('My Speakers'), model=model)
+self.set_palette(self.palette)
'set_palette' is the setter for the 'palette' property, so the second
line shouldn't be needed.
+model.connect('notify::level', self._speaker_status_changed_cb)
+model.connect('notify::muted', self._speaker_status_changed_cb)
+self.connect('expose-event', self._expose_event_cb)
Callbacks should start with two underscores in order to avoid name clashes.
The rest looks good to me.
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 4:25 PM, Jim Gettys [EMAIL PROTECTED] wrote: On Mon, 2008-04-28 at 10:06 -0400, Walter Bender wrote: I must have missed the post you refer to. It has never been the position of the core Sugar team--that I am aware of--to preclude the running of standard Linux apps. We even went so far as to hire a contractor to look at various ways to facilitate the running of standard X apps last summer---although that work was never completed or brought into the main branch. Matthew Allum thinks we're best off not trying to force-fit this into matchbox (the window manager we're currently using), having done the experiment last summer. He's not only the contractor, but also the original author of matchbox; so I think we should respect his opinion in this matter. We'll investigate alternative window managers, rather than flogging this horse, which is clearly dead for our purposes. Many of the modern ones honor full screen hints, and I've never seen Sugar's UI do much that isn't supported one way or the other by the ICCCM/EWMH's. It may take a bit of sugar work, but I'd be surprised it will be difficult. If someone would like to go ahead and try replacing matchbox with metacity, would be great ;) Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Mon, Apr 28, 2008 at 3:58 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: One thing I observe is that it takes considerable time from when I click on 'Shutdown' in the Main view, until the XO actually stops. Thank you, I'd like to ask the people with actual machines to write to this list with their opinions about which parts of the UI are worst affected by slow performance. This particular issue about shutdown seems to me to be more related to non-Sugar elements. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Recursive Signal Loop.
On Thu, Apr 24, 2008 at 11:37 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 5:25 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 24.04.2008, at 22:56, Eben Eliason wrote: On Thu, Apr 24, 2008 at 4:47 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: you check the keep property before you set it, and do not touch it if you are not going to change it. That does in fact sound like a reasonable way to handle it. It doesn't require an extra time around the loopit simply stops it directly at the signal handler for the KeepIcon change event by not overwriting with the same value. Don't I feel stupid now I'd even consider it a bug if overwriting a property with the same value would emit a change event - but maybe this is how the framework works? Good point. That seems not to be the case. In other news, despite the much cleaner underlying code, my initial treatment fails to alleviate the symptom! It appears that the redraw doesn't happen until after all of the signal handling business has run its course. This includes, as mentioned in my first message, refreshing the entire view. I looked at this again, and there is no check for the particular CollapsedEntry which changed at all. Instead, it loops over each one, refreshing each by setting the jobject property of each, which of course resets the keep icon, resets the object icon, creates a brand new palette from scratch and attaches it to the object icon, looks up and formats the date, reads the list of buddies and creates their associated objects and palettes, and a number of other smaller tasks. That's for /each/ entry shown, all because one toggle button was clicked! This seems like serious overkill, but I'm not sure if there's an obvious way to isolate the changes. It does seem that, if anything, either the query.py or listview.py code should be more intelligent about determining what changes are worth doing such comprehensive updates for. This is not one of them. Tomeu, you worked on the query and list code. Do you have any insight into this? The lazy programmer that coded this (me) thought that the simple solution implemented was efficient enough and could be written in a simple way with many mainteinance advantages. Eben, your new designs will render this code totally obsolete, so what's the point in changing this right now? About the signal loop, it's my opinion that most property setting code should only do its thing if the new value is different to the current one. This can affect performance considerably, as well. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Fix appearance of activity bundles (in Journal)
On Wed, Apr 23, 2008 at 10:05 PM, Eben Eliason [EMAIL PROTECTED] wrote:
On Wed, Apr 23, 2008 at 3:52 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
On Wed, Apr 23, 2008 at 9:45 PM, Eben Eliason [EMAIL PROTECTED] wrote:
Hmm, you mean:
if jobject.metadata.get('title', ''):
title_text = jobject.metadata.get('title', '')
else
title_text = _('Untitled')
title.props.text = title_text
...
Do I not need to declare title_text outside the scope of the condition
first? For that matter, is the null string always treated as False in
conditions, even though it's distinct from None type? (Sorry...didn't
play in Python much before.)
Sorry, didn't meant that as a literal solution.
I supposed there's also:
title_text = _('Untitled')
if jobject.metadata.get('title', ''):
title_text = jobject.metadata.get('title', '')
title.props.text = title_text
This I don't like much, the person that reads needs to make more
effort to see that you are overriding the var.
This is what I would do:
if jobject.metadata.get('title', ''):
title.props.text = jobject.metadata['title']
else
title.props.text = _('Untitled')
I'm not sure I like that much either, since I have to set two things
to the values.
if jobject.metadata.get('title', ''):
self._title.props.text = jobject.metadata['title']
self._title_entry.props.text = jobject.metadata['title']
else
self._title.props.text = _('Untitled')
self._title_entry.props.text = _('Untitled')
Hence, the reason to use a variable instead. Do you prefer this?
Yes, a 'title' variable is better in this case.
if jobject.metadata.get('title', ''):
title = jobject.metadata['title']
else
title = _('Untitled')
self._title.props.text = title
self._title_entry.props.text = title
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Cerebro released
On Mon, Apr 21, 2008 at 9:41 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: (sorry for cross-postings) The first release of Cerebro is out! Cerebro basically offers scalable presence information and a simple collaboration API. Features currently include: - presence information (including distance and route) for all other users in the network - dynamic rate of updates based on density of neighborhood: No more than 1 update every 5 seconds (on average) guaranteed. - mesh network extended to regular 802.11b/g devices - extensible user profile including nickname, colors, keys, IP addreses, picture of arbitrary size, status message etc - file sharing using an efficient multicast mechanism - simple collaboration mechanism through 'share', 'join', 'leave' functions - simple programming API based on dbus (see examples) http://wiki.laptop.org/go/Cerebro Hi, what's the plan for putting this on the images? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Community-news] where is Walter?
2008/4/23 Martin Edmund Sevior [EMAIL PROTECTED]: I've stayed away from this discussion until now. But for my own part, if the OLPC becomes just another laptop running standard educational software of the kind that inhabits my daughters primary school, I'm no longer interested in the project. I really bought into the new paradigm of pervasive collaboration and constructionist education. I'm not particularly interested in a cheap laptop clone and in any case I guess my own work on Write and abicollab will be ditched for some stripped down version of MS Word. It would nice to know if this is the new vision or not. If it is the new vision I can stop wasting my time here. Martin Sevior In case people don't know Martin's work on OLPC (I think he's not very vocal about his achievements), he designed and implemented along Marc Maurer (uwog) the technology behind the collaboration feature of Write, AbiCollab. I believe this feature has had a big impact in showing the collaboration focus of Sugar. http://www.abisource.com/wiki/AbiCollab http://msevior.livejournal.com/21245.html If OLPC fails to understand what it takes to maintain such enthusiastic contributors on board, we're pretty much doomed. Is Microsoft going to provide those features that bring enormous value to education? Or translate its software to every language on earth? Call me fundamentalist, but I don't see how proprietary software can fulfill our educational goals. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] sugar pylint (vol2)
On Tue, Apr 22, 2008 at 5:02 PM, Simon Schampijer [EMAIL PROTECTED] wrote: Ok, Marco's workaround solved the gtk.gdk.window issue. Martin Dengler wrote: On Tue, Apr 22, 2008 at 02:20:12PM +0100, Martin Dengler wrote: On Tue, Apr 22, 2008 at 02:47:38PM +0200, Simon Schampijer wrote: Another issue I have quite often is the one of unused variables due to returned tuples and lists where not all the variables are used in the code. What about doing here, or any other options? IMHO, pylint shouldn't warn about these situations. The code it's complaining about is a lot nicer than the pylint approved alternative you mention. Evidently one other solution is to adopt a naming convention for the unused variables in a tuple-unpacking LHS and add that as a pylint rule: http://lists.logilab.org/pipermail/python-projects/2006-November/001059.html Best, Simon Martin This sounds good to me. I would vote for that solution. Thanks for sharing that thread! The patches look good to me. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Grassroots-l] creation of local feedback groups
On Mon, Apr 21, 2008 at 7:34 PM, Christoph Derndorfer [EMAIL PROTECTED] wrote: Zitat von Bryan Berry [EMAIL PROTECTED]: Tomeu, tomeu wrote: Hi all, now that a considerable number of people are starting to use the first minimally complete version of Sugar, may be a good moment to discuss and agree on which is the best way for feedback to reach us the developers. This is the right idea. The key would be for the coordinators of the local feedback groups to summarize but not filter or bias the response w/ their own concerns. Most local volunteers are tech-oriented (like myself) and it is easy for us alter the feedback we get or selectively hear or magnify the responses that match our own. We need info from groups that don't use the tools of open-source trade -- wikis, mailing lists, IRC. We will be providing a lot of feedback from our pilots starting this Friday. How should we send that feedback to the Sugar Team? the best persons on the OLE Nepal team to provide this feedback are Kamana Regmi and Bipul Gautam, two teachers who are not familiar w/ wikis, IRC, mailing lists, etc. It would be easiest if they had an e-mail address to send their responses to. They would be very confused by the tech talk on Sugar-Request and Devel-Request. I agree that it's absolutely necessary to keep the barrier to entry for this feedback as low as possible. While e-mails are certainly a good start I'd like to see the submitted information also be added to an online-database because I find mailing-list archives to be a consistent pain the ass when it comes to retrieving previous communication and information. A searchable and taggable database would certainly make that easier. Plus we also have to consider the fact that many of the people giving the most valuable feedback (=teachers) might not even speak English and it would be important to keep a record of their original feedback somewhere. In terms of the organizational structure it might make sense to have some sort of feedback-liaison in each group. So for example if OLPC people on the ground in Peru want to find out what's happening in Nepal they'd just have to contact one person directly instead of asking their way around. Should we maybe set up a wiki page for that kind of information? Cheers, Christoph If I summarize the input I will inevitably filter the information and magnify what I think is coolest. Ok, so sending email directly to the mailing lists may be too inconvenient, and we don't have yet a database like the one Christoph described. Can we use anything else in the short term, see how well it suits our needs, and then go back from there? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Community-news] on Sugar
Thanks for sharing your ideas about Sugar with us. Some comments follow below. On Wed, Apr 23, 2008 at 6:06 PM, Nicholas Negroponte [EMAIL PROTECTED] wrote: For this reason, Sugar needs a wider basis, to run on more Linux platforms and to run under Windows. We have been engaged in discussions with Microsoft for several months, to explore a dual boot version of the XO. Some of you have seen what Microsoft developed on their own for the XO. It works well and now needs Sugar on top of it (so to speak). Sugar already runs in many different linux distributions and is quite easy to make it run in others. Putting it to run in Windows in a similar way shouldn't be too hard, but that's probably not what you have in mind. Which kind of experience we would like to give to users of Sugar on Windows? Exactly the same they would have on Sugar on linux? What is in front of us is an opportunity for big change. Sugar is at the core of it. To pretend otherwise would be a joke. That said, Sugar needs to be disentangled. I keep using the omelet analogy, claiming it needs to be a fried egg, with distinct yoke and white, rather than having the UI, collaborative tools, power management and radios merge into one amorphous blob. Otherwise, it is impossible to debug and will be limited to the small, albeit growing, world of the XO hardware platform. What I personally call Sugar is quite distinct from that omelet, it doesn't include power management nor radios. And I'd say that it's easily ported to other linux distributions and hardware. My understanding is that the Sugar UI is composed of inseparable components because we wanted to give an integrated and coherent experience. In which way are you suggesting to split Sugar? And I don't think it's impossible to debug ;) Thanks again, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Fix appearance of activity bundles (in Journal)
On Wed, Apr 23, 2008 at 9:26 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
On 23.04.2008, at 21:23, Eben Eliason wrote:
if jobject.metadata.has_key['title'] and
jobject.metadata.has_key['title']:
Seems a bit redundant.
;)
I would go for
if jobject.metadata.get('title', ''):
_title = title
else:
_title = _('Untitled')
(more or less)
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Fix appearance of activity bundles (in Journal)
On Wed, Apr 23, 2008 at 9:45 PM, Eben Eliason [EMAIL PROTECTED] wrote:
Hmm, you mean:
if jobject.metadata.get('title', ''):
title_text = jobject.metadata.get('title', '')
else
title_text = _('Untitled')
title.props.text = title_text
...
Do I not need to declare title_text outside the scope of the condition
first? For that matter, is the null string always treated as False in
conditions, even though it's distinct from None type? (Sorry...didn't
play in Python much before.)
Sorry, didn't meant that as a literal solution.
I supposed there's also:
title_text = _('Untitled')
if jobject.metadata.get('title', ''):
title_text = jobject.metadata.get('title', '')
title.props.text = title_text
This I don't like much, the person that reads needs to make more
effort to see that you are overriding the var.
This is what I would do:
if jobject.metadata.get('title', ''):
title.props.text = jobject.metadata['title']
else
title.props.text = _('Untitled')
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Community-news] on splitting Sugar
On Wed, Apr 23, 2008 at 10:43 PM, John Gilmore [EMAIL PROTECTED] wrote: That said, Sugar needs to be disentangled. I keep using the omelet analogy, claiming it needs to be a fried egg, with distinct yoke and white, rather than having the UI, collaborative tools, power management and radios merge into one amorphous blob. My understanding is that the Sugar UI is composed of inseparable components because we wanted to give an integrated and coherent experience. In which way are you suggesting to split Sugar? It's possible to provide a coherent experience by coordinating work among several projects, rather than by forcing all the work into a single take it or leave it project. Some of the work below is already done, some is agreed to, some may never be done. Here's my take on the fracture lines on which to shape the diamond of Sugar: The collab framework should definitely be split, so that apps that run on any GUI can collaborate (with apps that run on their own GUI or on another). The window manager (shell) should be split from the application toolkit. This is a fairly small job, but nobody's done it. Right now, Sugar apps don't run on other window managers (they lack icons), nor do they work across a TCP connection (like every other X application) because the Sugar shell is looking *in its own local filesystem* for the application's icon. There appear to be other problems, which are easy to reproduce by setting DISPLAY on your OLPC, pointing it to any Linux machine that runs X, and then trying to start a Sugar activity. Similarly, it should work cleanly for an ordinary Linux app to be displayed remotely on an OLPC screen. This is the basic promise of X, but small dumb bugs break it currently. The Sugar file system (datastore / journal) is in my opinion a major mistake, and should be separated from the application toolkit. There are good reasons that hierarchical filesystems rather than blog-structured journals (or more complex databases) are the norm on every major OS. Apps should be able to use a standard file open dialog, and get the journal on OLPC, while the same source code gets the Finder/Open Dialog Box on MacOS, for example. The presence implementation only works on access points and on meshes -- but not on non-meshed, ad-hoc 802.11. The vast majority of computers with 802.11 don't have mesh, but they would benefit from being able to see nearby laptops and share applications with them (whether or not a local access point, or global Internet access, is working). For full integration, this probably requires some driver work, but most of the work is probably at a daemon and library level. These are the four major axes I see refactoring Sugar along. I agree with most of that, but I think that the biggest problem with sugar on windows is the shell. It provides several features already provided by the windows shell, and that overlap would cause severe confusion and frustration to users. Any suggestion on how to approach this? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Replace the back bar in the detail view
r+ On Mon, Apr 21, 2008 at 10:51 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Sat, Apr 19, 2008 at 7:09 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi, + self._back_bar_release_event_cb) Please preppend signal handlers with two underscores '__'. This will prevent name clashes when subclassed (other instances of this omitted). Done. + +back_bar = hippo.CanvasBox() + What's this? Good question. Removed. =) - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Patch] Add palettes to people and objects in Journal
On Mon, Apr 21, 2008 at 10:56 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 1:24 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 7:20 PM, Eben Eliason [EMAIL PROTECTED] wrote: +from palettes import JobjectPalette, BuddyPalette What about EntryPalette instead of JobjectPalette? An entry in the journal is the UI representation of a datastore object/ self._jobject = None +self._jobject_palette = None Same here, _jobject is the data, CollapsedEntry is one of the UI views of this data. I would call it _palette instead of _jobject_palette. Well, that's not actually accurate. See, the Collapsed entry is a container for the entry, which contains various details about it. The palette is specifically attached to the object itself, and not the entry. Consider, for instance, an entry (in the future) with several objects in it. Consider also, in the current design, that a single entry may also have several people icons (and palettes) attached to it. We need to make it clear that the palette belongs to the icon/object and not the entry as a whole. I chose JobjectPalette and BuddyPalette since a) it seems like the most direct mapping and b) these are also the classes of object that they take as arguments to the constructor. I see. I would prefer ObjectPalette then. a) is the right reason but b) shouldn't affect the name of the class. ObjectPalette it is. I also replaced commented blocks with TODOs and added a condition in the delete signal handler to ensure that the deleted object was the one currently shown in detail view. Sorry, missed this one: +self._object_palette = ObjectPalette(jobject) +self._icon.set_palette(self._object_palette) I think that you don't need to keep a reference to the object_palette in the entry, as you can access it easily by self._icon.palette. r+ with that change. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] support battery-charge-state-dependent battery frame icon
+curr_level = self._model.props.level
I would use current_level, the occasional reader may not have as much
context as you.
r+ with that
Thanks,
Tomeu
On Fri, Apr 18, 2008 at 12:59 AM, Martin Dengler
[EMAIL PROTECTED] wrote:
Support battery-charge-state-dependent battery frame icon and upgrade to
consistency with battery icon design from
http://wiki.laptop.org/go/Designs/Frame#06.
Controversially (or so I think), this commit includes a very naive algorithm
to calculate battery time/life remaining, as a principled approach is much
more complex and this approach is better than what a naive human would do
(e.g., only misleading to those who should be coming up with better patches
:)). The code is very localized and self-contained so it's easy to rip out
later.
---
src/view/devices/battery.py | 50
+++
1 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/src/view/devices/battery.py b/src/view/devices/battery.py
index 8a4caf0..f209ecc 100644
--- a/src/view/devices/battery.py
+++ b/src/view/devices/battery.py
@@ -19,9 +19,11 @@ from gettext import gettext as _
import gtk
from sugar import profile
+from sugar.graphics import style
from sugar.graphics.icon import get_icon_state
from sugar.graphics.tray import TrayIcon
from sugar.graphics.palette import Palette
+from sugar.graphics.xocolor import XoColor
from view.frame.frameinvoker import FrameWidgetInvoker
@@ -37,7 +39,7 @@ class DeviceView(TrayIcon):
xo_color=profile.get_color())
self._model = model
-self.palette = BatteryPalette(_('My Battery life'))
+self.palette = BatteryPalette(_('My Battery'))
self.set_palette(self.palette)
self.palette.props.invoker = FrameWidgetInvoker(self)
self.palette.set_group_id('frame')
@@ -48,21 +50,28 @@ class DeviceView(TrayIcon):
self._update_info()
def _update_info(self):
-name = get_icon_state(_ICON_NAME, self._model.props.level)
-self.icon.props.icon_name = name
+name = _ICON_NAME
+curr_level = self._model.props.level
+xo_color = profile.get_color()
+badge_name = None
-# Update palette
if self._model.props.charging:
status = _STATUS_CHARGING
-self.icon.props.badge_name = 'emblem-charging'
+name += '-charging'
+xo_color = XoColor('%s,%s' % (style.COLOR_WHITE.get_svg(),
+ style.COLOR_WHITE.get_svg()))
elif self._model.props.discharging:
status = _STATUS_DISCHARGING
-self.icon.props.badge_name = None
+if curr_level = 15:
+badge_name = 'emblem-warning'
else:
status = _STATUS_FULLY_CHARGED
-self.icon.props.badge_name = None
-self.palette.set_level(self._model.props.level)
+self.icon.props.icon_name = get_icon_state(name, curr_level)
+self.icon.props.xo_color = xo_color
+self.icon.props.badge_name = badge_name
+
+self.palette.set_level(curr_level)
self.palette.set_status(status)
def _battery_status_changed_cb(self, pspec, param):
@@ -92,13 +101,26 @@ class BatteryPalette(Palette):
self._progress_bar.set_fraction(fraction)
def set_status(self, status):
-percent_string = ' (%s%%)' % self._level
+curr_level = self._level
+secondary_text = ''
+status_text = '%s%%' % curr_level
if status == _STATUS_CHARGING:
-charge_text = _('Battery charging') + percent_string
+secondary_text = _('Charging')
elif status == _STATUS_DISCHARGING:
-charge_text = _('Battery discharging') + percent_string
-elif status == _STATUS_FULLY_CHARGED:
-charge_text = _('Battery fully charged')
+if curr_level = 15:
+secondary_text = _('Very little power remaining')
+else:
+#TODO: make this less of an wild/educated guess
+minutes_remaining = int(curr_level / 0.59)
+remaining_hourpart = minutes_remaining / 60
+remaining_minpart = minutes_remaining % 60
+secondary_text = _('%(hour)d:%(min).2d remaining'
+ % { 'hour': remaining_hourpart,
+ 'min': remaining_minpart})
+else:
+secondary_text = _('Charged')
+status_text = ''
-self._status_label.set_text(charge_text)
+self.props.secondary_text = secondary_text
+self._status_label.set_text(status_text)
--
1.5.4.1
___
Sugar mailing list
Sugar@lists.laptop.org
Re: [sugar] [PATCH] Add support for inline renaming of Journal entries
On Sat, Apr 19, 2008 at 8:11 PM, Eben Eliason [EMAIL PROTECTED] wrote:
On Sat, Apr 19, 2008 at 6:41 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
On Wed, Apr 16, 2008 at 6:30 PM, Eben Eliason [EMAIL PROTECTED] wrote:
The former patch cut some comments that should have been cut (and now
have been) in the initial visual patch. This eliminates those parts
of the patch.
+self._title_entry.props.widget.connect('focus-out-event',
+
self._title_entry_focus_out_event_cb)
I'd indent the second line just two additional tabs to the right.
I started there. The problem is that it's currently tabbed over as
far as it can go before breaking the 80 char boundary. Which style
convention should we break?
Sorry, I explained badly. I meant this:
self._title_entry.props.widget.connect('focus-out-event',
self._title_entry_focus_out_event_cb)
If you cannot make the indentation beautiful, then fall back to the
simplest rule: two extra tabs (one may be confusing because of code
blocks).
+if event.key == hippo.KEY_RETURN:
+self._set_title(entry.props.text)
+self._title_entry.set_visible(False)
+self._title.set_visible(True)
+elif event.key == hippo.KEY_ESCAPE:
+entry.props.text = self._title.props.text
+self._title_entry.set_visible(False)
+self._title.set_visible(True)
I wonder if hardcoding the return and escape keys are really needed,
or if gtk has a better way of doing this.
Hmm, I'm not sure. I'll happily change this if someone has a better way.
I think we want to apply the changes when the 'activate' and
'focus-out' signals are called. About when to undo the changes, seems
like we need to listen for the escape key as you are doing.
+self._title_entry.set_visible(False)
+self._title.set_visible(True)
These two lines are repeated after every time we end editing the
title, can this duplication be removed?
Sure. Any thoughts on an appropriate function name?
_restore_title_label, _title_edit_completed ?
Can it be merged somehow inside _set_title()? And perhaps this method
should be called instead _apply_title_change()?
+def _set_title(self, title):
+if title == '':
+self._title_entry.props.text = self._title.props.text
I guess that you don't want to let the user remove completely the
title of an entry, can we make it more explicit?
Indeed, that's the idea. Do you mean I should add a comment to this
effect above the conditional, or is there a way the code could read
more clearly itself?
Hopefully the later. You are not doing anything specially complicated,
so I would prefer if we could avoid the extra comment by making the
intentions of the code more explicit.
self._title.props.text = self._format_title() + _(' Activity')
+self._title_entry.props.text = self._format_title() + _('
Activity')
We have a big problem here: https://dev.laptop.org/ticket/6875 .
Activity should be a formatting thing, shouldn't get into the
datastore.
Yes, I noticed this problem while making this patch. I'm happy to see
there is already a ticket, as it was on my list to enter one for it
anyway. I think I'd actually recommend cutting the title formatting
completely, and simply depending upon the unique visual treatment to
identify the bundle for now. I'll think about it, and perhaps provide
a separate patch for it. Do you think it should go in along with this
patch?
I think it could got in this patch if it's better for you, but
attaching a more focused patch to the ticket may be better process.
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Patch] Add palettes to people and objects in Journal
Hi,
+from palettes import JobjectPalette, BuddyPalette
What about EntryPalette instead of JobjectPalette? An entry in the
journal is the UI representation of a datastore object/
self._jobject = None
+self._jobject_palette = None
Same here, _jobject is the data, CollapsedEntry is one of the UI views
of this data. I would call it _palette instead of _jobject_palette.
+def _data_store_deleted_cb(self, uid):
+self._show_main_view()
Hmm, so we are going to switch to the main view every time that an
object in the DS is deleted? If an activity decided to delete an
object, the journal would switch to the main view and that would
confuse the user. May be better to handle this at the UI level,
without going to the model. The UI elements that trigger the deletion
may inform the UI element capable of switching views that a deletion
happened.
After writing the last paragraph, perhaps easiest and best would be to
keep listening the DS like you are doing, but only switch to the main
view if the jobject deleted is the one we are displaying the detail
of.
+
+menu_item = MenuItem(_('Start with'), 'activity-start')
+menu_item.props.sensitive = False
+#menu_item.connect('activate', self.__start_with_activate_cb)
+self.menu.append(menu_item)
+menu_item.show()
+
As this code doesn't bring much new and is unused, may be better to
not commit it for now. A TODO comment may make more sense.
Nice patch, and not too long nor too short. Please keep them like this.
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Patch] Add palettes to people and objects in Journal
On Mon, Apr 21, 2008 at 7:20 PM, Eben Eliason [EMAIL PROTECTED] wrote: +from palettes import JobjectPalette, BuddyPalette What about EntryPalette instead of JobjectPalette? An entry in the journal is the UI representation of a datastore object/ self._jobject = None +self._jobject_palette = None Same here, _jobject is the data, CollapsedEntry is one of the UI views of this data. I would call it _palette instead of _jobject_palette. Well, that's not actually accurate. See, the Collapsed entry is a container for the entry, which contains various details about it. The palette is specifically attached to the object itself, and not the entry. Consider, for instance, an entry (in the future) with several objects in it. Consider also, in the current design, that a single entry may also have several people icons (and palettes) attached to it. We need to make it clear that the palette belongs to the icon/object and not the entry as a whole. I chose JobjectPalette and BuddyPalette since a) it seems like the most direct mapping and b) these are also the classes of object that they take as arguments to the constructor. I see. I would prefer ObjectPalette then. a) is the right reason but b) shouldn't affect the name of the class. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add support for adding/removing activities to/from ring in palettes
r+
On Thu, Apr 17, 2008 at 7:08 PM, Eben Eliason [EMAIL PROTECTED] wrote:
On Thu, Apr 17, 2008 at 11:42 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
Hi,
+self._bundle_id = activity_info.bundle_id
+self._version = activity_info.version
+self._favorite = activity_info.favorite
Do we really need to store favorite in a member variable? Cannot just
use whatever value has favorite when activity-changed?
Actually, we do need to hold onto it. We need this value when the
favorite button is clicked on, to what value to set in the registry.
Apart from that, your suggestion would work fine.
+self._favorite_item = MenuItem(_('Add to ring'))
You are defining this same string twice. Why not just create the
_favorite_item in the constructor as you are doing, but without
passing any label? After the menuitem is created, you can just call
_update_favorite_item() and that would set the label and the color.
Good idea. The attached patch fixes this, and cleans up the way that
the label is accessed for setting as well. Unfortunately, do to the
internals of MenuItem, I have to pass a '' null string to the
constructor anyway, or it's not possible to later set the label.
Thanks!
- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Improve formatting of relative dates
On Sat, Apr 19, 2008 at 7:54 PM, Eben Eliason [EMAIL PROTECTED] wrote:
+NOW = _('Seconds ago')
Translators may not be able to translate adequately from 'Seconds
ago'. Perhaps a translation comment may help here? Example from
misc.py:
# TRANS: Relative dates (eg. 1 month and 5 days).
What if we are explicit in the comment about the intended meaning of NOW, as
in:
# TRANS: Indicating something that just happened; just now, right
now, moments ago
Sounds good.
+AGO = _(' ago')
...
+return result + AGO
This will break in most languages other than english. Sayamindu, do
you have any idea about what can be done here?
Likewise:
# TRANS: Indicating time passed, eg (1 month, 5 days ago); ago, in
the past, earlier
Yes, but in some languages that string may appear in a different
position inside the sentence. What about _('%s ago') % result instead?
Btw, may be better to change the name of the result variable to
something more descriptive (like 'period'?).
http://docs.python.org/lib/typesseq-strings.html
Good points. I'm certainly not sure how translations would work, but
this approach seemed the most appropriate for the english audience to
me. Is offering a few synonyms for the intended meaning appropriate in
a TRANS comment?
Not sure, what thinks Sayamindu?
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add support for inline renaming of Journal entries
On Wed, Apr 16, 2008 at 6:30 PM, Eben Eliason [EMAIL PROTECTED] wrote:
The former patch cut some comments that should have been cut (and now
have been) in the initial visual patch. This eliminates those parts
of the patch.
+self._title_entry.props.widget.connect('focus-out-event',
+
self._title_entry_focus_out_event_cb)
I'd indent the second line just two additional tabs to the right.
+self._title_entry.connect('key-press-event',
+ self._title_entry_key_press_event_cb)
This as well as the above would go inside _create_title_entry().
+if event.key == hippo.KEY_RETURN:
+self._set_title(entry.props.text)
+self._title_entry.set_visible(False)
+self._title.set_visible(True)
+elif event.key == hippo.KEY_ESCAPE:
+entry.props.text = self._title.props.text
+self._title_entry.set_visible(False)
+self._title.set_visible(True)
I wonder if hardcoding the return and escape keys are really needed,
or if gtk has a better way of doing this.
+self._title_entry.set_visible(False)
+self._title.set_visible(True)
These two lines are repeated after every time we end editing the
title, can this duplication be removed?
+def _set_title(self, title):
+if title == '':
+self._title_entry.props.text = self._title.props.text
I guess that you don't want to let the user remove completely the
title of an entry, can we make it more explicit?
self._title.props.text = self._format_title() + _(' Activity')
+self._title_entry.props.text = self._format_title() + _('
Activity')
We have a big problem here: https://dev.laptop.org/ticket/6875 .
Activity should be a formatting thing, shouldn't get into the
datastore.
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Record (was Re: VoiceThreads ... a very interesting education service)
On Wed, Apr 16, 2008 at 11:05 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 4:48 AM, Gary C Martin [EMAIL PROTECTED] wrote: Maybe if Journal item sharing arrives as some point, this will be a practical way of generating and sharing similar content. Yes - although that's more transfer of content than collaborating together in the activity (as I understand it). Perhaps we could distinguish between synchronous and asynchronous collaboration? Transfer of frozen activities may serve for the later. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Server-devel] sugar roadmap
On Wed, Apr 16, 2008 at 2:52 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:29 PM, Benj. Mako Hill [EMAIL PROTECTED] wrote: On Sun, Apr 13, 2008 at 10:02 PM, Martin Langhoff Personally, I have been dreaming of a mix between ion3 and Sugar's 4-zoom-stages. Talking with some hard-core ion3 friends, they seemed to be convinced that it was doable as a special configuration, binding the F1-F3 keys to full screen apps, and having a nested X in F4. Yes. This would be pretty simple. I'd be happy to help someone hack this up. Ion3 is extensible in Lua and a little bit of Lua will get tihs up and running pretty quickly. The whole plan would look like - Network-pane visual app on F1 - Network-local-resources+Friends visual app on F2 - Desktop mgmt app on F3 - F4 as an ion3 managed desktop You mean the zoom levels when you talk about F1, F2, etc, right? with the whole concert of things managed by Ion3. Good to know that the Ion3 Lua part is doable and relatively easy. The visual apps needed for F1/2 are probably a ton of work. Apps or rather windows created by the shell process? H. A weekend project for next time I have a weekend (next one up: Feb 2010 I think ;-) ). Maybe next time I'm in Cambridge we can explore it together if you have time+inclination... Can we have some more discussion here? I'm very intrigued about all this. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] sugar roadmap
On Mon, Apr 14, 2008 at 2:59 AM, Patrick Dubroy [EMAIL PROTECTED] wrote: On Sun, Apr 13, 2008 at 2:44 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: [snip] True, I'm afraid too that at the short and medium term hackers won't be scratching their itches in Sugar. But is also true that for many people, making education more accessible is one of the main itches in their lives. Those people are there, but will take time to pick them from the crowd. Has there been any thought in trying to position Sugar as a more general-purpose desktop? I don't see it as being particularly child-specific. It might also appeal to people who are looking for a simple, no-nonsense interface, especially to install on older machines or some of these new sub-notebooks that are getting popular. Certainly. Another option would be to create a version of Sugar that appeals to programmers. But I can't imagine creating such a version that wouldn't require a lot of programming resources. So here's another question: are any of the Sugar developers using it as their desktop shell? I was thinking of giving that try. If all the Sugar developer were eating their own dogfood, I'll bet you'd get a programmer-friendly system in a hurry. In fact, I don't see why it would be considered to be programmer-friendly already -- it's got terminal and a text editor, what more do you need? ;-) Yes, but we are so few developers that until now we have decided to focus on the most immediate goals. But if you wanted to give it a try and post the missing features that you think are most needed, you're more than welcome. For sugar development, I have dreamed on a sugar shell nested inside an activity, so you could restart that nested shell without loosing your open activities, etc Anyhow, speaking as someone who has only very recently gotten involved with the project, I can say that the Sugar interface was one of the most appealing things to me. I'm sure there are other potential contributors out there who would be attracted for the same reasons. Yes, I hope that the community grows soon to a point where newcomers are better welcomed and contributions better received. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] sugar roadmap
On Mon, Apr 14, 2008 at 3:10 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Dubroy wrote: | On Sun, Apr 13, 2008 at 2:44 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: |Another option would be to create a version of Sugar that appeals to |programmers. But I can't imagine creating such a version that wouldn't |require a lot of programming resources. | | So here's another question: are any of the Sugar developers using it | as their desktop shell? I was thinking of giving that try. If all the | Sugar developer were eating their own dogfood, I'll bet you'd get a | programmer-friendly system in a hurry. In fact, I don't see why it | would be considered to be programmer-friendly already -- it's got | terminal and a text editor, what more do you need? ;-) Yes: I take my XO with me to class and take notes in Write. I used to take my Thinkpad with me everywhere; now it never leaves my desk. I run unmodified Joyride builds on my XO, and I find the interface to be both superb and useful. I recently developed the DOSConsole activity solely on the XO itself, not because I was trying to prove any point but because it was the most convenient way. I'm curious to know what your list of missing features and bugs looks like. No: On my desktop I run in Xinerama with two different-sized LCDs. Together, they have about 8 times the area of an XO screen. Sugar will never make sense for that hardware without a serious redesign. On the other hand, running individual activities in windows managed by Metacity would probably work fine. Agreed. | Anyhow, speaking as someone who has only very recently gotten involved | with the project, I can say that the Sugar interface was one of the | most appealing things to me. I'm sure there are other potential | contributors out there who would be attracted for the same reasons. Me too. The project was vaguely interesting until I ran Sugar in Qemu, at which point it became compelling. Nice to hear that, please keep giving your feedback and suggestions. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC News (2008-04-12) - Addendum
2008/4/12 Kim Quirk [EMAIL PROTECTED]: Additional community news that didn't make it into Walter's email: I'm very pleased to see a more technical weekly news posted to the mailing lists. I'll try to give more detailed info about my work (and invite others to do the same) so all the community benefit from a better insight of what's going on inside OLPC. Thanks Kim, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar restart lost Journal, and some customization
Hi, On Fri, Apr 11, 2008 at 9:57 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: G1G1. Joyride 1848. Made the mistake of pressing ctl-alt-erase. When the new Sugar came up, it asked me for the Name and the Colors. I found that I had lost the previous Journal contents, and the Main screen's activity ring. Cannot reproduce this. Can you? I don't depend upon the Journal. What got me upset was that from then on, if I did a manual edit of /home/olpc/.sugar/default/config and then rebooted the XO -- this file's content was RESET to however that earlier Sugar restart had set up this file. [I had hoped that this file's contents would *persist* between reboots.] Reinstalled Joyride, to try to ward off this behavior. But will NOT again attempt to restart Sugar (as it advises) after changing sugar-control-panel -- will instead be rebooting from scratch. Would be great if you could help us to track this down. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] sugar roadmap
Hi, On Sat, Apr 12, 2008 at 12:58 PM, Bryan Berry [EMAIL PROTECTED] wrote: [snip] Another issue related to the Roadmap . . . ==The Problem of Building an Open-Source community around Sugar== I foresee problems building an open-source community around Sugar because most successful open-source projects are ones that allow programmers to scratch their own itch that is build or improve tools they themselves use. Sugar will primarily be used kids and adults w/ low literacy. I can't see programmers using it as their own desktop. True, I'm afraid too that at the short and medium term hackers won't be scratching their itches in Sugar. But is also true that for many people, making education more accessible is one of the main itches in their lives. Those people are there, but will take time to pick them from the crowd. A good case in point is GCompris which addresses a critical need of millions (basic math and English) but has very few contributors from what I can tell. Contrast this w/ something like git or the gnu utilities. I believe that Sugar will need longterm financial support to be viable. Perhaps that could come from some of the more enlightened pilot countries once they are heavily invested in Sugar. Yes, but Sugar/OLPC could get much more public exposure than GCompris, and that may influence things. But I agree with you in that the biggest contributions may come in the medium term from deployers, rather than hobbyists. But if OLPC fulfills its aims to deploy really massively at the global scale and Sugar is in there, we would see lots of contributions from users, and that should outgrow deployers' contributions. Another option would be to create a version of Sugar that appeals to programmers. But I can't imagine creating such a version that wouldn't require a lot of programming resources. Regardless the resources needed for that, do you have any rough idea of how that would look? (sorry for asking this question when you are so busy with the Nepal pilot). Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (partial) AP palette patch
On Fri, Apr 11, 2008 at 12:12 PM, Simon Schampijer [EMAIL PROTECTED] wrote: Thanks Tomeu for reviewing. I few things I found out when looking into that - I don't think introduced by the patch but maybe worth to look at. - I had the 'connecting...' label in the palette on the mesh view even though I was already connected. Later it went away. - The palette of the AP in the frame should probably get rid of the 'Disconnecting...' label as well and make it 'Disconnecting' - well introduce the new layout here as well - Sometimes the AP icon in the frame is black and white - even though I am connected fine Most of those issues seem to me to be related to the code between the NetworkManager and the UI. Some logging output would confirm that. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] sugar roadmap
On Thu, Apr 10, 2008 at 4:37 PM, Bryan Berry [EMAIL PROTECTED] wrote: I have looked at all 3 docs and they look good have some comments 1. Who is in charge of Sugar? the team lead. I remember that Blizzard used to be the team lead. Is it JG now? Well, I'm afraid I don't have a name to give to you, so I'll instead write a bit about how things work from my point of view. Currently three people are payed for working on Sugar: Marco (half-time, payed by Red Hat), Simon and me. We are in the process of hiring one more full-time developer, ideally based in Cambridge. Marco maintains sugar-base, sugar-toolkit, sugar, artwork, hulahop, and maybe something else. Simon maintains Browse. I maintain the Journal and, as OLPC hasn't hired nobody for this, the datastore. Technical decisions are taken in committee, with the participation of members from the community and other OLPC people. The roadmap and strategy is given by Kim, who normally asks for the participation of several members of OLPC. Last time I was told, Walter and Kim would work together and decide how the tech team could better answer the needs from pilots and deployments at every release. 2. Need a really easy way to play music and video files including ones w/ proprietary codecs. Kid finds mp3 file on the internet using browse, kid double-clicks file. It should open with the activity that supports that file type. Use Case: The kid should be able to access the same file again later from the Journal and open up in the appropriate activity/player (should one be loaded) OLPC won't have to pre-load the proprietary codecs for this to work. Leave that to deployment people like myself. just make it easy for us to load them using mechanisms like the customization key. Yes proprietary is bad but allowing kids to explore on their own -- an essential aspect of constructionism -- is more important. We cut off many avenues of exploration when we make it hard for them to access content that happens to use proprietary codecs -- which is the majority of interesting content on the Internet. 2.1 The XO needs a rock-solid media player. To me this is as essential as the Journal. Agreed, unless someone convinces OLPC to devote resources to this, someone from the community will have to jump and work on this. Here is a good start using gstreamer: http://dev.laptop.org/git?p=projects/jukebox-activity;a=summary 3. Need easy way to group links to activities, such as in a lesson plan. Use Case: Kid reads through geometry tutorial and clicks on first activity which opens up Dr. Geo. After finishing w/ Dr. Geo he does some more reading in the tutorial and then clicks on a second link which opens up a related GCompris activity. We need a way to launch different activities from within a graphical context, e.g. a tutorial. HTML is the most practical way to do this. I know there are issues w/ Rainbow and activities calling other activities but this is very important to the learning process. Interesting, would like to know what Eben thinks about it. 4. Don't see olpcfs in the roadmap, is that just a proposal? I think so. 5. Get long-term funding for Sugar Development. OLPC needs to set aside funding to support Sugar long term (5+ years) as an open-source project. Thanks for your support, I hope that in a couple of years we'll see Sugar being used outside OLPC and capable of self-sustaining. When a few countries deploy Sugar like it is planned, it will make a lot of sense for them to devote development resources to improve Sugar in the way they see fit. 6. Graphical control-panel needs way to increase default font-size of the sugar UI Marco has been doing recently some work related to dynamically changing the font size , I think. 7. Need graphical activity manager for removing and adding activities Could you detail the requirements for this? Perhaps in the wiki? Keep up the great work and make your way to Kathmandu some time. Will love to! Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (partial) AP palette patch
On Thu, Apr 10, 2008 at 12:53 AM, Eben Eliason [EMAIL PROTECTED] wrote: What do you mean here? +self.props.icon_name = icon_name +# This breaks style guidelines; we should store a reference +self._palette._icon.props.icon_name = icon_name I'm accessing the private _icon member of the palette class, rather than keeping a reference to it to use for this purpose. It was a quick hack. This is not breaking style guidelines, but encapsulation, which is a basic concept when designing object-oriented APIs. Related links: http://en.wikipedia.org/wiki/Information_hiding http://en.wikipedia.org/wiki/Separation_of_concerns http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 I think we should only push hacks like this to master repositories in cases of emergency when refactoring is not an option (very close to release date). Also, if you have felt the need to do such a thing, means that our API has a problem somewhere that should be solved ASAP. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar roadmap
Hi all, right now we have info about the sugar roadmap in several places: http://wiki.laptop.org/go/Sugar_Roadmap http://dev.laptop.org/git?p=users/marco/sugar-docs;a=blob;f=roadmap.txt http://lists.laptop.org/pipermail/sugar/2008-April/004909.html We are still having a vigorous debate about what we should work in the following months, and I think it would be a good moment to merge all this info. Because of this volatility, in a way that allows us to move blocks of todo items forward or backward. My motivation for this is twofold: - present this information better organized for gathering better input from the community, - mark the items that could be worked on immediately by people willing to contribute. Anybody thinks it is a bad idea? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (partial) AP palette patch
r+ On Thu, Apr 10, 2008 at 3:02 PM, Simon Schampijer [EMAIL PROTECTED] wrote: Eben Eliason wrote: I made the following changes to the patch: - display the AP icon in the palette in color - display the badge as well - removed the channel info in the secondary-text (for now) Sounds good. What do you mean here? +self.props.icon_name = icon_name +# This breaks style guidelines; we should store a reference +self._palette._icon.props.icon_name = icon_name I'm accessing the private _icon member of the palette class, rather than keeping a reference to it to use for this purpose. It was a quick hack. I changed this now to be: +self.props.icon_name = icon_name +icon = self._palette.props.icon +icon.props.icon_name = icon_name Full patch is attached. The Connect icon is 'dialog-ok' the disconnect 'media-eject', should we make this 'dialog-cancel' to be consistent? Well, it's consistent in naming, but not necessarily in experience. Where possible, I'd like to find ways to avoid the overloaded 'x' icon. It seems that using the eject icon for various types of external media makes sense, and I thought it might also apply to access points, which we treat as wireless devices. Alternately, I'd be open to a better suggestion for a connect icon. Yeah that sounds maybe like the best approach - to have a specific icon for connect/disconnect. Using a plug (connected/unconnected) icon might suggest a physical connection - not sure if we would want that association. Let's see if I can come up with something better. Another thought that come to my mind - the AP icon in the frame should maybe come with a badge as well. Hmm, perhaps. Although I'm not sure that the info provided by the badge is needed once it is shown in the Frame anyway. Also, we need to leave room for an alert badge if the wireless device in the Frame has trouble. I'd leave it as is, for now. I thought of it more like instantly knowing which AP you are connecting to. The badge is a visual hint as well. But the alert badge might be a reason not to have it. Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] interoperating with non-Sugar Jabber clients
On Thu, Apr 10, 2008 at 10:12 PM, Morgan Collett [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 6:37 PM, Dafydd Harries [EMAIL PROTECTED] wrote: It would be nice if the Chat activity could be used to converse with non-Sugar Jabber clients. The presence service has some code to generate invitations when somebody initiates a conversation, but Sugar doesn't do anything with these invitations. One open question is how to associate the invitation with the Chat activity. Should the association be hardcoded? What should the shell do if Chat is not installed? Given that there are no alternatives to Chat, I'm in favour of hardcoding it, at least for a proof of concept. If Chat's not installed, drop the invitation on the floor. sugar.presence emits 'private-invitation' with the Telepathy text channel for the connection with the non-Sugar client. Sugar team, can we (in the shell) iterate over the installed activities to find Chat? The issue I'm not sure of is how to pass the Telepathy channel in the invitation to Chat. Do you already have some code I can see to understand better the situation? We can hardcode Chat, but I guess we would like to avoid that. This new kind of invitation can only be consumed by Chat and Chat-likes? Not other activities? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] GVFS, OLPC, and GIT ?
On Wed, Mar 26, 2008 at 12:16 PM, Alexander Larsson [EMAIL PROTECTED] wrote: On Tue, 2008-03-25 at 16:27 -0400, Benjamin M. Schwartz wrote: On Tue, 2008-03-25 at 15:46 -0400, Martin Langhoff wrote: On Tue, Mar 25, 2008 at 10:29 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: | sufficiently generic to encompass multiple versions. I do not fully | grasp the layering between GIO and GVFS. Be aware that GIO/GVFS are very high level. In other words, they work for the Gnome guys because they don't realise that not all the world links to libgnome ;-) To be clear, my disappointment is in fact that GVFS is not high-level enough. It seems to me that a path-based filesystem API is not appropriate for a versioning datastore, because the versioned objects themselves contain path trees, leading to ambiguity about the meaning of a path. This goes double when both versioning and complex metadata are present. I would prefer something much more like a typed OO interface. Indeed, that is what we have now: an object-oriented DBus API. That still seems like the best solution to me. I agree that a path based filesystem is not the ideal for a versioned datastore. However, it may be useful as a *view* of such a datastore for applications that are not programmed against the (likely very different) API of the data store. However, as the olpc project has much more control of the software running on the laptops you might be able to only ship software that uses the native datastore APIs. A native API for a versioned datastore should probably make away completely with filenames, instead use some autogenerated unique identifier like uuids, have document type specified in the file creation operation and allow specifying which version fork to open in the open content stream call. This is interesting in its own, but not the goal of gvfs, the gvfs goal is more like allowing access to the path-based file stores that already exists and where users have files stored. You have just described the current API: http://wiki.laptop.org/go/Activity_DBus_API#Datastore The argument being made is that exposing versioning and metadata through the old path-based operations in POSIX would be a better API because of compatibility with current code and an API already known by developers. I'm still not decided one way or the other, I would like to see first how existing and new activities would interface with the new DS through the new path-based API. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] creative commons and licensing in sugar
Hi, would like to apply soon the work that CC has been doing about licensing in the journal. http://wiki.laptop.org/go/Creative_Commons Eben, are you aware of how this affects the UI and agree with that? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] A Sugar TODO List, of Sorts
Forgot to add my items: - Implement search in the activity list (needs specs) - Implement sorting in the activity list (just name and date?) - Implement installation date in the activity list - Execute the correct version of the activated bundle (patches pending discussion) - Transfer missing bundles when joining an activity - Transfer the activity icon along the rest of the information about a shared activity - Store in the journal the version of the bundle that created the entry Tomeu On Mon, Apr 7, 2008 at 9:00 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi, follow some requests for comments, details, etc. I propose to move the items marked as Ok to a page in the wiki, and continue to do so as we progress in the clarification of the rest of the items. Sounds good? On Mon, Apr 7, 2008 at 7:20 PM, Eben Eliason [EMAIL PROTECTED] wrote: Shell Notifications • Make notifications slide into or out of the Frame Which notifications slide in or out? • Create notification API (delay, type (in|out|remain)) Can you specify how the different types of notifications behave? • Reveal palette when clicking on notification, or reaching screen corner Ok • Add AlertBox for use with palettes/notifications Ok Clipboard • Use notification (instead of revealing Frame) when making a clipping Ok • Create clipping API (title, creator, icon, preview) Asked about this in a separate thread. • Add clipping previews (related to above) Which clipping types can be previewed? Just images and text? • Color copy/paste buttons in activities Which colors should take? Just the local colors? • Fix visual style for drag'n'drop Can you specify? People • Use notifications for XOs in Frame, when joining/leaving the activity Ok • Render XOs that have been invited or have temporarily left as outlines in Frame Ok • Expose buddy-active and buddy-inactive signals in PS, to enable above Ok • Expose a status property for buddies in PS Ok • Expose an avatar property for buddies in PS? svg? any pixbuf? which size limit? • Implement status as secondary text in buddy palettes Ok Activities/Places • Expose the activity name, activity preview in PS Activity preview is doable? Which screen size? Which maximum size for transfer in the mesh? • Implement share with functionality (from Frame) Ok • Make current activity icon clickable in Frame Ok • Make activity zoom level button cycle active activities? What's the doubt here? Devices • Tweak battery fully charged behavior What needs tweaking? • Implement white vs. colored battery style When is one or the other? • Add speaker device, with volume adjustment Ok • Add screen device, with brightness, color/BW adjustment Ok • Add device notifications (battery, storage, etc.) Can you specify each of those? Neighborhood • Remove mesh portals from neighborhood Ok • Add icons to palettes of APs, add channel as secondary text Ok • Remove ... from Disconnect option on APs Ok • Identify the school server visually in the mesh Ok. Which actions contains the palette? • Attach register option to the school server icon Ok • Gray badges along with icons when searching Ok • Add list view, group people under activities Do we have mockups? • Add modal alert before destructive changes (eg. change channel)? From where can the channel be changed? Groups • Refactor visualization of Groups, according to designs Do we have mockups in the wiki? • Provide basic support for creating groups, inviting people to groups Can you specify? • Add list view, group people under activities Mockups? Home • Implement start with functionality Ok • Add recent view of Home, or at least recent items in palettes Ok • Implement basic launcher service for search field Can you specify? • Add grouping (by identity thread) to activities list Pending on ongoing discussions about bundle signing. Activity • New activity launch behavior Needs to be specified. • Remove activity toolbar, add non-modal naming notification? Needs to be specified. • New toolbar design? Needs to be specified. Core • Fix startup sequence colors, etc. Can you detail more? • Create a sane color picker Mockups? • Improve object picker design, add search/filters Can you specify? • Add the control panel work Ok Journal -- • Use new visual style for list Do we have mockups? • Add palettes to activity icons Ok
Re: [sugar] PenTablet user interface
Best would be to create personal trees for sugar-toolkit and Paint: http://wiki.laptop.org/go/Creating_a_personal_git_tree But you would need an account in dev.laptop.org for that. You can ask to Henry Hardy (our sysadmin) in a similar way to project hosting requests: http://wiki.laptop.org/go/Project_hosting But I guess it will be easier for you to just send the patches to this mailing list, that's also fine. Thanks, Tomeu On Mon, Apr 7, 2008 at 10:24 PM, Patrick Dubroy [EMAIL PROTECTED] wrote: Great! I think the best thing to do right now is for me to release what I have. Can you (or anybody else) suggest the best place to put the code? Here's what I have: - a GTK widget for the 1-to-1 case. This is eventually destined for sugar.graphics, I think. - an activity that demonstrates the proposed interfaces for the unconstrained drawing task (e.g. Paint) - (soon) a GTK container widget for the unconstrained drawing task. However, the actual behaviour of this widget is still to be determined. Would it make sense to create a branch in the sugar-toolkit repository for the GTK widgets? For the activity, I could either host that on my own svn server, or put it into an OLPC repository. Pat -- Patrick Dubroy http://dubroy.com/blog - on programming, usability, and hci On Mon, Apr 7, 2008 at 4:10 PM, Eben Eliason [EMAIL PROTECTED] wrote: Hi Pat - I think that the technical solutions you've identified sound quite good, and make some nice improvements on my initial behavioral sketch as written up for the Paint activity. I'd definitely be interested in seeing any technical demos you have working, and also would like the chance to work with you on some graphical aspects of the widget and/or the experience (and hance, the API) for more complex use cases. - Eben On Mon, Apr 7, 2008 at 3:27 PM, Patrick Dubroy [EMAIL PROTECTED] wrote: (This was posted to olpc-devel a few weeks ago, but I just realized that it belongs more on this list) Hi, I'm working on a project to improve the PenTablet support. I have two main goals: 1. Build a GTK widget that an application developer could use to get tablet support for free. The widget would provide a 1-to-1 mapping between the physical tablet and the on-screen drawing area. For example, a penmanship application might have an area on-screen where a child could practice their writing. 2. For the more complicated case of freehand drawing in e.g. the Paint activity, my goal is to define the interface through which the user will be able to draw on an arbitrary area of the canvas. Of course, this is all pending proper driver support for the PenTablet. For now, I am prototyping these applications by reading directly from /dev/input/event5. I know that this has been discussed previously on the mailing list, but to my knowledge there's been no agreement on exactly how the UI will work for the PenTablet. I've created a page in the wiki (http://wiki.laptop.org/go/PenTablet_UI) that summarizes the previous suggestions that I am aware of. If you have any opinions on this, please take a look at let me know what you think. My personal feeling is that the best option is this: - the tablet is always mapped to a rectangle in the center of the screen. Using the grab button and the stylus, the canvas can be moved around underneath the rectangle (Option 1 for Adjusting the Mapping) - to allow for precise drawing, the user can engage a hover mode by holding down the Alt key while dragging the stylus (Option B for Precise Drawing) I have an application which demonstrates some of these techniques, which I could make available to anyone who is interested. I am also planning on doing a small, informal user study to test some of the techniques. Pat -- Patrick Dubroy http://dubroy.com/blog - on programming, usability, and hci ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] versions of bundles
Hi, from Update.2, we'll be able to manage several versions of the same bundle in Sugar. Until know, we only allowed having one bundle, and the user could only upgrade to later versions. Changes needed: - anywhere the shell displays a launchable bundle in the UI, launch that specific version (done, will send patch next), - the version of the bundle that produced a journal entry needs to be stored in the journal, - the presence service needs to send the bundle version of the shared activity. Right now, whenever we need to refer to a specific bundle but we lack a version number, we are choosing the latest installed version of that bundle. We should aim to always know which version we should launch/display. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Sugar toolkit: Identify bundles also by their version number.
From 705884f899440c20dc224a30ed3ef75ea9c7b9aa Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso [EMAIL PROTECTED]
Date: Sun, 6 Apr 2008 19:31:17 +0200
Subject: [PATCH] Identify bundles also by their version number.
---
sugar/activity/activityfactory.py | 33 ++---
sugar/activity/registry.py | 16
sugar/clipboard/clipboardservice.py | 19 +--
sugar/datastore/datastore.py| 24 +++-
4 files changed, 50 insertions(+), 42 deletions(-)
diff --git a/sugar/activity/activityfactory.py b/sugar/activity/activityfactory.py
index 1638197..7cb843a 100644
--- a/sugar/activity/activityfactory.py
+++ b/sugar/activity/activityfactory.py
@@ -163,10 +163,11 @@ class ActivityCreationHandler(gobject.GObject):
create call.
-def __init__(self, service_name, handle):
+def __init__(self, bundle_id, version, handle):
Initialise the handler
-service_name -- the service name of the bundle factory
+bundle_id -- id of the bundle to be started
+version -- version of the bundle to be started
activity_handle -- stores the values which are to
be passed to the service to uniquely identify
the activity to be created and the sharing
@@ -189,11 +190,12 @@ class ActivityCreationHandler(gobject.GObject):
gobject.GObject.__init__(self)
-self._service_name = service_name
+self._bundle_id = bundle_id
+self._version = version
self._handle = handle
self._use_rainbow = os.path.exists('/etc/olpc-security')
-if service_name in [ 'org.laptop.JournalActivity',
+if bundle_id in [ 'org.laptop.JournalActivity',
'org.laptop.Terminal',
'org.laptop.LogViewer',
'org.laptop.Analyze'
@@ -228,12 +230,13 @@ class ActivityCreationHandler(gobject.GObject):
self._handle.activity_id = create_activity_id()
self._shell.NotifyLaunch(
-self._service_name, self._handle.activity_id,
+self._bundle_id, self._handle.activity_id,
reply_handler=self._no_reply_handler,
error_handler=self._notify_launch_error_handler)
activity_registry = registry.get_registry()
-activity = activity_registry.get_activity(self._service_name)
+activity = activity_registry.get_activity(self._bundle_id,
+ self._version)
if activity:
environ = get_environment(activity)
(log_path, log_file) = open_log_file(activity)
@@ -279,11 +282,11 @@ class ActivityCreationHandler(gobject.GObject):
def _create_reply_handler(self):
logging.debug(Activity created %s (%s). %
-(self._handle.activity_id, self._service_name))
+(self._handle.activity_id, self._bundle_id))
def _create_error_handler(self, err):
logging.error(Couldn't create activity %s (%s): %s %
-(self._handle.activity_id, self._service_name, err))
+(self._handle.activity_id, self._bundle_id, err))
self._shell.NotifyLaunchFailure(
self._handle.activity_id, reply_handler=self._no_reply_handler,
error_handler=self._notify_launch_failure_error_handler)
@@ -299,18 +302,18 @@ class ActivityCreationHandler(gobject.GObject):
logging.error(Datastore find failed %s % err)
self._create_activity()
-def create(service_name, activity_handle=None):
-Create a new activity from its name.
+def create(bundle_id, version, activity_handle=None):
+Create a new activity from its bundle id.
if not activity_handle:
activity_handle = ActivityHandle()
-return ActivityCreationHandler(service_name, activity_handle)
+return ActivityCreationHandler(bundle_id, version, activity_handle)
-def create_with_uri(service_name, uri):
+def create_with_uri(bundle_id, version, uri):
Create a new activity and pass the uri as handle.
activity_handle = ActivityHandle(uri=uri)
-return ActivityCreationHandler(service_name, activity_handle)
+return ActivityCreationHandler(bundle_id, version, activity_handle)
-def create_with_object_id(service_name, object_id):
+def create_with_object_id(bundle_id, version, object_id):
Create a new activity and pass the object id as handle.
activity_handle = ActivityHandle(object_id=object_id)
-return ActivityCreationHandler(service_name, activity_handle)
+return ActivityCreationHandler(bundle_id, version, activity_handle)
diff --git a/sugar/activity/registry.py b/sugar/activity/registry.py
index e327cf0..f3a3129 100644
--- a/sugar/activity/registry.py
+++ b/sugar/activity/registry.py
@@ -72,8 +72,8 @@ class ActivityRegistry(gobject.GObject):
self._registry.connect_to_signal('ActivityRemoved
[sugar] [PATCH] Journal: Identify bundles also by their version number.
From 4ebc713e561b44eef33d9b0d527d9ef2b646a1b4 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso [EMAIL PROTECTED]
Date: Sun, 6 Apr 2008 19:31:24 +0200
Subject: [PATCH] Identify bundles also by their version number.
---
journaltoolbox.py |5 -
misc.py |6 --
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/journaltoolbox.py b/journaltoolbox.py
index 630d245..6bcc9c8 100644
--- a/journaltoolbox.py
+++ b/journaltoolbox.py
@@ -256,7 +256,10 @@ class SearchToolbar(gtk.Toolbar):
appended_separator = False
for service_name in datastore.get_unique_values('activity'):
-activity_info = activity.get_registry().get_activity(service_name)
+# TODO: Journal entries should also store the version of the
+# bundle that was used.
+registry = activity.get_registry()
+activity_info = registry.get_activity(service_name, -1)
if not activity_info is None:
if not appended_separator:
self._what_search_combo.append_separator()
diff --git a/misc.py b/misc.py
index 652930e..49a536c 100644
--- a/misc.py
+++ b/misc.py
@@ -65,8 +65,10 @@ def get_icon_name(jobject):
file_name = _get_icon_file_name('application-octet-stream')
if not file_name and jobject.metadata['activity']:
-service_name = jobject.metadata['activity']
-activity_info = activity.get_registry().get_activity(service_name)
+bundle_id = jobject.metadata['activity']
+# TODO: Journal entries should also store the version of the
+# bundle that was used.
+activity_info = activity.get_registry().get_activity(bundle_id, -1)
if activity_info:
file_name = activity_info.icon
--
1.5.2.5
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Choosing defaults for the activity ring
Ok, so the plan currently is for Sugar to keep shipping an activities.default with the same format as the existing one. The favorites file in the user profile will store the mtime and size of the activities.default file that merged by last time. At startup, the shell will check if it should merge a new one. Activity packs will still be able to customize this defaults file. Any comments? Thanks, Tomeu On Sat, Apr 5, 2008 at 8:22 AM, Eben Eliason [EMAIL PROTECTED] wrote: I'll toss in my thoughts, as I tried to introduce the problem as impartially as possible. I personally find the first option to be the simplest to implement, as well as the clearest conceptually. I, too, expect that such occurrences will be few, and find it unlikely that it would become a nuisance in those cases anyway. - Eben On Fri, Apr 4, 2008 at 8:17 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote I prefer option (1) because it's the behavior I would want as a user. With option (1), it's more obvious that new activity bundles have been installed. It's also more straightforward to implement. | Option (2) is somewhat more complex, but ensures that the user doesn't | have to repeatedly un-favorite activities which they don't want in | their ring. Where repeatedly means each time a Customization Stick is inserted. I do not imagine this happening more often than once a semester, i.e. very infrequently. It does not sound very inconvenient to me. Remember, this is the same frequency with which we anticipate that new OS releases will be installed. In fact, once we have automatic network activity updates, as recently discussed, I suspect that customization sticks will be used very little. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9sUxUJT6e6HFtqQRAoDTAJwLvas9mWk4DBz3U/82s3u/rE/xMQCfZX0o wCSPmarE//HK7RVRCAevjzQ= =UWRr -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs (or lack thereof)
What if on rollover would appear a normal palette with all the buttons that would be in the subtoolbar? This palette would have an option for pinning it, and that would mean inserting a subtoolbar between the toolbar and the canvas like in the mockups. Benefits: - palettes don't disturb the layout of the underlying window, - existing UI component, - buttons are grouped closer to the main button, requiring less mouse travel, - buttons are in an area not as thin, making easier to move the mouse without going out (thus hiding the palette), - we could keep the toolbar label. Thoughts? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Choosing defaults for the activity ring
On Sat, Apr 5, 2008 at 5:27 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Removing icons from the activity ring is just a matter of unstarring them in the list view - simple enough to do each semester. My vote is Option 1. Agreed. A much more interesting question is the __order__ in which to show the Activities: List view: Since there appears to be an intent to make the list searchable, there might be no need for alphabetization. What I think useful is to distinguish newly arrived Activities. My suggestion - as an Activity is installed for the first time (not replaced), insert its entry at the TOP of the list view. The 1825 list view appears all mixed up. Being a control freak, I would like to organize it myself. An ability to drag-n-drop the entries within the list would be handy. The activity list is planned to be sortable by name and install time (inverted?): http://wiki.laptop.org/go/Designs/Activity_Management#14 Ring view: One question - should it be easy for BB to sit down at AA's laptop? [This implies that 'Chat' (for example) should be at two o'clock on everyone's XO.] My opinion is to let every user put 'Chat' wherever he wants. Well, I think having the icons in different positions won't make difficult to share the laptops. As the position of the icons depends on the number of icons in the ring, I don't see how we could have fixed positions. Right now the icons are ordered in an arbitrary and unknown (to me) order. Maybe we would want to sort them alphabetically? or by install time (the date in the list)? But do let the user be able to control the order in which the icons are presented (this is an artifact now provided by the 650 file 'activities.defaults'). Adding reordering by dnd looks like quite a bit of work to me. Is it really needed? p.s. The drop-down menu from an icon can obscure the adjacent icon (should the user merely want to view the label of the current icon). Let me suggest positioning such a menu outside the circle. In my opinion we are a bit far from the moment when doing this refinements will make sense, but patches are welcome ;) Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Localization] code comments?
Very interesting, I guess we should integrate it in the language section of the control panel. AFAIK, this is not being considered yet. If we don't want to add more complexity to the control panel UI, we may assign under the hoods a fallback language to every language? Perhaps someone from deployment could comment on the better milestone to target this? Tomeu On Sat, Apr 5, 2008 at 6:47 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: Interesting, thanks. Are there any plans to make use of this feature in deployments? - Bert - On 05.04.2008, at 12:05, Khaled Hosny wrote: Yes, by setting LANGUAGE env variable with a fall back language, some thing like LANGUAGE=ur_PK:fa_IR:ar, you can specify multiple fall back languages. On Sat, Apr 05, 2008 at 09:31:30AM +0200, Bert Freudenberg wrote: ... which reminds me: Is it possible in gettext to fall back on a language other than English when a translation for some phrase cannot be found? That would be a useful feature I think, as long as there are programs that are not fully translated (which will happen very often). - Bert - ___ Localization mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/localization ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Olpc-open] [Grassroots-l] Update on XOs in Uruguay
Hi Bryan, thank you very much for your feedback. We're not getting yet from the field as much as we would want to, so I would like to have more details about your expereinces: On Fri, Apr 4, 2008 at 5:16 AM, Bryan Berry [EMAIL PROTECTED] wrote: Here are my top requirements based on 4 days of teacher training. They may change when we start the actual pilot on April 13th 1. Need graphical way to add and remove activities, something like Synaptic Package Manager on Ubuntu Clicking on a link in a web page is not good enough? What else is needed? 2. Need graphical way to change nickname and Jabber server. Those are two local values that I expect to change most frequently Yes, Simon has been working on the graphical control panel and that's expected to land in Update.2. We'd like to be able to give a preview in the following weeks. Less urgent: 1. We need awesome English games that are competitive. Just curious, what do you mean by competitive? And you mean educational games for learning English? 2. we need to make it easier to archive and share pictures. We had trouble sharing pictures during the teacher training. Can you detail your troubles? Do you have any suggestion about how to improve on this? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
