Re: [Sugar-devel] [PATCH sugar-0.84] journal scan of external media

[James Cameron]

Revised patch that handles recursive symlinks by processing each
directory only once.  Directories are identified by inode and device.

diff --git a/src/jarabe/journal/model.py b/src/jarabe/journal/model.py
index 50e8dc1..0bb571c 100644
--- a/src/jarabe/journal/model.py
+++ b/src/jarabe/journal/model.py
@@ -1,4 +1,4 @@
-# Copyright (C) 2007-2008, One Laptop Per Child
+# Copyright (C) 2007-2010, One Laptop per Child
 #
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -16,10 +16,11 @@
 
 import logging
 import os
+import errno
 from datetime import datetime
 import time
 import shutil
-from stat import S_IFMT, S_IFDIR, S_IFREG
+from stat import S_IFLNK, S_IFMT, S_IFDIR, S_IFREG
 import traceback
 import re
 
@@ -258,7 +259,9 @@ class InplaceResultSet(BaseResultSet):
 BaseResultSet.__init__(self, query, cache_limit)
 self._mount_point = mount_point
 self._file_list = None
-self._pending_directories = 0
+self._pending_directories = []
+self._visited_directories = []
+self._pending_files = []
 self._stopped = False
 
 query_text = query.get('query', '')
@@ -283,7 +286,10 @@ class InplaceResultSet(BaseResultSet):
 
 def setup(self):
 self._file_list = []
-self._recurse_dir(self._mount_point)
+self._pending_directories = [self._mount_point]
+self._visited_directories = []
+self._pending_files = []
+gobject.idle_add(self._scan)
 
 def stop(self):
 self._stopped = True
@@ -317,51 +323,99 @@ class InplaceResultSet(BaseResultSet):
 
 return entries, total_count
 
-def _recurse_dir(self, dir_path):
+def _scan(self):
 if self._stopped:
-return
+return False
 
-for entry in os.listdir(dir_path):
+self.progress.send(self)
+
+if len(self._pending_files) > 0:
+return self._scan_a_file()
+
+if len(self._pending_directories) > 0:
+return self._scan_a_directory()
+
+self.setup_ready()
+self._visited_directories = []
+return False
+
+def _scan_a_file(self):
+full_path = self._pending_files.pop(0)
+
+try:
+stat = os.lstat(full_path)
+except OSError, e:
+if e.errno != errno.ENOENT:
+logging.exception(
+'Error reading metadata of file %r', full_path)
+return True
+
+if S_IFMT(stat.st_mode) == S_IFLNK:
+try:
+link = os.readlink(full_path)
+except OSError, e:
+logging.exception(
+'Error reading target of link %r', full_path)
+return True
+
+if link == '.':
+return True
+if link.startswith('/') and full_path.startswith(link):
+return True
+
+try:
+stat = os.stat(full_path)
+
+except OSError, e:
+if e.errno != errno.ENOENT:
+logging.exception(
+'Error reading metadata of linked file %r', full_path)
+return True
+
+if S_IFMT(stat.st_mode) == S_IFDIR:
+id_tuple = stat.st_ino, stat.st_dev
+if not id_tuple in self._visited_directories:
+self._visited_directories.append(id_tuple)
+self._pending_directories.append(full_path)
+return True
+
+if S_IFMT(stat.st_mode) != S_IFREG:
+return True
+
+if self._regex is not None and \
+not self._regex.match(full_path):
+return True
+
+if None not in [self._date_start, self._date_end] and \
+(stat.st_mtime < self._date_start or
+ stat.st_mtime > self._date_end):
+return True
+
+if self._mime_types:
+mime_type = gio.content_type_guess(filename=full_path)
+if mime_type not in self._mime_types:
+return True
+
+file_info = (full_path, stat, int(stat.st_mtime))
+self._file_list.append(file_info)
+
+return True
+
+def _scan_a_directory(self):
+dir_path = self._pending_directories.pop(0)
+
+try:
+entries = os.listdir(dir_path)
+except OSError, e:
+if e.errno not in [errno.EACCES, errno.ENOTDIR]:
+logging.exception('Error reading directory %r', dir_path)
+return True
+
+for entry in entries:
 if entry.startswith('.'):
 continue
-full_path = dir_path + '/' + entry
-try:
-stat = os.stat(full_path)
-if S_IFMT(stat.st_mode) == S_IFDIR:
-self._pending_directories += 1
-gobject.idle_add(lambda s=full_path: self._recurse_dir(s))
-
- 

Re: [Sugar-devel] [PATCH sugar-0.84] journal scan of external media

[James Cameron]

Thanks for the review.  Detailed response to Tomeu and Sascha's review
below, followed by revised patch.

On Wed, Sep 08, 2010 at 09:20:21AM +0200, Tomeu Vizoso wrote:
> FWIW, I think this should go in a single patch because it doesn't make
> sense to cherry-pick pieces of a single refactoring/rewrite.

Thanks.

> About the tabs change, the -w flag to git diff and blame can cope with
> it, but I think when someone finds tabs should just push that change
> inmediately. (Though I have grepped through master and have only found
> tabs in invites.py).

Sorry, I used tabify in emacs, so as to force the diff to show the
entire function as changed.  I had said I "replaced tabs with spaces",
but I should have said "replaced spaces with tabs".  This is only
because I don't know how to drive git diff well enough.

> > I think it needs to be split into smaller functions,
> 
> +1

Done.

On Wed, Sep 08, 2010 at 05:32:39PM +0200, Sascha Silbe wrote:
> Are you sure you used spaces? The patch looked strangely formatted in
> both my MUA and my editor.

Tabs, sorry.

> You can simplify this by using logging.exception:

Done.

> While we're at it, let's improve on the original code:
> 
> > +if self._regex is not None and \
> > +not self._regex.match(full_path):
> > +add_to_list = False
> 
> All following ifs should be elif to avoid further examining entries that
> get skipped anyway. Especially for the MIME type comparison it will make
> a huge difference as it scans the file content.

Done.  Rewritten as guards with premature return.

> > +if None not in [self._date_start, self._date_end] and \
> > +(stat.st_mtime < self._date_start or
> > + stat.st_mtime > self._date_end):
> > +add_to_list = False
> 
> How about either checking just self._date_start or splitting it up into
> two separate rules?

Don't understand, sorry.

> > +if self._mime_types:
> > +mime_type = gio.content_type_guess(filename=full_path)
> 
> We should use a single way to derive MIME types (sugar.mime) in our code
> to avoid using different MIME types in different parts of Sugar.

I don't understand sugar.mime enough to do that.

> Back to your code:
> Why not .pop(0)?

Because I didn't know about it.  Thanks.  Fixed.

> > +try:
> > +entries = os.listdir(dir_path)
> > +except OSError, e:
> > +if e.errno not in [errno.ENOENT, errno.EACCES,
> > +   errno.EPERM, errno.ENOTDIR]:
> > +logging.error('Error reading directory %r: %s' %
> > +  (dir_path, traceback.format_exc()))
> 
> logging.exception() again. Also should we really ignore ENOTDIR?
> I don't see any way we could trigger ENOTDIR. If a symlink is broken,
> we won't recognise it as a directory, even if it was meant to point to
> a directory.

ENOTDIR does happen and is reproducible.  The reason it happens is that
os.lstat reads a link, os.readlink follows it, and os.stat identifies
the result as a directory, it is added to the list, and then os.listdir
fails to list the directory.

The reproducible instance is /media/disk/dev/fd/24 ... since fd is a
symlink to /proc/self/fd ... (awesome isn't it?  One can insert a USB key
that will list the contents of any directory on the laptop, provided
access is allowed.)

On nine test filesystems of varying sizes, the following exceptions were
counted:

os.listdir
exception EACCES a total of 95 times
exception ENOTDIR a total of 5 times

os.lstat of an entry returned by os.listdir
exception ENOENT a total of 5 times
exception EIO a total of 7 times

os.stat of an entry that os.lstat showed was a link
exception ENOENT a total of 7935 times

os.readlink
never failed

> > +self._pending_files.append(dir_path + '/' + entry)
> 
> What's the memory footprint of the two lists?

Depends on the population of the filesystem.  I don't consider it
important.  The pending files list never grows larger than the largest
directory.  The pending directory list never grows larger than the total
number of directories.

On the test filesystem of 73k files, the pending directory list in raw
form is about 250k, and worst case whole path list from "find /mnt" is
4MB.

> > +self._pending_files.reverse()
> 
> Why? The order in which os.listdir() returns the entries is undefined
> anyway.

When one uses os.listdir and then reverses the order before going
through them, the resulting performance is low, since the files are
being accessed in reverse.  Because I didn't know about pop(0), I had to
use .reverse() to maintain ordering.


diff --git a/src/jarabe/journal/model.py b/src/jarabe/journal/model.py
index 50e8dc1..81363fb 100644
--- a/src/jarabe/journal/model.py
+++ b/src/jarabe/journal/model.py
@@ -16,10 +16,11 @@
 
 import logging
 import os
+import errno
 from datetime import datetime
 import time
 import shutil
-from stat import S_IFMT, S_IFDIR, S_IFR

Re: [Sugar-devel] #2295 UNSP: Sugar 0.88 [Dextrose] not reporting all favourite connections to NetworkManager at startup

[James Cameron]

On Wed, Sep 08, 2010 at 06:53:24PM +0200, Tomeu Vizoso wrote:
> You mentioned that NM is only considering one connection, but if you
> can check that Sugar returns alls of them in ListConnections, why is
> NM only taking one of them?

I agree.  I don't see evidence on Sugar side that only one connection is
being requested.

On Sugar 0.84 traced NewConnection, ListConnections and GetSettings
using logging, and the log shows:

1283991592.492549 ERROR root: NewConnection 
'/org/freedesktop/NetworkManagerSettings/0'
1283991592.499109 ERROR root: NewConnection 
'/org/freedesktop/NetworkManagerSettings/1'
1283991592.569510 ERROR root: ListConnections 
[, 
] 
1283991592.574368 ERROR root: GetSettings 
'/org/freedesktop/NetworkManagerSettings/0'
1283991592.597896 ERROR root: GetSettings 
'/org/freedesktop/NetworkManagerSettings/1'
1283991592.615200 ERROR root: GetSettings 
'/org/freedesktop/NetworkManagerSettings/1'
1283991592.620522 ERROR root: GetSettings 
'/org/freedesktop/NetworkManagerSettings/0'

The above was on build os852, with only one connections.cfg entry, with
no mesh or ad-hoc support enabled.  There is only one access point
powered on, and I'm 10km from the next nearest.

I don't understand why there are two NewConnection signals.  I think the
extra NewConnection signal might have to do with the GSM support.  If I
discard network history, so that there is no connection for wireless,
what the trace shows is:

1283991817.029766 ERROR root: NewConnection 
'/org/freedesktop/NetworkManagerSettings/0'
1283991817.101088 ERROR root: ListConnections 
[]
1283991817.104933 ERROR root: GetSettings 
'/org/freedesktop/NetworkManagerSettings/0'
1283991817.122063 ERROR root: GetSettings 
'/org/freedesktop/NetworkManagerSettings/0'

Still, it is odd that NetworkManager calls GetSettings method twice, and
NetworkManager calls ListConnections only once *after* Sugar has
provided the two NewConnection signals.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Members shown in Journal for shared activity

[James Cameron]

On Wed, Sep 08, 2010 at 11:15:02AM +0200, Simon Schampijer wrote:
> I would believe that the list of members should be constructed of all 
> the buddies that were in the activity and not of the ones that were in 
> the activity the moment you leave it.
> 
> What do others think?

I used a shared Write activity in a teacher training practical
assignment last year, the members noticed this behaviour, and I had
a hard time explaining it.  The suggestion then was also that the
members should be retained in the journal no matter when they were
members.

So +1.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Display changed to 'Sugar in a window' instead of 'Xephyr on' Ticket #2285

[James Cameron]

On Wed, Sep 08, 2010 at 10:18:06PM +0530, Ishan Bansal wrote:
> Changed title displayed in the title bar of the sugar-emulator
> (SL#2285)

Reviewed-by: James Cameron 

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Code review (was: Re: [PATCH] Added Protected-Activities-Support to sugar (SL#2087))

[Daniel Drake]

On 8 September 2010 14:44, Sascha Silbe
 wrote:
> If there's consensus that we want to stay with the method first chosen
> by the submitter, then I'll refrain from doing that in the future and
> will concentrate on patches submitted on the mailing list.

I think that's the safest bet, and will certainly avoid problems like this.

Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Code review (was: Re: [PATCH] Added Protected-Activities-Support to sugar (SL#2087))

[Sascha Silbe]

Excerpts from Daniel Drake's message of Wed Sep 08 21:34:33 +0200 2010:

> Where a review process has started on trac, please keep the patch
> reviews on trac.

That's probably my fault, I've been referring people from Trac to the
mailing list for review. My assumption was that they're simply not
aware of the recent "experimental" changes to the Code Review Process
(that are not reflected on the corresponding wiki page, only on the
talk page), but would have liked to benefit from the new, streamlined
process.

If there's consensus that we want to stay with the method first chosen
by the submitter, then I'll refrain from doing that in the future and
will concentrate on patches submitted on the mailing list.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Added Protected-Activities-Support to sugar (SL#2087)

[Daniel Drake]

On 8 September 2010 11:13, Kandarp Kaushik  wrote:
> This patch provides a mechanism that uses a gconf value to determine
> which activities will not contain the erase option at the list view
> palette. The gconf value contains a list of activities bundle indentifiers.

Your efforts to help move tickets along are appreciated but you are
adding disruption to the process.

Where a review process has started on trac, please keep the patch
reviews on trac.
(sending an email with a link to the ticket, requesting on-trac review
is of course acceptable and a good idea where review has stalled)

In this case we have multiple people working on the same bug with
different versions of the same patch being submitted in 2 different
places on the same day.

You have also erased authorship information which is not a very nice
gesture to the original developer.

To reviewers: my suggestion is to ignore the patch in this thread,
review the latest version of the patch on trac:
http://bugs.sugarlabs.org/ticket/2087
The one on trac incorporates feedback from the design team, is a tiny
bit cleaner, and retains correct authorship information.

Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Update the versions of our telepathy dependencies and add mission control #2228

[Sascha Silbe]

Excerpts from David Farning's message of Wed Sep 08 19:58:53 +0200 2010:

> This now requires libtelepathy-glib-dev as a dependency for ubuntu 10.10.

AFAICT Maverick doesn't have recent enough Telepathy packages, so we
need to build it from source. If we build it from source, we need to
build all of it from source, including telepathy-glib. So there
shouldn't be a need to install libtelepathy-glib-dev.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Added Protected-Activities-Support to sugar (SL#2087)

[Sascha Silbe]

Excerpts from Kandarp Kaushik's message of Wed Sep 08 19:13:38 +0200 2010:

> This patch provides a mechanism that uses a gconf value to determine
> which activities will not contain the erase option at the list view
> palette. The gconf value contains a list of activities bundle indentifiers.

s/at the list view palette/in the Home View/

The Home View might support additional layouts in the future that show
the erase option as well.

[data/sugar.schemas.in]
> +Users will not be allowed to erase these
> +activities through the list view.

Dito.

[src/jarabe/desktop/activitieslist.py]
> +self._add_erase_option( registry, activity_info )

Please remove the extra spaces after / before parentheses. pylint would
have told you this.

> +if not activity_info.is_user_activity():
> +return
> +if registry.is_activity_protected(self._bundle_id):
> +return

A newline at this point (i.e. after the last guard) would improve
readability IMO.

[src/jarabe/model/bundleregistry.py]
> +try:
> +self._protected_activities = 
> client.get_list('/desktop/sugar/protected_activities',

Line too long (80 chars is the limit). Just put the string literal on the
next line, indented by four additional spaces. If it fits, merge in the
remaining part.

> +gconf.VALUE_STRING)
> +except Exception:
> +self._protected_activities = []

Please only catch specific exceptions, otherwise you might hide some
failures / bugs.

Have we reached consensus on the design, BTW? The patch still hides
the erase option instead of deactivating it.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Update the versions of our telepathy dependencies and add mission control #2228

[David Farning]

On Tue, Sep 7, 2010 at 12:42 PM, Tomeu Vizoso
 wrote:
> On Tue, Sep 7, 2010 at 19:39, Tomeu Vizoso  
> wrote:
>> Signed-off-by: Tomeu Vizoso 
>
> This has been tested only in Fedora 13, further testing appreciated.
>
> Will be sending a patch for adding specific Fedora versions after this lands.

This now requires libtelepathy-glib-dev as a dependency for ubuntu 10.10.

thanks

> Thanks,
>
> Tomeu
>
>> ---
>>  config/modulesets/glucose-external.modules |   35 
>> ++-
>>  config/modulesets/glucose.modules          |    1 +
>>  config/sysdeps/50debian-unstable.xml       |    4 ---
>>  config/sysdeps/50ubuntu-10.04.xml          |    4 ---
>>  config/sysdeps/debian-family.xml           |    3 ++
>>  config/sysdeps/fedora-family.xml           |    7 ++---
>>  sjhbuild/config.py                         |    1 +
>>  7 files changed, 31 insertions(+), 24 deletions(-)
>>
>> diff --git a/config/modulesets/glucose-external.modules 
>> b/config/modulesets/glucose-external.modules
>> index 0577963..9d50db0 100644
>> --- a/config/modulesets/glucose-external.modules
>> +++ b/config/modulesets/glucose-external.modules
>> @@ -84,9 +84,9 @@
>>   >              autogen-sh="configure">
>>     > -            version="0.8.9"
>> -            module="telepathy-gabble/telepathy-gabble-0.8.9.tar.gz"
>> -            size="1493009" md5sum="ddf89b1eea2f418a68b1013427eb0cb1">
>> +            version="0.9.16"
>> +            module="telepathy-gabble/telepathy-gabble-0.9.16.tar.gz"
>> +            size="2900705" md5sum="7f2ab9256a6202f717bffaf341c99f75">
>>     
>>     
>>       
>> @@ -111,9 +111,9 @@
>>   >              autogen-sh="configure" autogenargs="--enable-olpc --enable-ssl">
>>     > -            version="0.3.10"
>> -            module="telepathy-salut/telepathy-salut-0.3.10.tar.gz"
>> -            size="1190762" md5sum="145580837ba7727f7c97bcfbd1b4a71f">
>> +            version="0.3.13"
>> +            module="telepathy-salut/telepathy-salut-0.3.13.tar.gz"
>> +            size="1209052" md5sum="173448d2680026c5e311f7c97cdda327">
>>     
>>     
>>       
>> @@ -121,22 +121,33 @@
>>     
>>   
>>   
>> -    > -            module="telepathy-glib/telepathy-glib-0.9.2.tar.gz"
>> -            size="2548558" md5sum="83be89144539472eac4ee4a4487f68c4" />
>> +    > +            module="telepathy-glib/telepathy-glib-0.11.11.tar.gz"
>> +            size="2431238" md5sum="ff78ff73851841b47582d5cf99dd5a34" />
>>     
>>       
>>     
>>   
>>   
>> -    > -            repo="telepathy" version="0.15.14"
>> -            size="306178" md5sum="058b929055710410f420989c20d5e981"/>
>> +    > +            repo="telepathy" version="0.15.18"
>> +            size="356285" md5sum="51da78a77681b0652d9b4ca941da0658"/>
>>   
>>   
>>     > href="http://download.gnome.org/sources/evince/2.25/evince-2.25.92.tar.bz2";
>>             version="2.25.92" size="1842261" 
>> md5sum="5e0d0fc2d900856074b556e4eacc68e6"/>
>>   
>> +  > +             autogen-sh="configure">
>> +    > +            version="5.5.3"
>> +            
>> module="telepathy-mission-control/telepathy-mission-control-5.5.3.tar.gz"
>> +            size="1245954" md5sum="117528e399d190f66c176e37aefb85d6">
>> +    
>> +    
>> +      
>> +    
>> +  
>>   
>>     > href="http://download.gnome.org/sources/gnome-python-desktop/2.25/gnome-python-desktop-2.25.90.tar.bz2";
>>             version="2.25.90" size="571621" 
>> md5sum="9bc794079fb4dd02f4d0651ff04bbace"/>
>> diff --git a/config/modulesets/glucose.modules 
>> b/config/modulesets/glucose.modules
>> index 2a9a8ce..ac9e237 100644
>> --- a/config/modulesets/glucose.modules
>> +++ b/config/modulesets/glucose.modules
>> @@ -35,6 +35,7 @@
>>       
>>       
>>       
>> +      
>>     
>>   
>>   
>> diff --git a/config/sysdeps/50debian-unstable.xml 
>> b/config/sysdeps/50debian-unstable.xml
>> index e04de63..ffa8f0c 100644
>> --- a/config/sysdeps/50debian-unstable.xml
>> +++ b/config/sysdeps/50debian-unstable.xml
>> @@ -4,7 +4,6 @@
>>   
>>   
>>   
>> -  
>>   
>>   
>>   
>> @@ -13,12 +12,9 @@
>>   
>>  
>>   
>> -  
>>   
>>   
>>   
>> -  
>> -  
>>   
>>   
>>   
>> diff --git a/config/sysdeps/50ubuntu-10.04.xml 
>> b/config/sysdeps/50ubuntu-10.04.xml
>> index 89efc0d..7ac6839 100644
>> --- a/config/sysdeps/50ubuntu-10.04.xml
>> +++ b/config/sysdeps/50ubuntu-10.04.xml
>> @@ -4,7 +4,6 @@
>>   
>>   
>>   
>> -  
>>   
>>   
>>   
>> @@ -13,10 +12,7 @@
>>   
>>  
>>   
>> -  
>>   
>>   
>> -  
>> -  
>>   
>>  
>> diff --git a/config/sysdeps/debian-family.xml 
>> b/config/sysdeps/debian-family.xml
>> index d7c1354..6b03287 100644
>> --- a/config/sysdeps/debian-family.xml
>> +++ b/config/sysdeps/debian-family.xml
>> @@ -39,9 +39,11 @@
>>   
>>   
>>   
>> +  
>>   
>>   
>>   
>> +  
>>   
>>   
>>   
>> @@ -75,6 +77,7 @@
>>   
>>   
>>   
>> +  
>>   
>>   
>>   
>> diff --git a/config/sysdeps/fedora-family.xml 
>> b/config/sysdeps/fedora-family.xml
>> index 35ee6c0..d5a64db 100644
>> --- a/config/sysdeps/fedora-famil

[Sugar-devel] [PATCH] Added Protected-Activities-Support to sugar (SL#2087)

[Kandarp Kaushik]

This patch provides a mechanism that uses a gconf value to determine
which activities will not contain the erase option at the list view
palette. The gconf value contains a list of activities bundle indentifiers.
---
 data/sugar.schemas.in|   14 ++
 src/jarabe/desktop/activitieslist.py |   24 +++-
 src/jarabe/model/bundleregistry.py   |   11 +++
 3 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/data/sugar.schemas.in b/data/sugar.schemas.in
index 2e6b820..cfa7edf 100644
--- a/data/sugar.schemas.in
+++ b/data/sugar.schemas.in
@@ -343,5 +343,19 @@
   
 
 
+
+  /schemas/desktop/sugar/protected_activities
+  /desktop/sugar/protected_activities
+  sugar
+  list
+  string
+  []
+  
+Bundle IDs of protected activities
+Users will not be allowed to erase these
+activities through the list view.
+  
+
+
   
 
diff --git a/src/jarabe/desktop/activitieslist.py 
b/src/jarabe/desktop/activitieslist.py
index c14d31e..f2ce7cb 100644
--- a/src/jarabe/desktop/activitieslist.py
+++ b/src/jarabe/desktop/activitieslist.py
@@ -400,22 +400,28 @@ class ActivityListPalette(ActivityPalette):
 self.menu.append(self._favorite_item)
 self._favorite_item.show()
 
-if activity_info.is_user_activity():
-menu_item = MenuItem(_('Erase'), 'list-remove')
-menu_item.connect('activate', self.__erase_activate_cb)
-self.menu.append(menu_item)
-menu_item.show()
+self._add_erase_option( registry, activity_info )
 
-if not os.access(activity_info.get_path(), os.W_OK):
-menu_item.props.sensitive = False
-
-registry = bundleregistry.get_registry()
 self._activity_changed_sid = registry.connect('bundle_changed',
 self.__activity_changed_cb)
 self._update_favorite_item()
 
 self.connect('destroy', self.__destroy_cb)
 
+def _add_erase_option(self, registry, activity_info):
+"""Add Erase option to the GUI for user activities."""
+if not activity_info.is_user_activity():
+return
+if registry.is_activity_protected(self._bundle_id):
+return
+menu_item = MenuItem(_('Erase'), 'list-remove')
+menu_item.connect('activate', self.__erase_activate_cb)
+self.menu.append(menu_item)
+menu_item.show()
+
+if not os.access(activity_info.get_path(), os.W_OK):
+menu_item.props.sensitive = False
+
 def __destroy_cb(self, palette):
 self.disconnect(self._activity_changed_sid)
 
diff --git a/src/jarabe/model/bundleregistry.py 
b/src/jarabe/model/bundleregistry.py
index b96de86..3e6b97a 100644
--- a/src/jarabe/model/bundleregistry.py
+++ b/src/jarabe/model/bundleregistry.py
@@ -19,6 +19,7 @@ import os
 import logging
 import traceback
 
+import gconf
 import gobject
 import gio
 import simplejson
@@ -66,6 +67,13 @@ class BundleRegistry(gobject.GObject):
 self._last_defaults_mtime = -1
 self._favorite_bundles = {}
 
+client = gconf.client_get_default()
+try:
+self._protected_activities = 
client.get_list('/desktop/sugar/protected_activities',
+gconf.VALUE_STRING)
+except Exception:
+self._protected_activities = []
+
 try:
 self._load_favorites()
 except Exception:
@@ -312,6 +320,9 @@ class BundleRegistry(gobject.GObject):
 key = self._get_favorite_key(bundle_id, version)
 return key in self._favorite_bundles
 
+def is_activity_protected(self, bundle_id):
+return bundle_id in self._protected_activities
+
 def set_bundle_position(self, bundle_id, version, x, y):
 key = self._get_favorite_key(bundle_id, version)
 if key not in self._favorite_bundles:
-- 
1.7.1

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Display 'Sugar in a window' instead of 'Xephyr on'. Ticket #2285

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Wed Sep 08 17:19:00 +0200 2010:

> On Wed, Sep 8, 2010 at 17:00, Ishan Bansal  wrote:
> > Changed title displayed in the title bar of the sugar-emulator.
> 
> Please mention the number of the ticket that this fixes.

It's in the subject already and IMO that's enough. (I suppose you just
overlooked it, but wanted to make clear to Ishan that it's fine as-is).

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Time out on registration process to prevent indefinite UI hang (SL#2289)

[Sascha Silbe]

Excerpts from Dipankar Patro's message of Wed Sep 08 16:48:46 +0200 2010:

> -server = ServerProxy(url)
> +server = xmlrpclib.ServerProxy(url)

Have you tried this patch? TimeoutTransport isn't used anywhere.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] #2295 UNSP: Sugar 0.88 [Dextrose] not reporting all favourite connections to NetworkManager at startup

[Tomeu Vizoso]

On Wed, Sep 8, 2010 at 18:34, Franco Miceli  wrote:
> Tomeu,
>
> Following code traces of ListConnections from the NMSettings class within
> Network.py, I've come across the following sequence of calls from NM's code:
>
> NetworkManager.c's main function calls nm-manager-get (from nm-manager.c).
>
> Within nm-mannager-get the function initial_get_connections gets called. I
> think it is this the function we are looking for since it invokes other
> functions (query_connections and poke_system_settings_daemon_cb) that call
> the ListConnections through the d-bus (dbus_gproxy_begin_call()).
>
> So effectively I think that ListConnections is the one NM calls at startup.

You mentioned that NM is only considering one connection, but if you
can check that Sugar returns alls of them in ListConnections, why is
NM only taking one of them?

Regards,

Tomeu

> Hope I helped.
>
> Cheers
>
> 2010/9/8 Tomeu Vizoso 
>>
>> On Wed, Sep 8, 2010 at 13:42, Franco Miceli 
>> wrote:
>> > For what I've been able to see load_wifi_connections collects all wifi
>> > connections from /home/olpc/.sugar/default/nm/connections.cfg. This
>> > function
>> > gets called by load_connections who gets called by get_settings.
>> >
>> > I think that the class NMSettings is where sugar communicates this to
>> > NM,
>> > but I don't seem to find a "main loop" that I can follow in order to
>> > determine what happens when the process starts for the first time.
>> >
>> > Could it  be that this first "connection culling" is not provided by
>> > Sugar,
>> > but in fact by other entity?
>> >
>> > Sorry that I can't be of much help, but I'm very new to python and am
>> > still
>> > trying to understand some of the basics.
>> >
>> > Please tell me what I can do to help in solving this, since I've made
>> > changes in the autoconnection feature for the XO in NM, and in order to
>> > get
>> > the algorithms working well I need to get reliable data of the favourite
>> > connections. So I'm very interested in getting this solved.
>>
>> Hi Franco,
>>
>> I'm not familiar with this part of Sugar, but if you can check if this
>> is the method that NM calls at startup to retrieve the available
>> connections, we may get a step closer:
>>
>>
>> http://git.sugarlabs.org/projects/sugar/repos/nops/blobs/master/src/jarabe/model/network.py#line354
>>
>> Regards,
>>
>> Tomeu
>>
>> > Thanks for everything.
>> >
>> > Cheers
>> >
>> > 2010/9/8 Sugar Labs Bugs 
>> >>
>> >> #2295: Sugar 0.88 [Dextrose] not reporting all favourite connections to
>> >> NetworkManager at startup
>> >>
>> >>
>> >> --+-
>> >>    Reporter:  fmiceli                    |          Owner:  tomeu
>> >>        Type:  defect                     |         Status:  new
>> >>    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified
>> >> by
>> >> Release Team
>> >>   Component:  sugar                      |        Version:  0.88.x
>> >>    Severity:  Minor                      |       Keywords:
>> >> Distribution:  Dextrose                   |   Status_field:
>> >>  Unconfirmed
>> >>
>> >>
>> >> --+-
>> >>
>> >> Comment(by tomeu):
>> >>
>> >>  Hi Franco, have you found the place in Sugar that provides that single
>> >>  connection to NM?
>> >>
>> >> --
>> >> Ticket URL: 
>> >> Sugar Labs 
>> >> Sugar Labs bug tracking system
>> >
>> >
>> >
>> > --
>> > Ing. Franco Miceli
>> > CITS - Plan Ceibal - Investigación & Desarrollo
>> > Av. Italia 6201 - Montevideo, Uruguay
>> > CP: 11500
>> > Tel: (598 2) 601 5773 int.: 2227
>> >
>> > ___
>> > Sugar-devel mailing list
>> > Sugar-devel@lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>> >
>> >
>
>
>
> --
> Ing. Franco Miceli
> CITS - Plan Ceibal - Investigación & Desarrollo
> Av. Italia 6201 - Montevideo, Uruguay
> CP: 11500
> Tel: (598 2) 601 5773 int.: 2227
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Display changed to 'Sugar in a window' instead of 'Xephyr on' Ticket #2285

[Ishan Bansal]

Changed title displayed in the title bar of the sugar-emulator (SL#2285)
---
 src/jarabe/util/emulator.py |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/jarabe/util/emulator.py b/src/jarabe/util/emulator.py
index 5a99dbe..e956669 100644
--- a/src/jarabe/util/emulator.py
+++ b/src/jarabe/util/emulator.py
@@ -20,6 +20,7 @@ import subprocess
 import sys
 import time
 from optparse import OptionParser
+from gettext import gettext as _
 
 import gtk
 import gobject
@@ -36,6 +37,7 @@ def _run_xephyr(display, dpi, dimensions, fullscreen):
 cmd = [ 'Xephyr' ]
 cmd.append(':%d' % display)
 cmd.append('-ac') 
+cmd += ['-title', _('Sugar in a window')]
 
 screen_size = (gtk.gdk.screen_width(), gtk.gdk.screen_height())
 
-- 
1.7.0.4

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Update the versions of our telepathy dependencies and add mission control #2228

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Wed Sep 08 18:01:33 +0200 2010:

> I can make a release myself, will post an update then.

BTW, if/when you're (physically) meeting with the Collabora folks it
would be nice to do some PGP key signing. I couldn't verify one of the
components because the key lacked any signature at all. Same with your
key (though it didn't sign any release yet ;) ).
 
(Sending this on-list because it's a reminder to others to sign keys
whenever they meet someone physically, especially abroad).

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] #2295 UNSP: Sugar 0.88 [Dextrose] not reporting all favourite connections to NetworkManager at startup

[Franco Miceli]

Tomeu,

Following code traces of ListConnections from the NMSettings class within
Network.py, I've come across the following sequence of calls from NM's code:

NetworkManager.c's main function calls nm-manager-get (from nm-manager.c).

Within nm-mannager-get the function initial_get_connections gets called. I
think it is this the function we are looking for since it invokes other
functions (query_connections and poke_system_settings_daemon_cb) that call
the ListConnections through the d-bus (dbus_gproxy_begin_call()).

So effectively I think that ListConnections is the one NM calls at startup.

Hope I helped.

Cheers

2010/9/8 Tomeu Vizoso 

> On Wed, Sep 8, 2010 at 13:42, Franco Miceli 
> wrote:
> > For what I've been able to see load_wifi_connections collects all wifi
> > connections from /home/olpc/.sugar/default/nm/connections.cfg. This
> function
> > gets called by load_connections who gets called by get_settings.
> >
> > I think that the class NMSettings is where sugar communicates this to NM,
> > but I don't seem to find a "main loop" that I can follow in order to
> > determine what happens when the process starts for the first time.
> >
> > Could it  be that this first "connection culling" is not provided by
> Sugar,
> > but in fact by other entity?
> >
> > Sorry that I can't be of much help, but I'm very new to python and am
> still
> > trying to understand some of the basics.
> >
> > Please tell me what I can do to help in solving this, since I've made
> > changes in the autoconnection feature for the XO in NM, and in order to
> get
> > the algorithms working well I need to get reliable data of the favourite
> > connections. So I'm very interested in getting this solved.
>
> Hi Franco,
>
> I'm not familiar with this part of Sugar, but if you can check if this
> is the method that NM calls at startup to retrieve the available
> connections, we may get a step closer:
>
>
> http://git.sugarlabs.org/projects/sugar/repos/nops/blobs/master/src/jarabe/model/network.py#line354
>
> Regards,
>
> Tomeu
>
> > Thanks for everything.
> >
> > Cheers
> >
> > 2010/9/8 Sugar Labs Bugs 
> >>
> >> #2295: Sugar 0.88 [Dextrose] not reporting all favourite connections to
> >> NetworkManager at startup
> >>
> >>
> --+-
> >>Reporter:  fmiceli|  Owner:  tomeu
> >>Type:  defect | Status:  new
> >>Priority:  Unspecified by Maintainer  |  Milestone:  Unspecified
> by
> >> Release Team
> >>   Component:  sugar  |Version:  0.88.x
> >>Severity:  Minor  |   Keywords:
> >> Distribution:  Dextrose   |   Status_field:  Unconfirmed
> >>
> >>
> --+-
> >>
> >> Comment(by tomeu):
> >>
> >>  Hi Franco, have you found the place in Sugar that provides that single
> >>  connection to NM?
> >>
> >> --
> >> Ticket URL: 
> >> Sugar Labs 
> >> Sugar Labs bug tracking system
> >
> >
> >
> > --
> > Ing. Franco Miceli
> > CITS - Plan Ceibal - Investigación & Desarrollo
> > Av. Italia 6201 - Montevideo, Uruguay
> > CP: 11500
> > Tel: (598 2) 601 5773 int.: 2227
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>



-- 
Ing. Franco Miceli
CITS - Plan Ceibal - Investigación & Desarrollo
Av. Italia 6201 - Montevideo, Uruguay
CP: 11500
Tel: (598 2) 601 5773 int.: 2227
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Update the versions of our telepathy dependencies and add mission control #2228

[Tomeu Vizoso]

On Wed, Sep 8, 2010 at 17:57, Sascha Silbe
 wrote:
> Excerpts from Tomeu Vizoso's message of Wed Sep 08 10:45:09 +0200 2010:
>
>> > BTW, there seem to have been releases in the meantime (e.g.
>> > telepathy-gabble 0.9.17). Should we update to these right away?
>>
>> Should be safe to update, right now I'm only waiting for a new release
>> of mission-control with this one fixed:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=28915
>
> Updated again. Please ping me once the fix is in a release (or once it
> has been committed and a release isn't going to happen soon).

I can make a release myself, will post an update then.

Thanks,

Tomeu

>> Thanks, anything else you need from me to push this?
>
> Nop, done now. Even if we borked up it can't be worse than before. :-P
>
> Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Update the versions of our telepathy dependencies and add mission control #2228

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Wed Sep 08 10:45:09 +0200 2010:

> > BTW, there seem to have been releases in the meantime (e.g.
> > telepathy-gabble 0.9.17). Should we update to these right away?
> 
> Should be safe to update, right now I'm only waiting for a new release
> of mission-control with this one fixed:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=28915

Updated again. Please ping me once the fix is in a release (or once it
has been committed and a release isn't going to happen soon).

> Thanks, anything else you need from me to push this?

Nop, done now. Even if we borked up it can't be worse than before. :-P

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] palette timeouts (was Re: #1169 NORM: Drop down menus give no indication of their existence, also are too slow to load.)

[Gary Martin]

Hi Tomeu,

On 8 Sep 2010, at 10:30, Tomeu Vizoso  wrote:

> Hi,
> 
> looks like Seeta is interested in doing something about this.
> 
> Do we have any kind of agreement on what changes should be done?

From that ticket there seems to be agreement on making a left click immediately 
raise a palette where there is no other primary action. Should I start filing 
enhancement request tickets for each case I can find? Example: For the owners 
buddy icon, in all cases, a single left click should open the 'Shutdown, 
Logout, My settings, Register' palette.

Regarding the secondary palette timing, a delay is there for several sane 
reasons:

  - hiding advanced and infrequently used features one level down to reduce UI 
complexity**
  - delaying the palettes from obscuring other parts of the UI a user may be 
trying to get to  

** we must be open to sorting out cases where we have the priority wrong, the 
home view activity resume vs. start new is a clear example that needs resolving 
(e.g. resume and start new need to be given equal UI priority).

How long the delay should be is not so obvious. 

Also be aware of future touch input, where a single tap would be equivalent of 
a left click, and a tap with hold would raise the palette, FWIW there is no 
good right click in a touch world —some folks are using two and three fingered 
touches but these are pretty obscure and unnatural to use, especially for small 
button sized targets; might be OK for something like raising/lowering the frame 
when allowed anywhere on the touch surface.

Regards,
--Gary  

> Thanks,
> 
> Tomeu
> 
> On Tue, May 4, 2010 at 06:51, Sugar Labs Bugs
>  wrote:
>> #1169: Drop down menus give no indication of their existence, also are too 
>> slow to
>> load.
>> -+--
>>Reporter:  wwdillingham  |  Owner:  tomeu
>>Type:  enhancement   | Status:  new
>>Priority:  Normal|  Milestone:  0.90
>>   Component:  sugar |Version:  Unspecified
>>Severity:  Critical  |   Keywords:  interface design usability 
>> sugar-love GPA
>> Distribution:  Unspecified   |   Status_field:  Needinfo
>> -+--
>> 
>> Comment(by FGrose):
>> 
>>  In my estimation, reducing the hover-delay-time-before-palette-showing by
>>  50 to 70 % would make the palettes more discoverable.  Pop-up help and
>>  previews on the web seem to pop up pretty quickly these days.
>> 
>>  This would be an easier mitigation to implement and would help on action
>>  buttons with palette menus as well.
>> 
>>  I like the left click reveal, where possible, as well.
>> 
>> --
>> Ticket URL: 
>> Sugar Labs 
>> Sugar Labs bug tracking system
>> 
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar-0.84] journal scan of external media

[Sascha Silbe]

Excerpts from James Cameron's message of Wed Sep 08 09:00:31 +0200 2010:

> I've reworked it to be as asynchronous as I can make it without moving
> into a separate thread or process.

Nice!

> The patch below is a rewrite of the function _recurse_dir, and I've
> replaced tabs with spaces only because the indenting changes make the
> patch hard to read otherwise.

Are you sure you used spaces? The patch looked strangely formatted in
both my MUA and my editor.

> I'm not asking for the patch to be accepted as is, I presume I'd be
> asked to break it down into ten different patches so that each change
> is explained in a different way to how my thought processes proceeded.



> I think it needs to be split into smaller functions, and it doesn't
> address the issue of relative recursive links.

OK.

> +def _recurse_dir(self):
> +if self._stopped:
> +return False
> +
> +except OSError, e:
> +if e.errno not in [errno.ENOENT, errno.EPERM]:
> +logging.error('Error reading metadata of file %r: %s' %
> +  (full_path, traceback.format_exc()))

You can simplify this by using logging.exception:

   logging.exception('Error reading metadata of file %r',
   full_path)

While we're at it, let's improve on the original code:

> +if self._regex is not None and \
> +not self._regex.match(full_path):
> +add_to_list = False

All following ifs should be elif to avoid further examining entries that
get skipped anyway. Especially for the MIME type comparison it will make
a huge difference as it scans the file content.

> +if None not in [self._date_start, self._date_end] and \
> +(stat.st_mtime < self._date_start or
> + stat.st_mtime > self._date_end):
> +add_to_list = False

How about either checking just self._date_start or splitting it up into
two separate rules?

> +if self._mime_types:
> +mime_type = gio.content_type_guess(filename=full_path)

We should use a single way to derive MIME types (sugar.mime) in our code
to avoid using different MIME types in different parts of Sugar.

Back to your code:

> +if len(self._pending_directories) > 0:
> +dir_path = self._pending_directories[0]
> +self._pending_directories.remove(dir_path)

Why not .pop(0)?

> +try:
> +entries = os.listdir(dir_path)
> +except OSError, e:
> +if e.errno not in [errno.ENOENT, errno.EACCES,
> +   errno.EPERM, errno.ENOTDIR]:
> +logging.error('Error reading directory %r: %s' %
> +  (dir_path, traceback.format_exc()))

logging.exception() again. Also should we really ignore ENOTDIR?
I don't see any way we could trigger ENOTDIR. If a symlink is broken,
we won't recognise it as a directory, even if it was meant to point to
a directory.

> +self._pending_files.append(dir_path + '/' + entry)

What's the memory footprint of the two lists? I'm wondering whether it
might make sense to store only the relative path in self._pending_files
and construct the full path for each individual file. Would need to
either save the name of the current directory in an additional attribute
or adjust the code to remove the directory only after it was processed.

> +self._pending_files.reverse()

Why? The order in which os.listdir() returns the entries is undefined
anyway.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Display 'Sugar in a window' instead of 'Xephyr on'. Ticket #2285

[Tomeu Vizoso]

On Wed, Sep 8, 2010 at 17:00, Ishan Bansal  wrote:
> Changed title displayed in the title bar of the sugar-emulator.

Please mention the number of the ticket that this fixes. As Sascha
said before, the commit message would be more useful if you mention to
which string you are changing to.

> ---
>  src/jarabe/util/emulator.py |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/src/jarabe/util/emulator.py b/src/jarabe/util/emulator.py
> index 5a99dbe..07f1569 100644
> --- a/src/jarabe/util/emulator.py
> +++ b/src/jarabe/util/emulator.py
> @@ -20,6 +20,7 @@ import subprocess
>  import sys
>  import time
>  from optparse import OptionParser
> +from gettext import gettext as _
>
>  import gtk
>  import gobject
> @@ -36,7 +37,8 @@ def _run_xephyr(display, dpi, dimensions, fullscreen):
>     cmd = [ 'Xephyr' ]
>     cmd.append(':%d' % display)
>     cmd.append('-ac')
> -
> +    cmd += ['-title',_('Sugar in a window')]

Should be a space after the comma.

> +

You are adding unneeded whitespace here.

This is almost ready to go in.

Regards,

Tomeu

>     screen_size = (gtk.gdk.screen_width(), gtk.gdk.screen_height())
>
>     if (not dimensions) and (fullscreen is None) and \
> --
> 1.7.0.4
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Members shown in Journal for shared activity

[Gary Martin]

Hi Simon,

On 8 Sep 2010, at 10:15, Simon Schampijer  wrote:

> Hi,
> 
> the following is true on 0.84 (untested so far on master, reports welcome):
> 
> Machine A: Share an activity
> Machine B: Join
> Machine C: Join
> Machine C: leaves -> Buddy A and B listed as members in Journal entry on 
> machine C
> Machine B: leaves -> Buddy A listed as member in Journal entry on machine B
> Machine A: closes -> No Buddy listed as a member of the Journal entry on 
> machine A
> 
> I would believe that the list of members should be constructed of all 
> the buddies that were in the activity and not of the ones that were in 
> the activity the moment you leave it.
> 
> What do others think?

+1, that makes more sense, if it's possible... What would be the behaviour when 
this activity is later resumed by one of the original participants (the others 
are not present), and machine D joins? Does D see the full past membership as 
ABCD? Is the view of past participants grown through direct observation, or is 
the list of participants shared along with other metadata?

Regards,
--Gary

> Regards,
>Simon
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Display 'Sugar in a window' instead of 'Xephyr on'. Ticket #2285

[Ishan Bansal]

Changed title displayed in the title bar of the sugar-emulator.
---
 src/jarabe/util/emulator.py |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/jarabe/util/emulator.py b/src/jarabe/util/emulator.py
index 5a99dbe..07f1569 100644
--- a/src/jarabe/util/emulator.py
+++ b/src/jarabe/util/emulator.py
@@ -20,6 +20,7 @@ import subprocess
 import sys
 import time
 from optparse import OptionParser
+from gettext import gettext as _
 
 import gtk
 import gobject
@@ -36,7 +37,8 @@ def _run_xephyr(display, dpi, dimensions, fullscreen):
 cmd = [ 'Xephyr' ]
 cmd.append(':%d' % display)
 cmd.append('-ac') 
-
+cmd += ['-title',_('Sugar in a window')]
+
 screen_size = (gtk.gdk.screen_width(), gtk.gdk.screen_height())
 
 if (not dimensions) and (fullscreen is None) and \
-- 
1.7.0.4

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Time out on registration process to prevent indefinite UI hang (SL#2289)

[Dipankar Patro]

Registration with the school server is currently done synchronously.
To prevent the UI from hanging indefinitely, if the school server is reachable
but unresponsive, we add an explicit timeout.
---
 src/jarabe/desktop/schoolserver.py |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/src/jarabe/desktop/schoolserver.py 
b/src/jarabe/desktop/schoolserver.py
index 62519df..792622a 100644
--- a/src/jarabe/desktop/schoolserver.py
+++ b/src/jarabe/desktop/schoolserver.py
@@ -16,7 +16,8 @@
 
 import logging
 from gettext import gettext as _
-from xmlrpclib import ServerProxy, Error
+import httplib
+import xmlrpclib
 import socket
 import os
 import string
@@ -30,6 +31,7 @@ from sugar import env
 from sugar.profile import get_profile
 
 REGISTER_URL = 'http://schoolserver:8080/'
+REGISTER_TIMEOUT = 10
 
 def generate_serial_number():
 """  Generates a serial number based on 3 random uppercase letters
@@ -76,6 +78,18 @@ def store_identifiers(serial_number, uuid, backup_url):
 class RegisterError(Exception):
 pass
 
+class TimeoutHTTP(httplib.HTTP):
+def __init__(self, host='', port=None, strict=None, timeout = None):
+if port == 0:
+port = None
+self._setup(self._connection_class(host,
+port, strict, timeout = REGISTER_TIMEOUT))
+
+class TimeoutTransport(xmlrpclib.Transport):
+def make_connection(self, host):
+host, extra_headers, x509 = self.get_host_info(host)
+return TimeoutHTTP(host, timeout = REGISTER_TIMEOUT)
+
 def register_laptop(url=REGISTER_URL):
 
 profile = get_profile()
@@ -95,10 +109,10 @@ def register_laptop(url=REGISTER_URL):
 
 nick = client.get_string('/desktop/sugar/user/nick')
 
-server = ServerProxy(url)
+server = xmlrpclib.ServerProxy(url)
 try:
 data = server.register(sn, nick, uuid_, profile.pubkey)
-except (Error, socket.error):
+except (xmlrpclib.Error, socket.error):
 logging.exception('Registration: cannot connect to server')
 raise RegisterError(_('Cannot connect to the server.'))
 
-- 
1.7.0.4

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] known issues with collaboration in XS 0.5.2

[Tomeu Vizoso]

On Wed, Sep 8, 2010 at 12:35, Tomeu Vizoso  wrote:
> On Wed, Sep 8, 2010 at 12:21, Martin Langhoff  wrote:
>> On Wed, Sep 8, 2010 at 5:02 AM, Tomeu Vizoso  wrote:
>>> Note that those are registered users, there's only a dozen online.
>>
>> Ah! Then no, the behaviour is 100% bogus.
>>
>>> I guess in that case you won't accumulate lots of registered users
>>> either, so this behavior shouldn't matter in the field.
>>
>> Well, you do, just that they are segregated in groups. But the
>> "registered, not online" users should not be in memory at all, unless
>> they've been "seen" by ejabberd since it started and it's not perhaps
>> purging its roster?
>>
>> Are you seeing the bug after a long run?
>>
>>> Will consider purging registered users weekly or daily from public
>>> jabber servers such as jabber.sugarlabs.org.
>>
>> Does a restart of ejabberd make this better?
>
> Nope, same slowness. Ejabberd also took all the cpu for a couple of
> minutes when starting up, so it probably loads all registered users to
> memory and does some crazy stuff with them at that point.

Some more info:

- deleting all registered users with ejabberdctl delete-older-users 0
doesn't seem to have any effect, even after restarting

- it's using mnesia, not postgresql

- while churning the CPU, strace shows it's doing this:

clock_gettime(CLOCK_MONOTONIC, {5168912, 600887090}) = 0
pread64(13, "\0\0\7|\0224Vx\0\0\1\347\203h\5d\0\vpubsub_itemh\2k"...,
8192, 5813560) = 8192
pread64(13, "\0\0\6*\0224Vx\0\0\6\"\203h\5d\0\vpubsub_itemh\2k"...,
8192, 5821752) = 8192
pread64(13, "\0\0\1\275\0224Vx\0\0\1\265\203h\5d\0\vpubsub_itemh\2k"...,
8192, 3843384) = 8192
pread64(13, "\0\0\f\202\0224Vx\0\0\6!\203h\5d\0\vpubsub_itemh\2k"...,
8192, 3851576) = 8192
pread64(13, "\0\0\6,\0224Vx\0\0\6$\203h\5d\0\vpubsub_itemh\2k"...,
8192, 5829944) = 8192
pread64(13, "\0\0\6b\0224Vx\0\0\6Z\203h\5d\0\vpubsub_itemh\2k"...,
8192, 5840184) = 8192
pread64(13, "\0\0\4E\0224Vx\0\0\4=\203h\5d\0\vpubsub_itemh\2k"...,
8192, 3859768) = 8192
pread64(13, "\0\0\10W\0224Vx\0\0\1\243\203h\5d\0\vpubsub_itemh\2k"...,
8192, 3867960) = 8192
poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=5,
events=POLLIN|POLLRDNORM}, {fd=8, events=POLLIN|POLLRDNORM}, {fd=7,
events=POLLIN|POLLRDNORM}, {fd=17, events=POLLIN|POLLRDNORM}, {fd=18,
events=POLLIN|POLLRDNORM}, {fd=20, events=POLLIN|POLLRDNORM}, {fd=25,
events=POLLIN|POLLRDNORM}, {fd=21, events=POLLIN|POLLRDNORM}, {fd=28,
events=POLLIN|POLLRDNORM}, {fd=24, events=POLLIN|POLLRDNORM}, {fd=26,
events=POLLIN|POLLRDNORM}, {fd=23, events=POLLIN|POLLRDNORM}, {fd=27,
events=POLLIN|POLLRDNORM}, {fd=29, events=POLLIN|POLLRDNORM}, {fd=19,
events=POLLIN|POLLRDNORM}], 16, 0) = 0

- fd 13 is /var/lib/ejabberd/spool/pubsub_item.DAT which is 12M

- exporting the db with ejabberdctl dump /tmp/test.dump shows that
there's 8916 entries in the pubsub_item table.

So maybe something is not getting purged and maybe we have a very bad
index somewhere?

Regards,

Tomeu

>> [ My questions are a bit hazy here, as I am chasing a few matters at
>> this moment and I cannot devote the time to repro and diagnose/debug
>> this... apologies. ]
>
> There's no rush at all.
>
> Regards,
>
> Tomeu
>
>> cheers,
>>
>>
>> m
>> --
>>  mar...@laptop.org -- School Server Architect
>>  - ask interesting questions
>>  - don't get distracted with shiny stuff  - working code first
>>  - http://wiki.laptop.org/go/User:Martinlanghoff
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] #2295 UNSP: Sugar 0.88 [Dextrose] not reporting all favourite connections to NetworkManager at startup

[Tomeu Vizoso]

On Wed, Sep 8, 2010 at 13:42, Franco Miceli  wrote:
> For what I've been able to see load_wifi_connections collects all wifi
> connections from /home/olpc/.sugar/default/nm/connections.cfg. This function
> gets called by load_connections who gets called by get_settings.
>
> I think that the class NMSettings is where sugar communicates this to NM,
> but I don't seem to find a "main loop" that I can follow in order to
> determine what happens when the process starts for the first time.
>
> Could it  be that this first "connection culling" is not provided by Sugar,
> but in fact by other entity?
>
> Sorry that I can't be of much help, but I'm very new to python and am still
> trying to understand some of the basics.
>
> Please tell me what I can do to help in solving this, since I've made
> changes in the autoconnection feature for the XO in NM, and in order to get
> the algorithms working well I need to get reliable data of the favourite
> connections. So I'm very interested in getting this solved.

Hi Franco,

I'm not familiar with this part of Sugar, but if you can check if this
is the method that NM calls at startup to retrieve the available
connections, we may get a step closer:

http://git.sugarlabs.org/projects/sugar/repos/nops/blobs/master/src/jarabe/model/network.py#line354

Regards,

Tomeu

> Thanks for everything.
>
> Cheers
>
> 2010/9/8 Sugar Labs Bugs 
>>
>> #2295: Sugar 0.88 [Dextrose] not reporting all favourite connections to
>> NetworkManager at startup
>>
>> --+-
>>    Reporter:  fmiceli                    |          Owner:  tomeu
>>        Type:  defect                     |         Status:  new
>>    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by
>> Release Team
>>   Component:  sugar                      |        Version:  0.88.x
>>    Severity:  Minor                      |       Keywords:
>> Distribution:  Dextrose                   |   Status_field:  Unconfirmed
>>
>> --+-
>>
>> Comment(by tomeu):
>>
>>  Hi Franco, have you found the place in Sugar that provides that single
>>  connection to NM?
>>
>> --
>> Ticket URL: 
>> Sugar Labs 
>> Sugar Labs bug tracking system
>
>
>
> --
> Ing. Franco Miceli
> CITS - Plan Ceibal - Investigación & Desarrollo
> Av. Italia 6201 - Montevideo, Uruguay
> CP: 11500
> Tel: (598 2) 601 5773 int.: 2227
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] when changing the owner of a ticket in Trac...

[Walter Bender]

 question about protocol: when should people be
reassigning ownership of tickets in Trac? It seems a lot of tickets
have had their ownership changed of late when someone unilaterally
decides they'll work on a bug, before the work has been done. This
seems broken to me.

 walterbender: I think the owner field should be used to avoid
having people working on the same stuff but whoever becomes the owner
needs to really take care of it not just plan to

tomeu, walterbender normally if you are interested in a bug
you should first put you on cc

I'd add that a brief discussion with the current owner would be good
practice just to make sure everyone in on the same page.

thanks.

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Members shown in Journal for shared activity

[Walter Bender]

On Wed, Sep 8, 2010 at 5:15 AM, Simon Schampijer  wrote:
> Hi,
>
> the following is true on 0.84 (untested so far on master, reports welcome):
>
> Machine A: Share an activity
> Machine B: Join
> Machine C: Join
> Machine C: leaves -> Buddy A and B listed as members in Journal entry on
> machine C
> Machine B: leaves -> Buddy A listed as member in Journal entry on machine B
> Machine A: closes -> No Buddy listed as a member of the Journal entry on
> machine A
>
> I would believe that the list of members should be constructed of all
> the buddies that were in the activity and not of the ones that were in
> the activity the moment you leave it.

+1

>
> What do others think?
>
> Regards,
>    Simon
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] #2295 UNSP: Sugar 0.88 [Dextrose] not reporting all favourite connections to NetworkManager at startup

[Franco Miceli]

For what I've been able to see load_wifi_connections collects all wifi
connections from /home/olpc/.sugar/default/nm/connections.cfg. This function
gets called by load_connections who gets called by get_settings.

I think that the class NMSettings is where sugar communicates this to NM,
but I don't seem to find a "main loop" that I can follow in order to
determine what happens when the process starts for the first time.

Could it  be that this first "connection culling" is not provided by Sugar,
but in fact by other entity?

Sorry that I can't be of much help, but I'm very new to python and am still
trying to understand some of the basics.

Please tell me what I can do to help in solving this, since I've made
changes in the autoconnection feature for the XO in NM, and in order to get
the algorithms working well I need to get reliable data of the favourite
connections. So I'm very interested in getting this solved.

Thanks for everything.

Cheers

2010/9/8 Sugar Labs Bugs 

> #2295: Sugar 0.88 [Dextrose] not reporting all favourite connections to
> NetworkManager at startup
>
> --+-
> Reporter:  fmiceli|  Owner:  tomeu
> Type:  defect | Status:  new
>Priority:  Unspecified by Maintainer  |  Milestone:  Unspecified by
> Release Team
>Component:  sugar  |Version:  0.88.x
>Severity:  Minor  |   Keywords:
> Distribution:  Dextrose   |   Status_field:  Unconfirmed
>
> --+-
>
> Comment(by tomeu):
>
>  Hi Franco, have you found the place in Sugar that provides that single
>  connection to NM?
>
> --
> Ticket URL: 
> Sugar Labs 
> Sugar Labs bug tracking system
>



-- 
Ing. Franco Miceli
CITS - Plan Ceibal - Investigación & Desarrollo
Av. Italia 6201 - Montevideo, Uruguay
CP: 11500
Tel: (598 2) 601 5773 int.: 2227
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] known issues with collaboration in XS 0.5.2

[Tomeu Vizoso]

On Wed, Sep 8, 2010 at 12:21, Martin Langhoff  wrote:
> On Wed, Sep 8, 2010 at 5:02 AM, Tomeu Vizoso  wrote:
>> Note that those are registered users, there's only a dozen online.
>
> Ah! Then no, the behaviour is 100% bogus.
>
>> I guess in that case you won't accumulate lots of registered users
>> either, so this behavior shouldn't matter in the field.
>
> Well, you do, just that they are segregated in groups. But the
> "registered, not online" users should not be in memory at all, unless
> they've been "seen" by ejabberd since it started and it's not perhaps
> purging its roster?
>
> Are you seeing the bug after a long run?
>
>> Will consider purging registered users weekly or daily from public
>> jabber servers such as jabber.sugarlabs.org.
>
> Does a restart of ejabberd make this better?

Nope, same slowness. Ejabberd also took all the cpu for a couple of
minutes when starting up, so it probably loads all registered users to
memory and does some crazy stuff with them at that point.

> [ My questions are a bit hazy here, as I am chasing a few matters at
> this moment and I cannot devote the time to repro and diagnose/debug
> this... apologies. ]

There's no rush at all.

Regards,

Tomeu

> cheers,
>
>
> m
> --
>  mar...@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] known issues with collaboration in XS 0.5.2

[Martin Langhoff]

On Wed, Sep 8, 2010 at 5:02 AM, Tomeu Vizoso  wrote:
> Note that those are registered users, there's only a dozen online.

Ah! Then no, the behaviour is 100% bogus.

> I guess in that case you won't accumulate lots of registered users
> either, so this behavior shouldn't matter in the field.

Well, you do, just that they are segregated in groups. But the
"registered, not online" users should not be in memory at all, unless
they've been "seen" by ejabberd since it started and it's not perhaps
purging its roster?

Are you seeing the bug after a long run?

> Will consider purging registered users weekly or daily from public
> jabber servers such as jabber.sugarlabs.org.

Does a restart of ejabberd make this better?

[ My questions are a bit hazy here, as I am chasing a few matters at
this moment and I cannot devote the time to repro and diagnose/debug
this... apologies. ]

cheers,


m
-- 
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New IRC bot

[Aleksey Lim]

On Sun, Sep 05, 2010 at 12:15:36PM +0200, Bert Freudenberg wrote:
> On 04.09.2010, at 02:57, Aleksey Lim wrote:
> 
> > Hi all,
> > 
> > FIY, To keep IRC logs, I've setup IRC bot - supybot[1]. It supports many
> > useful plugins[2] including meetings (so, we can replace meetbot with
> > more powerful one).
> > 
> > Full irc logs and meeting logs will be stored on [4]
> > (each channel has link to meetings page).
> > 
> > [1] http://sourceforge.net/projects/supybot/
> > [2] http://ubottu.com/stdin/supydocs/plugins.html
> > [3] http://meetbot.debian.net/Manual.html
> > [4] http://jita.sugarlabs.org/
> 
> Nice! Would you mind logging #etoys, too? Thanks! :)

done

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Time out on registration process to prevent indefinite UI hang (SL#2289)

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Wed Sep 08 11:00:13 +0200 2010:

> > +class TimeoutHTTP(httplib.HTTP):
> 
> http://docs.python.org/library/httplib.html says:
> 
> Note
> 
> The public interface for this module changed substantially in Python
> 2.0. The HTTP class is retained only for backward compatibility with
> 1.5.2. It should not be used in new code. Refer to the online
> docstrings for usage.
> 
> Have you considered using the non-deprecated APIs?

I originally meant to say that as well, but double-checked the original
code and discovered that xmlrpclib (a stock Python module) uses the same
API internally. There's a good chance that switching to the newer classes
would require reimplementing large parts of xmlrpclib.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] palette timeouts (was Re: #1169 NORM: Drop down menus give no indication of their existence, also are too slow to load.)

[Tomeu Vizoso]

Hi,

looks like Seeta is interested in doing something about this.

Do we have any kind of agreement on what changes should be done?

Thanks,

Tomeu

On Tue, May 4, 2010 at 06:51, Sugar Labs Bugs
 wrote:
> #1169: Drop down menus give no indication of their existence, also are too 
> slow to
> load.
> -+--
>    Reporter:  wwdillingham  |          Owner:  tomeu
>        Type:  enhancement   |         Status:  new
>    Priority:  Normal        |      Milestone:  0.90
>   Component:  sugar         |        Version:  Unspecified
>    Severity:  Critical      |       Keywords:  interface design usability 
> sugar-love GPA
> Distribution:  Unspecified   |   Status_field:  Needinfo
> -+--
>
> Comment(by FGrose):
>
>  In my estimation, reducing the hover-delay-time-before-palette-showing by
>  50 to 70 % would make the palettes more discoverable.  Pop-up help and
>  previews on the web seem to pop up pretty quickly these days.
>
>  This would be an easier mitigation to implement and would help on action
>  buttons with palette menus as well.
>
>  I like the left click reveal, where possible, as well.
>
> --
> Ticket URL: 
> Sugar Labs 
> Sugar Labs bug tracking system
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SL bug #1520

[Tomeu Vizoso]

On Tue, Sep 7, 2010 at 20:01, Mukul Gupta  wrote:
> Team,
>
> I am working on Bug # 1520 on sugarlabs.
> http://bugs.sugarlabs.org/ticket/1520
> I tried to reproduce the issue on sugar-emulator. I realised that Alt + Tab
> did nothing. Instead, Alt+Tab functioned for GNOME. I tried to run sugar
> from sugar-session. Still, Alt+ Tab did nothing.
> Firstly, I would require some pointers on how to reproduce the bug.
> Secondly, when I read the comments on the bugs page, I realised that fran
> pointed out that this functioning of the Alt+Tab as mentioned in the bug can
> also be considered as a utility rather than a bug.
> A very similar bug to bug #1520 is #1518.
> http://bugs.sugarlabs.org/ticket/1518
>
> As far as solving the current bug is concerned I realised that Bernie had
> created a patch for the same in fedora and that could be implemented on
> ubuntu. I have studied the patch -
> http://sascha.silbe.org/patches/metacity-ungrab-keybindings.patch

Should this patch go upstream?

Regards,

Tomeu

> Regards,
>
> Mukul Gupta
> Research Engineer, SEETA
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] Members shown in Journal for shared activity

[Simon Schampijer]

Hi,

the following is true on 0.84 (untested so far on master, reports welcome):

Machine A: Share an activity
Machine B: Join
Machine C: Join
Machine C: leaves -> Buddy A and B listed as members in Journal entry on 
machine C
Machine B: leaves -> Buddy A listed as member in Journal entry on machine B
Machine A: closes -> No Buddy listed as a member of the Journal entry on 
machine A

I would believe that the list of members should be constructed of all 
the buddies that were in the activity and not of the ones that were in 
the activity the moment you leave it.

What do others think?

Regards,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] known issues with collaboration in XS 0.5.2

[Tomeu Vizoso]

On Tue, Sep 7, 2010 at 17:20, Martin Langhoff  wrote:
> On Tue, Sep 7, 2010 at 10:44 AM, Tomeu Vizoso  wrote:
>> With the script attached, some GetProperties queries take a few
>> seconds, others more than 25 seconds (the default dbus timeout). It
>> should be invoked like this: dbus-launch --exit-with-session python
>> gabble_test.py
>
> Hmmm, great that we have a test script -- thanks! I don't have an XS
> at hand at this very moment, but I do believe what you're saying and
> it makes sense -
>
>> There are presently 2573 registered users and the ejabberd version is
>> ejabberd-xs-2.0.3-11.fc9.olpc.i386 , which is the last one I see in
>> http://fedora.laptop.org/xs/testing/olpc/9/i386/
>
> Ok - so you're on the right version of ejabberd. The datastructures
> get very inefficient when the number of nodes is moderately high --
> some messages travel fast, others show huge latency. I thought of
> refactoring the handling of "@all@" inside of ejabberd (if we
> special-case it a bit, we can avoid the mess of copied
> datastructures).
>
> But it's a daunting prospect. And our "neighbourhood" view doesn't
> behave well with 2.5K users either.

Note that those are registered users, there's only a dozen online.

> So my approach has been to split
> up the groups in courses, via Moodle. In my (unverified) experience,
> this makes ejabberd _much_ happier.

I guess in that case you won't accumulate lots of registered users
either, so this behavior shouldn't matter in the field.

Will consider purging registered users weekly or daily from public
jabber servers such as jabber.sugarlabs.org.

Thanks,

Tomeu

> cheers,
>
>
>
> m
> --
>  mar...@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Time out on registration process to prevent indefinite UI hang (SL#2289)

[Tomeu Vizoso]

On Tue, Sep 7, 2010 at 19:44, Dipankar Patro  wrote:
> Registration with the school server is currently done synchronously.
> To prevent the UI from hanging indefinitely, if the school server is reachable
> but unresponsive, we add an explicit timeout.
> ---
>  src/jarabe/desktop/schoolserver.py |   19 ---
>  1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/src/jarabe/desktop/schoolserver.py 
> b/src/jarabe/desktop/schoolserver.py
> index 62519df..6a96077 100644
> --- a/src/jarabe/desktop/schoolserver.py
> +++ b/src/jarabe/desktop/schoolserver.py
> @@ -16,7 +16,8 @@
>
>  import logging
>  from gettext import gettext as _
> -from xmlrpclib import ServerProxy, Error
> +import httplib
> +import xmlrpclib
>  import socket
>  import os
>  import string
> @@ -30,6 +31,7 @@ from sugar import env
>  from sugar.profile import get_profile
>
>  REGISTER_URL = 'http://schoolserver:8080/'
> +REGISTER_TIMEOUT = 10
>
>  def generate_serial_number():
>     """  Generates a serial number based on 3 random uppercase letters
> @@ -76,6 +78,17 @@ def store_identifiers(serial_number, uuid, backup_url):
>  class RegisterError(Exception):
>     pass
>
> +class TimeoutHTTP(httplib.HTTP):

http://docs.python.org/library/httplib.html says:

Note

The public interface for this module changed substantially in Python
2.0. The HTTP class is retained only for backward compatibility with
1.5.2. It should not be used in new code. Refer to the online
docstrings for usage.

Have you considered using the non-deprecated APIs?

> +   def __init__(self, host='', port=None, strict=None, 
> timeout=socket._GLOBAL_DEFAULT_TIMEOUT):
> +        if port == 0:
> +            port = None
> +        self._setup(self._connection_class(host, port, strict, timeout))

We should never use private and undocumented methods. If this is
indeed the only way to achieve what we want, then we should put a big
warning in the code that points to a ticket in trac because that would
be indeed a bug in Sugar.

Regards,

Tomeu

> +class TimeoutTransport(xmlrpclib.Transport):
> +       def make_connection(self, host):
> +        host, extra_headers, x509 = self.get_host_info(host)
> +        return TimeoutHTTP(host, timeout = REGISTER_TIMEOUT)
> +
>  def register_laptop(url=REGISTER_URL):
>
>     profile = get_profile()
> @@ -95,10 +108,10 @@ def register_laptop(url=REGISTER_URL):
>
>     nick = client.get_string('/desktop/sugar/user/nick')
>
> -    server = ServerProxy(url)
> +    server = xmlrpclib.ServerProxy(url, TimeoutTransport())
>     try:
>         data = server.register(sn, nick, uuid_, profile.pubkey)
> -    except (Error, socket.error):
> +    except (xmlrpclib.Error, socket.error):
>         logging.exception('Registration: cannot connect to server')
>         raise RegisterError(_('Cannot connect to the server.'))
>
> --
> 1.7.0.4
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Update the versions of our telepathy dependencies and add mission control #2228

[Tomeu Vizoso]

On Tue, Sep 7, 2010 at 20:54, Sascha Silbe
 wrote:
> Excerpts from Tomeu Vizoso's message of Tue Sep 07 19:39:55 +0200 2010:
>
>
>> Signed-off-by: Tomeu Vizoso 
>
> I've done some corrections locally:
>
>> +            version="0.9.16"
>> +            module="telepathy-gabble/telepathy-gabble-0.9.16.tar.gz"
>> +            size="2900705" md5sum="7f2ab9256a6202f717bffaf341c99f75">
>
> Updated to use hash= with sha256 instead of md5sum (which is deprecated
> upstream). Same for the other modules.
>
> BTW, there seem to have been releases in the meantime (e.g.
> telepathy-gabble 0.9.17). Should we update to these right away?

Should be safe to update, right now I'm only waiting for a new release
of mission-control with this one fixed:

https://bugs.freedesktop.org/show_bug.cgi?id=28915

> [config/sysdeps/debian-family.xml]
>> +  
>> +  
>> +  
>
> Added the same comment you were using for Fedora.

Thanks, anything else you need from me to push this?

Tomeu

> Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [laptop-accessibility] screenreader for sugar

[Tomeu Vizoso]

On Tue, Sep 7, 2010 at 18:32, Peter Korn  wrote:
>
> Hi Tomeu, gang,
>
> [I'm cc-ing Joanie Diggs, co-maintainer of Orca]
>
> I believe there are 6 key things that need to be done in/for Sugar to enable 
> use of the GNOME accessibility work for folks with vision impairments.  
> Others more expert in the specific details may correct/amend my comments.  I 
> believe the 6 things are:
>
> The shift of AT-SPI from CORBA to DBUS (in process, not yet completed, but 
> builds of at-spi2 are in the GNOME code repository and if someone would start 
> playing and testing with it on the OLPC, that'd be great!)

I tested the very recent bits of at-spi2 in sugar-jhbuild and they
seemed to work fine in that accerciser was able to navigate through
the controls of the desktop window and of activities (applications).

> Implementation of ATK by the Sugar UI components (this is the accessibility 
> API that screen readers like Orca use)

Accerciser showed that it could not go into the HippoCanvas widget
that is used in some fundamental parts of the Sugar shell and also
inside our browser. The browser is moving from xulrunner to webkitgtk+
which I expect to fare much better there. About HippoCanvas, I have
been experimenting with replacing it with custom GtkContainers and
dropping Hippo completely seemed very doable.

> Creating / adapting a magnifier service on Sugar for Orca.  This may be a 
> fairly trivial port of gnome-mag (non-COMPOSITE edition), or it may be a 
> complete re-write

I have no idea of what this entails, but as we have kept quite close
to GNOME's architecture, I expect the fairly trivial port to suffice.

> Porting Orca to Sugar.  This may be fairly trivial, or it may involve a new 
> Sugar-style GUI, etc.

Tried out Orca in Sugar and it was able to read windows titles,
buttons labels, etc. What GUI would it have other than a configuration
parameter for starting it automatically at startup?

> Adding theme support go Sugar for vision impairments - things like a 
> large-print theme, and inverse theme, etc.

The Uruguayan deployment has customized their builds in this direction
but I believe they need help upstreaming it.

> Ensure 100% keyboard operability of Sugar

Hippo is also the roadblock here.

> Tomeu - are there folks in sugar-devel who have cycles to work on these 
> things?

No idea, I started this thread to find out :)

Thanks a lot for the great insights!

Tomeu

>
> Regards,
>
>
> Peter
>
> On 9/7/2010 12:49 AM, Tomeu Vizoso wrote:
>
> On Mon, Sep 6, 2010 at 20:15, Esteban Arias  wrote:
>
>
> no, I tested with gnome desktop.
>
>
> Ok, I can help you get in touch with the GNOME team that works on
> accessibility if you want. They are very dedicated, friendly and
> talented bunch. Collabora and other companies also provide services
> related to accessibility and GNOME.
>
> But nobody else than us is going to fix accessibility in Sugar so
> that's why I'm asking if anybody here has interest in working on this.
> The first need is finding someone who can tell us what needs to be
> improved in Sugar so it can be used by people with no or very low
> vision.
>
> Thanks,
>
> Tomeu
>
>
>
> 2010/9/3 Tomeu Vizoso 
>
>
> On Thu, Sep 2, 2010 at 18:25, Esteban Arias 
> wrote:
>
>
> xo-1.0 | F11 | Dextrose version | Gnome desktop | orca 2.26.3
>
> If I set: "run at startup"
> orca run correctly.
>
>
> Hi Esteban,
>
> to clarify, you configure orca in some way so it runs when sugar
> starts up and it reads what is on the screen?
>
> Thanks,
>
> Tomeu
>
>
>
> If I excecute "orca" from Terminal, shows error:
> /usr/lib/python2.6/site-packages/orca/mouse_review.py:189: Warning:
> invalid
> uninstantiatable type `(null)' in cast to `GdkDisplayX11'
>     self._mouseDwellTimeout(event.detail1, event.detail2)
>
> Displays Preferences dialog, but dont reads screen.
>
> Regards,
> Esteban Arias.
>
> 2010/9/2 Tomeu Vizoso 
>
>
> On Wed, Sep 1, 2010 at 14:51, Esteban Arias 
> wrote:
>
>
> I install orca on xo 1.0 with gnome for f11.
> If I config to start session with orca, runs ok. But if I execute
> orca
> from
> terminal, dont run correctly:
>
>
> Hi Esteban,
>
> could be that your email arrived to us incomplete?
>
> Regards,
>
> Tomeu
>
>
>
> 2010/9/1 pbrobin...@gmail.com 
>
>
> On Wed, Sep 1, 2010 at 10:24 AM, Tomeu Vizoso 
> wrote:
>
>
> On Fri, Aug 20, 2010 at 14:10, Tomeu Vizoso 
> wrote:
>
>
> On Fri, Aug 20, 2010 at 14:08, Esteban Arias
>  wrote:
>
>
> hi,
> we can colaborate with this proyect.
>
>
> Excelent, have you tried already orca with Sugar? And with GNOME?
>
>
> I would say that the next step is for someone who knows how orca
> is
> used to give it a try and file tickets for the biggest issues. Not
> sure we can make much more until then.
>
>
> The gnome guys mentioned this the other day and there's going to be
> some more work done within gnome hopefully for F-14. So hopefully we
> should be looking better for that release.
>
> Peter
>
>
> --
>     Esteban Arias
>     Investigación y Desarrollo -

Re: [Sugar-devel] [PATCH sugar-0.84] journal scan of external media

[Tomeu Vizoso]

On Wed, Sep 8, 2010 at 09:00, James Cameron  wrote:
> On Tue, Sep 07, 2010 at 01:18:11PM +0200, Sascha Silbe wrote:
>> Agreed. I wonder if we could somehow wrap os.walk() in a single,
>> low-priority idle task. Alternatively call find in a subprocess and
>> use gobject.io_add_watch(). Especially if we want to continue indexing
>> symlinked directories this would be a good approach (see below).
>
> I've reworked it to be as asynchronous as I can make it without moving
> into a separate thread or process.
>
> - the progress bar updates smoothly during the filesystem scan, except
>  when a system call (a single os.listdir or os.stat) is held up due
>  to media or scheduling delays,
>
> - the user interface is responsive during the filesystem scan,
>
> - when an I/O error retry is happening on a USB HDD, the old code
>  would not respond quickly to user cancelling the view, since there
>  were thousands of idle tasks to get through before the event queue
>  was checked, the new code responds to the event as soon as the current
>  retry times out,
>
> - normal expected I/O errors are handled and ignored.
>
> The patch below is a rewrite of the function _recurse_dir, and I've
> replaced tabs with spaces only because the indenting changes make the
> patch hard to read otherwise.
>
> I'm not asking for the patch to be accepted as is, I presume I'd be
> asked to break it down into ten different patches so that each change
> is explained in a different way to how my thought processes proceeded.

FWIW, I think this should go in a single patch because it doesn't make
sense to cherry-pick pieces of a single refactoring/rewrite.

About the tabs change, the -w flag to git diff and blame can cope with
it, but I think when someone finds tabs should just push that change
inmediately. (Though I have grepped through master and have only found
tabs in invites.py).

> I think it needs to be split into smaller functions,

+1

Regards,

Tomeu

> and it doesn't
> address the issue of relative recursive links.
>
> What I'm asking for is a review of the new code so far.
>
> The old code was recursive; by calling itself through the gobject idle
> add.  Each idle task was called once.
>
> The new code is called by the idle loop until it returns False.  There
> is only one idle task, not one per directory.
>
> The new code maintains a list of pending directories and files.  The
> pending directory list is initialised with the mount point.  The pending
> files are processed one call at a time until they are exhausted, then
> the pending directories are processed once.  Eventually the lists become
> empty and the result set is ready.
>
> In effect, a pair of lists are used for synthetic recursion.
>
> diff --git a/src/jarabe/journal/model.py b/src/jarabe/journal/model.py
> index 50e8dc1..6ced07c 100644
> --- a/src/jarabe/journal/model.py
> +++ b/src/jarabe/journal/model.py
> @@ -16,10 +16,11 @@
>
>  import logging
>  import os
> +import errno
>  from datetime import datetime
>  import time
>  import shutil
> -from stat import S_IFMT, S_IFDIR, S_IFREG
> +from stat import S_IFLNK, S_IFMT, S_IFDIR, S_IFREG
>  import traceback
>  import re
>
> @@ -258,7 +259,8 @@ class InplaceResultSet(BaseResultSet):
>         BaseResultSet.__init__(self, query, cache_limit)
>         self._mount_point = mount_point
>         self._file_list = None
> -        self._pending_directories = 0
> +        self._pending_directories = []
> +        self._pending_files = []
>         self._stopped = False
>
>         query_text = query.get('query', '')
> @@ -283,7 +285,9 @@ class InplaceResultSet(BaseResultSet):
>
>     def setup(self):
>         self._file_list = []
> -        self._recurse_dir(self._mount_point)
> +        self._pending_directories = [self._mount_point]
> +        self._pending_files = []
> +        gobject.idle_add(self._recurse_dir)
>
>     def stop(self):
>         self._stopped = True
> @@ -317,51 +321,79 @@ class InplaceResultSet(BaseResultSet):
>
>         return entries, total_count
>
> -    def _recurse_dir(self, dir_path):
> -        if self._stopped:
> -            return
> -
> -        for entry in os.listdir(dir_path):
> -            if entry.startswith('.'):
> -                continue
> -            full_path = dir_path + '/' + entry
> -            try:
> -                stat = os.stat(full_path)
> -                if S_IFMT(stat.st_mode) == S_IFDIR:
> -                    self._pending_directories += 1
> -                    gobject.idle_add(lambda s=full_path: 
> self._recurse_dir(s))
> -
> -                elif S_IFMT(stat.st_mode) == S_IFREG:
> -                    add_to_list = True
> -
> -                    if self._regex is not None and \
> -                            not self._regex.match(full_path):
> -                        add_to_list = False
> -
> -                    if None not in [self._date_start, self._date_end] and \
> -                            (stat.st_mtime < self._date_start or
> -                         

Re: [Sugar-devel] [PATCH sugar-0.84] journal scan of external media

[James Cameron]

On Tue, Sep 07, 2010 at 01:18:11PM +0200, Sascha Silbe wrote:
> Agreed. I wonder if we could somehow wrap os.walk() in a single,
> low-priority idle task. Alternatively call find in a subprocess and
> use gobject.io_add_watch(). Especially if we want to continue indexing
> symlinked directories this would be a good approach (see below).

I've reworked it to be as asynchronous as I can make it without moving
into a separate thread or process.

- the progress bar updates smoothly during the filesystem scan, except
  when a system call (a single os.listdir or os.stat) is held up due
  to media or scheduling delays,

- the user interface is responsive during the filesystem scan,

- when an I/O error retry is happening on a USB HDD, the old code
  would not respond quickly to user cancelling the view, since there
  were thousands of idle tasks to get through before the event queue
  was checked, the new code responds to the event as soon as the current
  retry times out,

- normal expected I/O errors are handled and ignored.

The patch below is a rewrite of the function _recurse_dir, and I've
replaced tabs with spaces only because the indenting changes make the
patch hard to read otherwise.

I'm not asking for the patch to be accepted as is, I presume I'd be
asked to break it down into ten different patches so that each change
is explained in a different way to how my thought processes proceeded.
I think it needs to be split into smaller functions, and it doesn't
address the issue of relative recursive links.

What I'm asking for is a review of the new code so far.

The old code was recursive; by calling itself through the gobject idle
add.  Each idle task was called once.

The new code is called by the idle loop until it returns False.  There
is only one idle task, not one per directory.

The new code maintains a list of pending directories and files.  The
pending directory list is initialised with the mount point.  The pending
files are processed one call at a time until they are exhausted, then
the pending directories are processed once.  Eventually the lists become
empty and the result set is ready.

In effect, a pair of lists are used for synthetic recursion.

diff --git a/src/jarabe/journal/model.py b/src/jarabe/journal/model.py
index 50e8dc1..6ced07c 100644
--- a/src/jarabe/journal/model.py
+++ b/src/jarabe/journal/model.py
@@ -16,10 +16,11 @@
 
 import logging
 import os
+import errno
 from datetime import datetime
 import time
 import shutil
-from stat import S_IFMT, S_IFDIR, S_IFREG
+from stat import S_IFLNK, S_IFMT, S_IFDIR, S_IFREG
 import traceback
 import re
 
@@ -258,7 +259,8 @@ class InplaceResultSet(BaseResultSet):
 BaseResultSet.__init__(self, query, cache_limit)
 self._mount_point = mount_point
 self._file_list = None
-self._pending_directories = 0
+self._pending_directories = []
+self._pending_files = []
 self._stopped = False
 
 query_text = query.get('query', '')
@@ -283,7 +285,9 @@ class InplaceResultSet(BaseResultSet):
 
 def setup(self):
 self._file_list = []
-self._recurse_dir(self._mount_point)
+self._pending_directories = [self._mount_point]
+self._pending_files = []
+gobject.idle_add(self._recurse_dir)
 
 def stop(self):
 self._stopped = True
@@ -317,51 +321,79 @@ class InplaceResultSet(BaseResultSet):
 
 return entries, total_count
 
-def _recurse_dir(self, dir_path):
-if self._stopped:
-return
-
-for entry in os.listdir(dir_path):
-if entry.startswith('.'):
-continue
-full_path = dir_path + '/' + entry
-try:
-stat = os.stat(full_path)
-if S_IFMT(stat.st_mode) == S_IFDIR:
-self._pending_directories += 1
-gobject.idle_add(lambda s=full_path: self._recurse_dir(s))
-
-elif S_IFMT(stat.st_mode) == S_IFREG:
-add_to_list = True
-
-if self._regex is not None and \
-not self._regex.match(full_path):
-add_to_list = False
-
-if None not in [self._date_start, self._date_end] and \
-(stat.st_mtime < self._date_start or
- stat.st_mtime > self._date_end):
-add_to_list = False
-
-if self._mime_types:
-mime_type = gio.content_type_guess(filename=full_path)
-if mime_type not in self._mime_types:
-add_to_list = False
-
-if add_to_list:
-file_info = (full_path, stat, int(stat.st_mtime))
-self._file_list.append(file_info)
-
-self.progress.send(self)
-
-except Exception:
-logging.error('Error reading file %r: %s