Re: [Sugar-devel] xo colors & gradients
Hi Erik, On 7 Sep 2010, at 19:01, Erik Blankinship wrote: > On Mon, Aug 23, 2010 at 4:49 PM, Gary Martin > wrote: > I don't think I've seen any activity icons try this yet, but it might work > for some specific cases if it's not used to try and make 3d style shaded > button icons. > > > The sample activity icon with a graident I put on the almanac causes the > launching of a dummy activity on the xo-1 (and other older computers too, I > presume) to stutter. I suspect this is because sugar is rendering the > colored version of the icon at launch time. If this is the case, the > xo-colored activity icon might be something sugar should pre-render? There has been efforts in pre-rendering SVGs at specific sizes, but no clear improvements for the general case, the catch being that activity icons vary in fill/stroke colour and in scale depending where in the interface they are needed. Of course special cases like icons with alpha gradients may well be measurably helped by such optimisations, but are not part of the core Sugar style guidelines, so I'd hate to see effort burnt there when there are so many other things we could do with (unless their use also overlaps with other more common use cases). Sugar is severely lacking in efficient animation and alpha compositing abilities, for it's most common hardware platform, we can't even show a dialogue while dimming out the background, or translate/zoom in a change of view. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Shutdown and Logout menu items should activate the buzzy cursor (SL#2151)
On Wed, Sep 08, 2010 at 08:10:27AM +0530, Anurag Chowdhury wrote: > Shutdown (and Logout) menu items should activate the buzzy cursor (or > provide some other visual feedback, perhaps dimming/locking the UI > from use). You mean the busy cursor. I've tried the patch you proposed. It doesn't work. The GTK+ event loop doesn't even get a chance to refresh the area under the menu palette before the X server collapses. I tried adding a call to gtk.gdk.flush() but there was no impact. The X server collapses within about a second. Even in that time, there was no change to the cursor that I could see. On what platform do you see a delay between releasing the mouse button and the X server terminating, and what amount of delay occurs? > def __logout_activate_cb(self, menu_item): > +self.window.set_cursor( gtk.gdk.Cursor(gtk.gdk.WATCH) ) # newline The " # newline" is unnecessary. The "self.window" would refer only to the menu button on the palette, which is dismissed by the operation. You should refer instead to the top level window. Perhaps that is why it did nothing for me. Does it work for you? -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Pukllanapac-3
Activity Homepage: http://activities.sugarlabs.org/addon/4320 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/27010/pukllanapac-3.xo Release notes: * added card rotation Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Home button in Browse
On Mon, Sep 06, 2010 at 09:21:06PM -0700, Hal Murray wrote: > >> Go-home would be the button I press most often, to counteract > auto-resuming. > > > FWIW you can hold while clicking on the activity to start a new > > instance instead of resuming the most recent one. > > Neat/thanks. > > Where is that documented? What else have I missed? http://wiki.sugarlabs.org/go/0.86/Notes#Home_Favourites_View_Improvements > It didn't work for me. Is that a recent change? I'm running os852 > which has Sugar 0.84.16. Yes, it's a change after the version you are running. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Shutdown and Logout menu items should activate the buzzy cursor (SL#2151)
Shutdown (and Logout) menu items should activate the buzzy cursor (or provide some other visual feedback, perhaps dimming/locking the UI from use). --- buddymenu.py |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/buddymenu.py b/buddymenu.py index 0ba6cc1..4e7f501 100644 --- a/buddymenu.py +++ b/buddymenu.py @@ -98,14 +98,17 @@ class BuddyMenu(Palette): item.show() def __logout_activate_cb(self, menu_item): +self.window.set_cursor( gtk.gdk.Cursor(gtk.gdk.WATCH) ) # newline session_manager = get_session_manager() session_manager.logout() def __reboot_activate_cb(self, menu_item): +self.window.set_cursor( gtk.gdk.Cursor(gtk.gdk.WATCH) ) # newline session_manager = get_session_manager() session_manager.reboot() def __shutdown_activate_cb(self, menu_item): +self.window.set_cursor( gtk.gdk.Cursor(gtk.gdk.WATCH) ) # newline session_manager = get_session_manager() session_manager.shutdown() -- 1.7.2.2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [laptop-accessibility] screenreader for sugar
Excerpts from Tomeu Vizoso's message of Tue Sep 07 19:49:30 +0200 2010: > [forwarding kind email from Peter Korn, will reply myself tomorrow morning] > > On Tue, Sep 7, 2010 at 18:32, Peter Korn wrote: Peter, I've added you as a list subscriber with disabled delivery, so you should be able to post to sugar-devel now. 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
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? [config/sysdeps/debian-family.xml] > + > + > + Added the same comment you were using for Fedora. 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
Excerpts from Ishan Bansal's message of Tue Sep 07 19:43:24 +0200 2010:
> Changed title displayed in the title bar of the sugar-emulator.
"Changed" isn't very useful on it's own. Please say what changed (i.e.
a slightly more elaborative version of your subject) and why.
> +cmd.append('-title')
> +cmd.append(_('Sugar in a window'))
Why not += on a single line?
cmd += ['-title', _('Sugar in a window')]
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)
Excerpts from Dipankar Patro's message of Tue Sep 07 19:44:17 +0200 2010: > +class TimeoutHTTP(httplib.HTTP): > + def __init__(self, host='', port=None, strict=None, > timeout=socket._GLOBAL_DEFAULT_TIMEOUT): Line too long (> 80 chars). I don't think you'll ever get passed timeout as a parameter, so just use a local variable instead. Otherwise your patch looks fine. 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] loading ttf fonts in a sugar activity
Thanks Tomeu. The results look great. On Wed, Sep 1, 2010 at 3:42 AM, Tomeu Vizoso wrote: > On Tue, Aug 31, 2010 at 21:20, Erik Blankinship > wrote: > > I am wondering if there is a sugar activity which loads in custom ttf > fonts? > > The almanac does not provide an example > > > http://wiki.sugarlabs.org/go/Development_Team/Almanac/Pango#How_do_I_control_the_appearance_of_fonts_on_a_Pango_layout.3F > > ...but a google search suggests it should be possible with pango. Does > > anyone have any experience with embedding fonts into a sugar activity? I > > would be happy to write it up into the almanac for others benefit once I > > figure it out. > > Doesn't seem to be possible to load a bundled font with pango at this > moment: https://bugzilla.gnome.org/show_bug.cgi?id=347237 > > But this hack seems to work, though you are not using Pango and you > may miss some of its most advanced features: > http://cairographics.org/freetypepython/ > > Regards, > > Tomeu > > > ___ > > 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] xo colors & gradients
On Mon, Aug 23, 2010 at 4:49 PM, Gary Martin wrote: > I don't think I've seen any activity icons try this yet, but it might work > for some specific cases if it's not used to try and make 3d style shaded > button icons. > > The sample activity icon with a graident I put on the almanac causes the launching of a dummy activity on the xo-1 (and other older computers too, I presume) to stutter. I suspect this is because sugar is rendering the colored version of the icon at launch time. If this is the case, the xo-colored activity icon might be something sugar should pre-render? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SL bug #1520
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 Regards, Mukul Gupta Research Engineer, SEETA ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [laptop-accessibility] screenreader for sugar
[forwarding kind email from Peter Korn, will reply myself tomorrow morning] 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!) > Implementation of ATK by the Sugar UI components (this is the accessibility > API that screen readers like Orca use) > 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 > Porting Orca to Sugar. This may be fairly trivial, or it may involve a new > Sugar-style GUI, etc. > Adding theme support go Sugar for vision impairments - things like a > large-print theme, and inverse theme, etc. > Ensure 100% keyboard operability of Sugar > > Tomeu - are there folks in sugar-devel who have cycles to work on these > things? > > > 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 - Plan Ceibal > Avda. Italia 6201 > Montevideo - Uruguay. > Tel.: 2601.57.73 Interno 2228 > E-mail : ear...@plan.ceibal.edu.uy > > > > > -- > Esteban Arias > Investigación y Desarrollo - Plan Ceibal > Avda. Italia 6201 > Montevideo - Uruguay. > Tel.: 2601.57.73 Interno 2228 > E-mail : ear...@plan.ceibal.edu.uy > > > > > -- > Esteban Arias > Investigación y Desarrollo - Plan Ceibal > Avda. Italia 6201 > Montevideo - Uruguay. > Tel.: 2601.57.73 Interno 2228 > E-mail : ear...@plan.ceibal.edu.uy > > > > > ___ > accessibility mailing list > accessibil...@lists.laptop.org > http://lists.laptop.org/listinfo/accessibility > > > -- > > Peter Korn | Accessibility Principal > Phone: +1 650 5069522 > 500 Oracle Parkway | Redwood City, CA 94065 > Oracle is committed to developing practices and products that help protect > the environment > ___ > accessibility mailing list > accessibil...@lists.laptop.org > http://lists.laptop.org/listinf
[Sugar-devel] [PATCH] Time out on registration process to prevent indefinite UI hang (SL#2289)
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):
+ 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))
+
+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] [PATCH] Display 'Sugar in a window' instead of 'Xephyr on'. Ticket #2285
Changed title displayed in the title bar of the sugar-emulator.
---
src/jarabe/util/emulator.py |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/jarabe/util/emulator.py b/src/jarabe/util/emulator.py
index 5a99dbe..c16680f 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,8 @@ def _run_xephyr(display, dpi, dimensions, fullscreen):
cmd = [ 'Xephyr' ]
cmd.append(':%d' % display)
cmd.append('-ac')
+cmd.append('-title')
+cmd.append(_('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
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. 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-family.xml > +++ b/config/sysdeps/fedora-family.xml > @@ -46,6 +46,7 @@ > > > > + > > > > @@ -69,14 +70,12 @@ > > > > - > > + > > - > - > - > > > + > > > > diff --git a/sjhbuild/config.py b/sjhbuild/config.py > index 8fd4ec0..e451f93 100644 > --- a/sjhbuild/config.py > +++ b/sjhb
[Sugar-devel] [PATCH] Update the versions of our telepathy dependencies and add mission control #2228
Signed-off-by: Tomeu Vizoso
---
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 @@
+version="0.9.16"
+module="telepathy-gabble/telepathy-gabble-0.9.16.tar.gz"
+size="2900705" md5sum="7f2ab9256a6202f717bffaf341c99f75">
@@ -111,9 +111,9 @@
+version="0.3.13"
+module="telepathy-salut/telepathy-salut-0.3.13.tar.gz"
+size="1209052" md5sum="173448d2680026c5e311f7c97cdda327">
@@ -121,22 +121,33 @@
-
+
-
+
http://download.gnome.org/sources/evince/2.25/evince-2.25.92.tar.bz2";
version="2.25.92" size="1842261"
md5sum="5e0d0fc2d900856074b556e4eacc68e6"/>
+
+
+
+
+
+
+
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-family.xml
+++ b/config/sysdeps/fedora-family.xml
@@ -46,6 +46,7 @@
+
@@ -69,14 +70,12 @@
-
+
-
-
-
+
diff --git a/sjhbuild/config.py b/sjhbuild/config.py
index 8fd4ec0..e451f93 100644
--- a/sjhbuild/config.py
+++ b/sjhbuild/config.py
@@ -61,6 +61,7 @@ class Config(jhbuild.config.Config):
# Enable debug log of the Telepathy components
os.environ.setdefault('GABBLE_DEBUG', 'all')
os.environ.setdefault('SALUT_DEBUG', 'all')
+os.environ.setdefault('MC_DEBUG', 'all')
os.environ.setdefault('STREAM_ENGINE_DEBUG', 'all')
# We need to add the gtk-2.0 directory explicitly to
--
1.7.2.2
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introspection packages (was: Re: Patch review request for ticket #2290)
On Tue, Sep 7, 2010 at 10:32 AM, Tomeu Vizoso wrote: > On Tue, Sep 7, 2010 at 17:13, Sascha Silbe > wrote: >> Excerpts from Tomeu Vizoso's message of Tue Sep 07 15:30:53 +0200 2010: >> >>> Sorry for not being clear, what I meant is that GNOME Shell is stated >>> for inclusion in GNOME 2.34 and that it's going to require a fairly >>> updated stack, including introspection. I expect major distros that >>> have a time-based release cycle to follow suit. >> >> [...] >> >>> I expect packages to be updated very often because of new feature and >>> bugfix development until GNOME 2.34 is out. >> >> That might be the case for Fedora, but not necessarily for Debian and >> Ubuntu, which were the ones I worried about and where we might need >> someone to maintain bleeding edge packages for. > > Well, Ubuntu wants to ship GNOME Shell in Maverick already, so they > are going to need some introspection, actually something newer than > the last release, by what I read in #introspection. > > Also, Ubuntu didn't aimed for Gtk 3.x for Maverick because of time > constraints but it's quite probably they will for Maverick+1 and there > won't be static bindings for Gtk 3.x. We are in the final month before the release of maverick. We, both the ubuntu sugar remix team and ubuntu, will start Maverick planning the seek of oct 10. It will be hard to get any commitment before then. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introspection packages (was: Re: Patch review request for ticket #2290)
On Tue, Sep 7, 2010 at 17:13, Sascha Silbe wrote: > Excerpts from Tomeu Vizoso's message of Tue Sep 07 15:30:53 +0200 2010: > >> Sorry for not being clear, what I meant is that GNOME Shell is stated >> for inclusion in GNOME 2.34 and that it's going to require a fairly >> updated stack, including introspection. I expect major distros that >> have a time-based release cycle to follow suit. > > [...] > >> I expect packages to be updated very often because of new feature and >> bugfix development until GNOME 2.34 is out. > > That might be the case for Fedora, but not necessarily for Debian and > Ubuntu, which were the ones I worried about and where we might need > someone to maintain bleeding edge packages for. Well, Ubuntu wants to ship GNOME Shell in Maverick already, so they are going to need some introspection, actually something newer than the last release, by what I read in #introspection. Also, Ubuntu didn't aimed for Gtk 3.x for Maverick because of time constraints but it's quite probably they will for Maverick+1 and there won't be static bindings for Gtk 3.x. Of course, this is all speculation. Regards, 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] known issues with collaboration in XS 0.5.2
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. So my approach has been to split up the groups in courses, via Moodle. In my (unverified) experience, this makes ejabberd _much_ happier. 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] Introspection packages (was: Re: Patch review request for ticket #2290)
Excerpts from Tomeu Vizoso's message of Tue Sep 07 15:30:53 +0200 2010: > Sorry for not being clear, what I meant is that GNOME Shell is stated > for inclusion in GNOME 2.34 and that it's going to require a fairly > updated stack, including introspection. I expect major distros that > have a time-based release cycle to follow suit. [...] > I expect packages to be updated very often because of new feature and > bugfix development until GNOME 2.34 is out. That might be the case for Fedora, but not necessarily for Debian and Ubuntu, which were the ones I worried about and where we might need someone to maintain bleeding edge packages for. 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] known issues with collaboration in XS 0.5.2
On Mon, Sep 6, 2010 at 10:27, Tomeu Vizoso wrote:
> On Fri, Sep 3, 2010 at 19:48, Martin Langhoff wrote:
>> On Fri, Sep 3, 2010 at 12:43 PM, Tomeu Vizoso wrote:
>>> I have a local XS 0.6 that is working fine but I'm finding that the XS
>>> 0.5.2 at jabber.sugarlabs.org is not returning some results for some
>>> of the queries that I make.
>>
>> There are very important bugfixes in the "final" ejabberd that is in
>> olpcxs-testing repo for xs-0.6
>>
>> I should release a 0.6.1 with the contents of olpcxs-testing, but
>> things haven't been kind to me lately.
>>
>> You aren't telling us exactly what problems you saw on the old
>> ejabberd.
>
> I'm noticing that the server never replies to some PEP queries about
> buddyinfo and activity properties. The symptom on the Sugar side is
> that the DBus calls timeout.
Actually, it eventually replies, it's just that it takes veeery long sometimes.
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
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/
Martin, does it match your experience that, when there are several
hundreds of registered users, PEP queries could take so much CPU?
During each query, the process 'beam' was taking 100% CPU. Postgres
didn't appeared in top.
Thanks,
Tomeu
>> All I can say is: that old ejabberd (+patches) had plenty of
>> gremlins and unexplainable behaviours. The ejabberd in olpcxs-testing
>> has been 100% reliable in behaviour, and I reworked the patches until
>> I didn't see any buggy behaviour.
>
> Thanks, this answers perfectly my question.
>
>> Highly recommended. Should work with just a rebuild if you're not on F9.
>>
>> I cannot confirm that the right patches are in the latest ejabberd on F13.
>
> Ok, will be keeping an eye on further updates to the School Server
> software and will test Sugar against its jabber server.
>
>> 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
>>
>
from functools import partial
import logging
import gobject
import dbus
import dbus.mainloop.glib
import telepathy
from dbus import PROPERTIES_IFACE
from telepathy.interfaces import ACCOUNT, \
ACCOUNT_MANAGER, \
CONNECTION, \
CHANNEL, \
CHANNEL_INTERFACE_GROUP, \
CONNECTION_INTERFACE_REQUESTS, \
CONNECTION_INTERFACE_ALIASING, \
CONNECTION_INTERFACE_CONTACTS, \
CHANNEL_TYPE_CONTACT_LIST
from telepathy.constants import HANDLE_TYPE_LIST
ACCOUNT_MANAGER_SERVICE = 'org.freedesktop.Telepathy.AccountManager'
ACCOUNT_MANAGER_PATH = '/org/freedesktop/Telepathy/AccountManager'
CONNECTION_INTERFACE_BUDDY_INFO = 'org.laptop.Telepathy.BuddyInfo'
CONNECTION_INTERFACE_ACTIVITY_PROPERTIES = \
'org.laptop.Telepathy.ActivityProperties'
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
main_loop = gobject.MainLoop()
connection = None
def _account_property_changed_cb(account_path, properties):
if 'ConnectionStatus' not in properties:
return
if properties['ConnectionStatus'] == 0:
bus = dbus.Bus()
obj = bus.get_object(ACCOUNT_MANAGER_SERVICE, account_path)
connection_path = obj.Get(ACCOUNT, 'Connection', dbus_interface=PROPERTIES_IFACE)
connection_name = connection_path.replace('/', '.')[1:]
global connection
connection = bus.get_object(connection_name, connection_path)
properties = {
CHANNEL + '.ChannelType': CHANNEL_TYPE_CONTACT_LIST,
CHANNEL + '.TargetHandleType': HANDLE_TYPE_LIST,
CHANNEL + '.TargetID': 'subscribe',
}
properties = dbus.Dictionary(properties, signature='sv')
is_ours, channel_path, properties = \
connection.EnsureChannel(properties,
dbus_interface=CONNECTION_INTERFACE_REQUESTS)
channel = bus.get_object(connection_name, channel_path)
channel.connect_to_signal('MembersChanged', _members_changed_cb)
channel.Get(CHANNEL_INTERFACE_GROUP,
'Members',
reply_handler=_get_members_ready_cb,
error_handler=partial(_error_handler_cb,
'Connection.GetMembers'),
dbus_interface=PROPERTIES_IFACE)
def _members_changed_cb(message, added, removed, local_pending,
Re: [Sugar-devel] [PATCH] Increase timeout for buddy properties queries #2298
On Tue, Sep 7, 2010 at 14:55, Sascha Silbe wrote: > Excerpts from Tomeu Vizoso's message of Tue Sep 07 13:40:28 +0200 2010: > >> Signed-off-by: Tomeu Vizoso > > A long description would be nice. The docstring from your patch would do > fine. Ok. >> +_QUERY_DBUS_TIMEOUT = 200 > > 200 seconds (over 3 minutes) is a really long time for updating the > Neighborhood. Well, it's the time from when we ask for extended information about a buddy until the answer comes. Presently we are using dbus' default which is 25 seconds. I think values of 50, 100 or 500 would be equally good because jabber servers are supposed to reply always. > I'm curious, what are the actual times you encountered > during testing? It could go from 3-4 seconds to 30-40. > Do you have any idea why the server might be that slow? Most probably some throttling done by ejabberd because we are making many more PEP queries than what other clients would do. Scratch that, just peeked into the server and ejabberd just cannot get enough CPU to answer the queries. I think we can assume that in this case the long time that a query takes to be processed is due to a defect in the server, but because servers use to do throttling and we request a considerable amount of information in short bursts, I think it would make sense to increase the default dbus timeout for these queries. But there's no rush at all, we can do so after more testing is done. Will give more details in the other open thread about ejabberd and the school server. >> +""" >> +Time in seconds to wait when querying contact properties. Some jabber >> servers >> +will be very slow in returning these queries, so just be patient. >> +""" > > Is there a special reason you used a docstring after the variable > instead of a comment before it? It's what http://www.python.org/dev/peps/pep-0257/ calls "attribute docstring", it could be extracted by documentation tools. Regards, 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] Introspection packages (was: Re: Patch review request for ticket #2290)
On Tue, Sep 7, 2010 at 14:48, Sascha Silbe wrote: > Excerpts from Tomeu Vizoso's message of Tue Sep 07 14:01:38 +0200 2010: > >> > Then someone should get started on packaging the introspection stuff >> > for Debian, Ubuntu and if necessary Fedora (the distributions supported >> > by sugar-jhbuild). :-P ;) >> I'm not too worried about it being packaged in those distros, > > Not sure I understand that part of the sentence. Do you mean you expect > it to be packaged by someone soon? If so, who resp. where? Sorry for not being clear, what I meant is that GNOME Shell is stated for inclusion in GNOME 2.34 and that it's going to require a fairly updated stack, including introspection. I expect major distros that have a time-based release cycle to follow suit. There are other changes in GNOME that are going to require apps to drop deprecated APIs and their replacements won't be available as static bindings. So either people suddenly start writing static bindings, packaging them and maintaining the existing ones, or they will have to port to introspection. The situation is not as rosy as it could be because people are starting late to make these changes, but kicking out so many apps is probably out of question. >> it only may not get to the stable/testing release of your choice :( > > Given that 0.92 is going to be rather disruptive due to API breakage > being forced upon us by GNOME, I don't think requiring packages from > non-default sources is a blocker, as long as these are maintained well > enough (e.g. timely security updates). I expect packages to be updated very often because of new feature and bugfix development until GNOME 2.34 is out. Regards, 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] [PATCH] Build Squeak VM 4.0.3 from tarfile
On Tue, Sep 7, 2010 at 6:09 AM, Tomeu Vizoso wrote: > On Mon, Sep 6, 2010 at 13:08, Bert Freudenberg wrote: >> >> On 03.09.2010, at 10:47, Tomeu Vizoso wrote: >> >>> On Fri, Sep 3, 2010 at 00:10, Bert Freudenberg wrote: This is almost the same as my patch from April, which never made it in. Instead of building from the outdated "olpc" subversion branch, the Squeak VM is build from a release tarball. It adds a cmake dependency, and gives an error if make is run without running autogen.sh first. Also adds a "clean" make target to please jhbuild. >>> >>> Not sure how relevant it is, but someone at Collabora was adding cmake >>> support to upstream jhbuild recently. >>> >>> http://git.gnome.org/browse/jhbuild/commit/?id=aa564775b5c26527c5ff1d5ad8db8a3565d4dff2 >>> >>> Regards, >>> >>> Tomeu >> >> Is this an actual objection? What do I need to do to get this patch accepted? > > Was just a comment. > > For the others, Bert has been working with Sascha on this on #sugar. > I have noticed this happening several times lately. I think many of us have been reading Tomue's comments as objects when in fact many are meant to share information about possible solutions. david PS Bert if you ever need to stall before preparing a talk We still need to get squeak into Debian proper. It is packaged and in both debian and ubuntu, but we still need to finish the process of getting approval from the Debian FTP_masters to move squeak for contrib to main. I think the work is 90% done. It is still matter of helping them understand how squeak recursively builds itself and how that process can be monitored for security purposes. The standard packaging model is pristine tarball + patch set. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Increase timeout for buddy properties queries #2298
Excerpts from Tomeu Vizoso's message of Tue Sep 07 13:40:28 +0200 2010: > Signed-off-by: Tomeu Vizoso A long description would be nice. The docstring from your patch would do fine. > +_QUERY_DBUS_TIMEOUT = 200 200 seconds (over 3 minutes) is a really long time for updating the Neighborhood. I'm curious, what are the actual times you encountered during testing? Do you have any idea why the server might be that slow? > +""" > +Time in seconds to wait when querying contact properties. Some jabber servers > +will be very slow in returning these queries, so just be patient. > +""" Is there a special reason you used a docstring after the variable instead of a comment before 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
[Sugar-devel] Introspection packages (was: Re: Patch review request for ticket #2290)
Excerpts from Tomeu Vizoso's message of Tue Sep 07 14:01:38 +0200 2010: > > Then someone should get started on packaging the introspection stuff > > for Debian, Ubuntu and if necessary Fedora (the distributions supported > > by sugar-jhbuild). :-P ;) > I'm not too worried about it being packaged in those distros, Not sure I understand that part of the sentence. Do you mean you expect it to be packaged by someone soon? If so, who resp. where? > it only may not get to the stable/testing release of your choice :( Given that 0.92 is going to be rather disruptive due to API breakage being forced upon us by GNOME, I don't think requiring packages from non-default sources is a blocker, as long as these are maintained well enough (e.g. timely security updates). 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 review request for ticket #2290
On Tue, Sep 7, 2010 at 13:53, Sascha Silbe wrote: > Excerpts from Marco Pesenti Gritti's message of Tue Sep 07 01:29:30 +0200 > 2010: > >> So many reasons to move to introspection :) > > Then someone should get started on packaging the introspection stuff > for Debian, Ubuntu and if necessary Fedora (the distributions supported > by sugar-jhbuild). :-P ;) I'm not too worried about it being packaged in those distros, it only may not get to the stable/testing release of your choice :( Regards, 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] Patch review request for ticket #2290
Excerpts from Marco Pesenti Gritti's message of Tue Sep 07 01:29:30 +0200 2010: > So many reasons to move to introspection :) Then someone should get started on packaging the introspection stuff for Debian, Ubuntu and if necessary Fedora (the distributions supported by sugar-jhbuild). :-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
[Sugar-devel] [PATCH] Increase timeout for buddy properties queries #2298
Signed-off-by: Tomeu Vizoso
---
src/jarabe/model/neighborhood.py | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/jarabe/model/neighborhood.py b/src/jarabe/model/neighborhood.py
index 9ec6322..a457ff7 100644
--- a/src/jarabe/model/neighborhood.py
+++ b/src/jarabe/model/neighborhood.py
@@ -55,6 +55,12 @@ CONNECTION_INTERFACE_BUDDY_INFO =
'org.laptop.Telepathy.BuddyInfo'
CONNECTION_INTERFACE_ACTIVITY_PROPERTIES = \
'org.laptop.Telepathy.ActivityProperties'
+_QUERY_DBUS_TIMEOUT = 200
+"""
+Time in seconds to wait when querying contact properties. Some jabber servers
+will be very slow in returning these queries, so just be patient.
+"""
+
class ActivityModel(gobject.GObject):
__gsignals__ = {
'current-buddy-added': (gobject.SIGNAL_RUN_FIRST,
@@ -544,20 +550,23 @@ class _Account(gobject.GObject):
nick),
error_handler=partial(self.__error_handler_cb,
'BuddyInfo.GetProperties'),
-byte_arrays=True)
+byte_arrays=True,
+timeout=_QUERY_DBUS_TIMEOUT)
connection.GetActivities(
handle,
reply_handler=partial(self.__got_activities_cb,
handle),
error_handler=partial(self.__error_handler_cb,
- 'BuddyInfo.GetActivities'))
+ 'BuddyInfo.GetActivities'),
+timeout=_QUERY_DBUS_TIMEOUT)
connection.GetCurrentActivity(
handle,
reply_handler=partial(self.__get_current_activity_cb,
handle),
error_handler=partial(self.__error_handler_cb,
- 'BuddyInfo.GetCurrentActivity'))
+ 'BuddyInfo.GetCurrentActivity'),
+timeout=_QUERY_DBUS_TIMEOUT)
else:
self.emit('buddy-added', contact_id, nick, None)
--
1.7.2.2
___
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
Excerpts from James Cameron's message of Tue Sep 07 05:03:40 +0200 2010:
> The code may as well have just recursed right where it was; with this
> number of idle tasks there's very little point in using idle tasks.
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).
[Attached patches]
Please use git-send-email to send the patches in the mail body or set
Content-Disposition to inline (Ctrl+D in mutt) to allow easier replying
to the patches in other mail clients.
> -for entry in os.listdir(dir_path):
> +try:
> +entries = os.listdir(dir_path)
> +except:
> +entries = []
> +for entry in entries:
This has been fixed by alsroot in commit 11af549c ("Progress bar for
reading volumes nevers stops if can't read all volume entries #1412")
already, including logging the error to provide at least some (though
rather hidden) indication why the Journal doesn't everything on the
device. That commit looks more invasive than your patch, though.
> +link = os.readlink(full_path)
> +if link == '.':
> +continue
> +if link.startswith('/') and full_path.startswith(link):
> +continue
> +stat = os.stat(full_path)
This will still break for relative links.
The easiest solution is to do the same most other tools do by default:
Ignore symlinked directories. The disadvantage is that the search
pattern won't match paths containing symlinked directories, but only
the real path. It could be argued that this is a rare use case and the
user should use some low-level tool instead in that case since symlinks
are low-level stuff as well.
The alternative is to do the same as "find -L" does (check the dir_ids /
dir_curr handling in find/find.c, especially in process_path()). It
keeps a list of directories (identified by device id and inode number)
that have been visited before in the current branch of the directory
tree (i.e. while traversing down to the current path). If it encounters
a directory twice, there has been a loop and it won't descend again
(but print a warning).
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] Build Squeak VM 4.0.3 from tarfile
On Mon, Sep 6, 2010 at 13:08, Bert Freudenberg wrote:
>
> On 03.09.2010, at 10:47, Tomeu Vizoso wrote:
>
>> On Fri, Sep 3, 2010 at 00:10, Bert Freudenberg wrote:
>>> This is almost the same as my patch from April, which never made it in.
>>> Instead of building from the outdated "olpc" subversion branch, the Squeak
>>> VM is build from a release tarball.
>>> It adds a cmake dependency, and gives an error if make is run without
>>> running autogen.sh first.
>>> Also adds a "clean" make target to please jhbuild.
>>
>> Not sure how relevant it is, but someone at Collabora was adding cmake
>> support to upstream jhbuild recently.
>>
>> http://git.gnome.org/browse/jhbuild/commit/?id=aa564775b5c26527c5ff1d5ad8db8a3565d4dff2
>>
>> Regards,
>>
>> Tomeu
>
> Is this an actual objection? What do I need to do to get this patch accepted?
Was just a comment.
For the others, Bert has been working with Sascha on this on #sugar.
Regards,
Tomeu
> - Bert -
>
>>> Signed-off-by: Bert Freudenberg
>>> ---
>>> config/modulesets/glucose-external.modules | 15 +++-
>>> config/modulesets/patches/squeak-autogen.patch | 28
>>> +++
>>> config/modulesets/patches/squeak-makefile.patch | 11 +
>>> config/sysdeps/debian-family.xml | 1 +
>>> config/sysdeps/fedora-family.xml | 1 +
>>> config/sysdeps/mandrivalinux-2009.1.xml | 1 +
>>> 6 files changed, 51 insertions(+), 6 deletions(-)
>>> create mode 100644 config/modulesets/patches/squeak-autogen.patch
>>> create mode 100644 config/modulesets/patches/squeak-makefile.patch
>>>
>>> diff --git a/config/modulesets/glucose-external.modules
>>> b/config/modulesets/glucose-external.modules
>>> index d76b1f0..0577963 100644
>>> --- a/config/modulesets/glucose-external.modules
>>> +++ b/config/modulesets/glucose-external.modules
>>> @@ -5,8 +5,8 @@
>>> href="git://dev.laptop.org/projects/" />
>>> >> href="git://git.gnome.org"/>
>>> - >> - href="http://squeakvm.org/svn/squeak/branches/";
>>> trunk-template="olpc"/>
>>> + >> + href="http://squeakvm.org/unix/release/"/>
>>> >> href="git://git.imendio.com/projects/"/>
>>> >> @@ -61,10 +61,13 @@
>>>
>>>
>>>
>>> -
>>> -
>>> -
>>> -
>>> +
>>> + >> + repo="squeakvm.org"
>>> +
>>> hash="sha256:87cd3f708cb3d330f6d74931fd7488784f45b0f467f14e2dc6fbdc9d3df97189"
>>> size="3623094">
>>> +
>>> +
>>> +
>>>
>>>
>>>
>>> diff --git a/config/modulesets/patches/squeak-autogen.patch
>>> b/config/modulesets/patches/squeak-autogen.patch
>>> new file mode 100644
>>> index 000..ff9274d
>>> --- /dev/null
>>> +++ b/config/modulesets/patches/squeak-autogen.patch
>>> @@ -0,0 +1,28 @@
>>> +--- /dev/null 2010-09-02 18:58:30.359785873 +0200
>>> autogen.sh 2010-09-02 22:07:35.577316348 +0200
>>> +@@ -0,0 +1,25 @@
>>> ++#!/bin/sh
>>> ++EXCLUDE="gl FileCopyPlugin SqueakFFIPrims B3DAcceleratorPlugin
>>> PseudoTTYPlugin UnixOSProcessPlugin XDisplayControlPlugin"
>>> ++
>>> ++test -d bld || mkdir bld
>>> ++
>>> ++OPTIONS=""
>>> ++for p in $EXCLUDE ; do
>>> ++ OPTIONS="$OPTIONS --without-${p}"
>>> ++done
>>> ++
>>> ++(cd bld && ../unix/cmake/configure $OPTIONS "$@")
>>> ++
>>> ++cat > Makefile <<__EOF__
>>> ++default:
>>> ++ make -C bld
>>> ++
>>> ++install:
>>> ++ make -C bld install
>>> ++
>>> ++check:
>>> ++ �...@echo SKIPPED: No tests defined for Squeak VM
>>> ++
>>> ++clean:
>>> ++ rm -rf bld Makefile
>>> ++__EOF__
>>> diff --git a/config/modulesets/patches/squeak-makefile.patch
>>> b/config/modulesets/patches/squeak-makefile.patch
>>> new file mode 100644
>>> index 000..043dc7d
>>> --- /dev/null
>>> +++ b/config/modulesets/patches/squeak-makefile.patch
>>> @@ -0,0 +1,11 @@
>>> +--- Makefile.orig 2010-09-02 22:11:03.702191222 +0200
>>> Makefile 2010-09-02 22:21:14.580177789 +0200
>>> +@@ -1,7 +1,5 @@
>>> + all : .force
>>> +- test -d bld || mkdir bld
>>> +- (cd bld; ../unix/cmake/configure)
>>> +- (cd bld; make)
>>> ++ �...@test -d bld || (echo ERROR: run autogen.sh first; exit 1)
>>> +
>>> + install : all
>>> + (cd bld; make install)
>>> diff --git a/config/sysdeps/debian-family.xml
>>> b/config/sysdeps/debian-family.xml
>>> index ce11329..9870451 100644
>>> --- a/config/sysdeps/debian-family.xml
>>> +++ b/config/sysdeps/debian-family.xml
>>> @@ -3,6 +3,7 @@
>>>
>>>
>>>
>>> +
>>>
>>>
>>>
>>> diff --git a/config/sysdeps/fedora-family.xml
>>> b/config/sysdeps/fedora-family.xml
>>> index 83ec629..f97efb4 100644
>>> --- a/config/sysdeps/fedora-family.xml
>>> +++ b/config/sysdeps/fedora-family.xml
>>> @@ -7,6 +7,7 @@
>>>
>>>
>>>
>>> +
>>>
>>>
>>>
>>> diff --git a/config/sysdeps/mandrivalinux-2009.1.xml
>>> b/config/sysdeps/mandrivalinux-2009.1.xml
>>> index 0acac46..7fa1131 100644
>>> --- a/config/sysdeps/mandrivalinux-2009.1.xml
>>> +++ b/config/sy
Re: [Sugar-devel] [PATCH] Patch to display 'Sugar inside Xephyr' instead of 'Xephyr on' in the title bar. Ticket #2285
On Sun, Sep 5, 2010 at 18:12, Ishan Bansal wrote:
> This patch is to display 'Sugar inside Xephyr' instead of 'Xephyr on' in the
> title bar of the sugar windows.
> ---
> sugar-0.88-0.88.1/src/jarabe/util/emulator.py | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/sugar-0.88-0.88.1/src/jarabe/util/emulator.py
> b/sugar-0.88-0.88.1/src/jarabe/util/emulator.py
> index 5a99dbe..32ab982 100644
> --- a/sugar-0.88-0.88.1/src/jarabe/util/emulator.py
> +++ b/sugar-0.88-0.88.1/src/jarabe/util/emulator.py
> @@ -36,6 +36,7 @@ def _run_xephyr(display, dpi, dimensions, fullscreen):
> cmd = [ 'Xephyr' ]
> cmd.append(':%d' % display)
> cmd.append('-ac')
> + cmd += ['-title', 'Sugar inside Xephyr']
>
> screen_size = (gtk.gdk.screen_width(), gtk.gdk.screen_height())
>
> --
> 1.7.0.4
For reference: http://bugs.sugarlabs.org/ticket/2285#comment:2
Regards,
Tomeu
> ___
> 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
On Tue, Sep 7, 2010 at 05:03, James Cameron wrote: > I've noticed that on Sugar 0.84 at least, inserting external media such > as a USB HDD, flash drive, or SD card with an entire operating system on > it is an unpleasant experience: > > 1. the progress bar stutters; does not smoothly update, > > 2. the progress bar may not go away, depending on whether the > filesystem contains unreadable directories, (dev.laptop.org #10140) > > 3. the shell.log contains a huge amount of errors. > > The stutter is caused by the overall design ... one pass through the top > level directory is made, then for each directory in that one gobject > idle task is created, and so on recursively. > > On a filesystem containing Ubuntu 10.04, for instance, with 6249 > directories, 48732 files, and 18317 symlinks, the number of gobject idle > tasks reaches several thousand ... each of which are serviced once > before GTK+ is permitted to do a progress bar graphics update. > > The code may as well have just recursed right where it was; with this > number of idle tasks there's very little point in using idle tasks. > > The failure of the progress bar to go away is addressed in one of the > attached patches. It's just a failure to count down, caused by an idle > task throwing an exception without decrementing a counter. > > A cause of the huge amount of errors is the presence of recursive > symlinks: > > /usr/bin/X11 -> . > > ... which causes the scan to iterate through the same directory as many > times as it can until the number of links in the path exceeds some > implementation limit. > > This is addressed in the second of the attached patches. > > Discussion desired. Both look good to me, though I cannot ack for 0.84. I would suggest logging something in the except block, we should do it always when the exception we are bailing out from isn't very specific. Unrelated to these patches, if the idle handlers are indeed preventing the UI from updating then we should lower their priority. Regards, Tomeu > -- > James Cameron > http://quozl.linux.org.au/ > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On 09/07/2010 01:33 AM, Hal Murray wrote: > > d...@laptop.org said: >> When we discussed this while I was in Peru, one requirement they identified >> is that the kid would log onto an XO one day and do some work, and then log >> onto another XO the following week and continue the same work. > >> Assuming this still stands, this strongly calls for a network-based home >> directory system with some kind of network login service (but someone with >> experience in such areas should comment). This would require a number of >> changes at the OS level and server level, but Sugar would be left untouched, >> as far as I can think. > > I think there are two approaches. > > One is for /home to live on the file server and XOs to access their files via > NFS. There may be interesting alternatives to NFS, but I'm not familiar with > any of them. > > The other is to have a working copy of files on the local machine and > manually slosh files back and forth, probably using a program to automate > things. > > I don't think either would be great, but both could probably be made to work. > > Both depend on reasonable network support. Somebody would have to do some > experimenting to see how many users the typical WiFi setup can support. > > [...] > > Here is another alternative... Give each child their own SD card. Patch > Sugar to look there. Or patch the system to mount /home/olpc there. ... From my experience in class, handing out cards/usb sticks to kids is very delicate for the reasons of loosing them or forgetting them at home. Of course you can organize for them to leave them in the school or with the teachers, I just would not let the kids take them home... :) Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Error/Warning Icons for alerts
On 09/06/2010 09:25 PM, Anish Mangal wrote: > On Mon, Sep 6, 2010 at 9:05 PM, Simon Schampijer wrote: >> Hi, >> >> I came across the issue when working on "Error messages when writing to >> device (Journal) [1]": Our alerts (e.g. "Connecting to the school server", >> the error message when you can not copy an item to a removable device...) do >> not have an icon at the left, even though the alert does allow for that. >> >> For the moment we use the emblem-warning (attached) for example in the >> Control Panel for the inline alerts (you have to restart Sugar in order to >> have the changes take effect). >> >> Having an icon with the alert does help learners that can not read yet, or >> simply when the alert is not translated in the specific language yet. I >> guess for the start an icon for warning and one for error would be a good >> start. >> > > +1. I had included an error-icon [1] when the discussion on sl#1842 > was taking place [2]. Gary gave some perspective that might be useful > for this discussion. Anish, thanks for the pointers. Gary is right that once you start adding messages we need to categorize them, what is an error, what a warning. In this particular case we already so this with words error/warning. We can probably adopt other levels of messages (error, warning, info). For 0.92 we might want to make it a bigger effort to define the levels and go through the UI for places where we already have alerts. Notifications play in here as well... For this particular case, I think it is ok to add the icons (at least for 0.84). And designing an icon for error and warning is no lost work, we will need them at some point. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Home button in Browse
On 09/06/2010 09:10 PM, Sascha Silbe wrote: > Excerpts from Simon Schampijer's message of Mon Sep 06 18:24:44 +0200 2010: > Actually I'm surprised it isn't already in Browse. We could add a new Palette (with some "location" / URI related icon) containing reload and go-home. Both are used rarely enough that we don't need them in the main toolbar. >> >> Hmm not sure one could group them like that, I think I would prefer one >> icon each. > > Why not? Reloading the current location (URL) and going to the home > location (URL) are definitely related. I would even consider moving the > bookmark function in there, but expected it to be used often enough to > warrant some dominant place. Same rationale for the go-backward button. > go-forward should stay only for consistency. To me reloading a page and going to a defined page is not related. As this might be a different way of thinking we might be able to find out with a quick user test. Other comments welcome of course. > Adding yet another top-level button for go-home would clutter things > too much IMO. Sure, I am all for not cluttering UI. On the other hand we want to make it discoverable. So we should be careful when we group things together. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Home button in Browse
On 09/06/2010 09:00 PM, Sascha Silbe wrote: > Excerpts from chm's message of Mon Sep 06 18:51:56 +0200 2010: > >>> FWIW you can hold while clicking on the activity to start a new >>> instance instead of resuming the most recent one. >> >> Thanks for the tip. The resume sessions by default >> seems to work better for me when the Activity does >> not have multiple types of sessions so I usually >> want to continue. That is definitely not the case >> with Browse as I usually want the clean start and >> will select another session if I know I am going >> back to previous work... > > We had some ideas on how to improve this during the last design meeting > (quite some time ago), but unfortunately nobody got around to doing any > detailed mock-up yet. Help with this would be very welcome. > > Basically we considered doing an intermediate full-screen chooser after > clicking on an activity icon. It would offer both Start New and a > gallery of existing entries, similar to the (still not merged) grid > view in the Journal. Android or iPad (don't remember which) seems to > be doing something similar. > > Sascha Yes, we were did a lot of work on this one already (including tests that "resume" vs "start new" can not be solved by just switching modes). I think the proposal from Gary is the way to go and it is on my list for 0.92. Regards, Simon [1] http://lists.laptop.org/pipermail/devel/2010-July/029187.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Tue, Sep 7, 2010 at 9:40 AM, Simon Schampijer wrote: > On 09/06/2010 03:40 PM, pbrobin...@gmail.com wrote: >> >> On Mon, Sep 6, 2010 at 2:05 PM, Daniel Drake wrote: >>> >>> On 5 September 2010 13:57, Christoph Derndorfer >>> wrote: Hi, I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get some discussions started on what changes need to be made to Sugar to work well in an environment where multiple users will work on the same machine (which is how Peru's next 300,000 XOs will be used: http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html). Obviously this touches upon a lot of areas from simple naming of the machine, over the Journal, backups and probably a whole host of other issues that I haven't though of yet. >>> >>> When we discussed this while I was in Peru, one requirement they >>> identified is that the kid would log onto an XO one day and do some >>> work, and then log onto another XO the following week and continue the >>> same work. >>> >>> Assuming this still stands, this strongly calls for a network-based >>> home directory system with some kind of network login service (but >>> someone with experience in such areas should comment). This would >>> require a number of changes at the OS level and server level, but >>> Sugar would be left untouched, as far as I can think. >> >> The standard way of doing this in unix is to use nfs and automount >> with NIS/LDAP authentication. This would mount the users home >> directory on login. There's a number of issues that come up with this >> implementation for the XOs in that wireless would need to connect >> prior to this and NFS over wifi would be interesting at best due to >> wifi dropouts. To mitigate that problem you'd probably have to wedge >> some of the caching filesystems that are being developed to allow the >> home directory to be cached. Suddenly your getting a very complex >> solution to fix the problem. > > Yes, this is true. I obviously used wired connections when using LDAP/NFS. > In a lap with fixed equipment this is an easy setup. For the XOs, I agree > this could lead to frustration. (even in my case kids very confused because > someone has pulled the cables) > >> The other possible alternative to this would be to use something like >> couchdb to store the contents of the journal and associated config >> files where you can have a local couchdb that replicates to a remote >> service. This might be the simpler solution but would obviously >> require development. >> >> Peter > > Interesting. A solution where you only need to sync twice (start/stop) might > be better in the wifi environment. It is something that I've been meaning of trying to dogfood as a concept as I think it would be a perfect "cloud" (and yes I frickn hate the term) storage solution for deployments as it allows you to change servers, move storage etc without having to reconfigure the client side. I got as far as setting up the server side of things and playing around with evolution-couchdb for storing evo contacts but no further. There's some glib helper files. I was actually hoping to get more time to play with this more once Fedora 14 / SoaS 4 is out the door. I have some server resources available to set up the server side if anyone else is interested as well. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On 09/06/2010 03:40 PM, pbrobin...@gmail.com wrote: > On Mon, Sep 6, 2010 at 2:05 PM, Daniel Drake wrote: >> On 5 September 2010 13:57, Christoph Derndorfer >> wrote: >>> Hi, >>> >>> I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get >>> some discussions started on what changes need to be made to Sugar to work >>> well in an environment where multiple users will work on the same machine >>> (which is how Peru's next 300,000 XOs will be used: >>> http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html). >>> >>> Obviously this touches upon a lot of areas from simple naming of the >>> machine, over the Journal, backups and probably a whole host of other issues >>> that I haven't though of yet. >> >> When we discussed this while I was in Peru, one requirement they >> identified is that the kid would log onto an XO one day and do some >> work, and then log onto another XO the following week and continue the >> same work. >> >> Assuming this still stands, this strongly calls for a network-based >> home directory system with some kind of network login service (but >> someone with experience in such areas should comment). This would >> require a number of changes at the OS level and server level, but >> Sugar would be left untouched, as far as I can think. > > The standard way of doing this in unix is to use nfs and automount > with NIS/LDAP authentication. This would mount the users home > directory on login. There's a number of issues that come up with this > implementation for the XOs in that wireless would need to connect > prior to this and NFS over wifi would be interesting at best due to > wifi dropouts. To mitigate that problem you'd probably have to wedge > some of the caching filesystems that are being developed to allow the > home directory to be cached. Suddenly your getting a very complex > solution to fix the problem. Yes, this is true. I obviously used wired connections when using LDAP/NFS. In a lap with fixed equipment this is an easy setup. For the XOs, I agree this could lead to frustration. (even in my case kids very confused because someone has pulled the cables) > The other possible alternative to this would be to use something like > couchdb to store the contents of the journal and associated config > files where you can have a local couchdb that replicates to a remote > service. This might be the simpler solution but would obviously > require development. > > Peter Interesting. A solution where you only need to sync twice (start/stop) might be better in the wifi environment. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] giving feedback when a transfer finishes (was Re: #2111 NORM: File Transfer don't work: the transfer never finish)
On 09/06/2010 03:30 PM, Tomeu Vizoso wrote: > Hi, > > Daniel from Uruguay has valuable feedback about the file transfer > functionality. > > How can we make it clearer that a transfer has completed? Or maybe we > don't need to show anything at all and just remove silently the icon > from the frame? > > Regards, > > Tomeu Hey, fresh from the field: I did test the transferring today in my class. I did not tell the kids to dismiss explicitly, none of them did. All the rest (accept/decline) worked fine. If there is no very good reason to have the dismiss, I would vote to remove the icon once finished. Another indicator when finished is the resulting entry in the Journal. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On 09/06/2010 03:05 PM, Daniel Drake wrote: > On 5 September 2010 13:57, Christoph Derndorfer > wrote: >> Hi, >> >> I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get >> some discussions started on what changes need to be made to Sugar to work >> well in an environment where multiple users will work on the same machine >> (which is how Peru's next 300,000 XOs will be used: >> http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html). >> >> Obviously this touches upon a lot of areas from simple naming of the >> machine, over the Journal, backups and probably a whole host of other issues >> that I haven't though of yet. > > When we discussed this while I was in Peru, one requirement they > identified is that the kid would log onto an XO one day and do some > work, and then log onto another XO the following week and continue the > same work. > > Assuming this still stands, this strongly calls for a network-based > home directory system with some kind of network login service (but > someone with experience in such areas should comment). This would > require a number of changes at the OS level and server level, but > Sugar would be left untouched, as far as I can think. > > Daniel So this is basically what I did in my pilot [1]. I used F11, 0.84 on regular laptops and an Xserve that was already handling LDAP and NFS. The changes you need to make on the machines to point to the Server are minimal, Sugar itself stays untouched. And yes you need some login manager. Regards, Simon [1] http://wiki.sugarlabs.org/go/Planetarium/en ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] screenreader for sugar
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 - Plan Ceibal >> >> > Avda. Italia 6201 >> >> > Montevideo - Uruguay. >> >> > Tel.: 2601.57.73 Interno 2228 >> >> > E-mail : ear...@plan.ceibal.edu.uy >> >> > >> >> > >> > >> > >> > >> > -- >> > Esteban Arias >> > Investigación y Desarrollo - Plan Ceibal >> > Avda. Italia 6201 >> > Montevideo - Uruguay. >> > Tel.: 2601.57.73 Interno 2228 >> > E-mail : ear...@plan.ceibal.edu.uy >> > >> > > > > > -- > Esteban Arias > Investigación y Desarrollo - Plan Ceibal > Avda. Italia 6201 > Montevideo - Uruguay. > Tel.: 2601.57.73 Interno 2228 > E-mail : ear...@plan.ceibal.edu.uy > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
