Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Mon, Sep 6, 2010 at 02:24, Samuel Klein meta...@gmail.com wrote: On Sun, Sep 5, 2010 at 5:28 PM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Christoph Derndorfer's message of Sun Sep 05 21:57:09 +0200 2010: 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 ). I don't think we should change anything in Sugar, for two orthogonal reasons: 1. There is already an existing, proven, well-working mechanism to support multiple users on the same machine that's way older than Sugar: user accounts. Check out any computer lab at a university to see how it works (though I suppose you already know). Supporting user accounts is not a novel mechanism, and probably sufficient, but doing it in a Sugar-like way would still benefit from child-focused design and input. It's something that would be good to see as part of / a flavor of Sugar one day, rather than as an external hack by people trying to use Sugar as nature never intended. I'm confused by this, Sugar's architecture follows closely that of other modern X11-based desktops which also means it will just work fine in a multi-user system. Running parallel instances of Sugar each on its own account is something that should be completely supported by Sugar's architecture and not a hack at all. 2. If the Peru government wants Sugar to adapt to being used by multiple users (in what way exactly?), let _them_ do the work. The question of the right way to support multiple users on a single Sugar instance (usb key, computer) is separate from who will do the work. (If OTOH you use one account per child, there's nothing to change in Sugar, so no reason for a ticket). I don't think you can give Sugar an accountname as a startup parameter, so there's at least something to change. When you start Sugar, you are already in an user account, so you don't really need to give it an username. What is going to allow the user to choose an account with which to log in is a display manager and you have several implementations to choose from. All should work fine with Sugar. I believe Simon has used this deployment mode in his pilots in Berlin. Regards, Tomeu PS: I know this kind of setup (some 30 computers for the entire school) from my school days; I've even administered the machines back then. It was called a computer room (we had two of them). I think you can guess how much time most pupils spent in there outside of special computer (i.e. word processing etc.) classes? Computer use in regular subjects was close to zero, similar to our fancy language lab (a class room with tape recorders built into desktops) which we used a whopping two times during my entire school life. I had similar experiences, though they were well used by a few students. I'd like to hear more details about what Peru is planning - which sounds more like a fixed group sharing a computer than that sort of traditional 'lab'. SJ -- Samuel Klein identi.ca:sj w:user:sj ___ 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 Fri, Sep 3, 2010 at 19:48, Martin Langhoff mar...@laptop.org wrote: On Fri, Sep 3, 2010 at 12:43 PM, Tomeu Vizoso to...@sugarlabs.org 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. 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] Stability stuff
On Fri, Sep 3, 2010 at 23:59, Bernie Innocenti ber...@codewiz.org wrote: El Fri, 03-09-2010 a las 11:23 -0400, Martin Abente escribió: Well, thats true in theory, assuming all the activities are properly designed for sugar. In the field you already know thats not the case. Also... even when the activities are being implemented in python through the Activity Class, the read and write methods needs to be implemented by the programmer. That means it depends on the activity specifics again. Yes, but if an activity fails to save when Sugar asks it to quit, then it's already buggy today: we also have a Stop item in the menu of the activity frame icon. This is also a very good suggestion. We could start by doing this, which is a lot easier and almost equally effective. I see it this way: Why waiting to get sick to do something about it. Preventive medicine is always better. Why waiting for the machine to freeze (waiting 3 or more minutes until its back to a usable state again) to do something about it, also with potential data loss. Having a message telling kids that the machine is too overloaded should be enough, with recommendations about saving any current work and closing earlier activities. This kind of mechanisms should help to the overall stability, and it makes even more sense when you think about XO's 1 scenarios. :) Yes, I already agreed with you on this. The hard part of this patch would be setting a threshold to disallow opening another activity. Memory footprint of activities varies wildly. Shall we take the worst case, pissing off users who knew what they were doing, or shall we be optimistic, risking the current behavior in some cases? If we also had both the graceful stop on oom that I was thinking of, we could afford to be be optimistic in the oom prevention code. Anyway, for now I'd vote for doing what you suggest in the easiest possible way even if it saves the system only 50% of the times. It would still be a huge improvement upon the current behavior. Whatever we end up doing, we should not leave much chance of undercalculating the available memory of we may render Sugar mostly useless. This remembers me when we deployed the free-space warning and users were able to get into situations where they could not use Sugar because of not enough space but also couldn't remove stuff. Regards, Tomeu -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Review of patch submitted by Martin for bug #2087
On Sat, Sep 4, 2010 at 22:20, Aleksey Lim alsr...@member.fsf.org wrote: On Sat, Sep 04, 2010 at 05:13:03PM +0200, Sascha Silbe wrote: Excerpts from Kandarp Kaushik's message of Sat Sep 04 16:16:57 +0200 2010: [data/sugar.schemas.in] + locale name=C + shortProtected Activities Bundle Indentifiers/short Typo. Also a bit hard to understand. Something along the lines of Bundle IDs of protected activities might be better. + longUsers will not be allowed to erase these + activities through the list view./long [src/jarabe/desktop/activitieslist.py] + if activity_info.is_user_activity() and \ + not registry.is_activity_protected(self._bundle_id): + 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 This is getting convoluted. Please factor it out and turn your condition into one or several guards [1]. E.g.: def _add_erase_option(self, activity_info): if not activity_info.is_user_activity(): return if registry.is_activity_protected(self._bundle_id): return # show menu item etc. A suitable docstring is left as an exercise for the reader. ;) [src/jarabe/model/bundleregistry.py] + client = gconf.client_get_default() + self._protected_activities = client.get_list('/desktop/sugar/protected_activities', + gconf.VALUE_STRING) I have a feeling this will break badly if the GConf value is not set. See #1147 [2] for a similar case. I've found that there is no way to call has() method(all sugar code calls get_* methods w/o any checks). If everything is installed, we will get key value in any case (default from shcheme), but if installation is inproper... I've managed to coredump python for unknow keys. This is really bad and should be fixed inside GConf (though I think anyway Sugar should be able to deal with incorrect gconf values). That said, it may be more practical to deal with this problem when we move to GSettigns/dconf, though that really depends on how many resources are put into this issue. Regards, Tomeu And please don't indent this much for a continuation. Personally I'd use regular indentation (i.e. four spaces); maybe Tomeu can state his preference so we can agree on some guideline. PS: Please use git-send-email or some equivalent method of sending patches. Your message has had at least one line of the patch wrapped; I would have been unable to try out the patch (because it wouldn't apply). Sascha [1] http://en.wikipedia.org/wiki/Guard_(computing) [2] https://bugs.sugarlabs.org/ticket/1147 -- 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 -- Aleksey ___ 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] Alt + Tab issue on sugar-emulator
On Sun, Sep 5, 2010 at 21:31, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Dipankar Patro's message of Sun Sep 05 20:34:55 +0200 2010: I was unable to reproduce the bug because the 'Alt + Tab' function doesn't work in Sugar on Ubuntu (Neither in emulator nor in Sugar-Session). That's probably due to the same bug I've hit on Debian and Bernie before me on Fedora 11. Also note that Xephyr has been almost fully rewritten lately and is now kind-of-maintained again. So may make sense to just update to a recent version. Regards, Tomeu He wrote a patch [1] for metacity that fixes it. ISTR Bernie saying something about some other component (X server?) being broken and this being just a workaround. Since I don't know any details and don't quite understand the change, I haven't filed a bug report at Debian yet. I probably should have reported it and let the maintainer sort out who actually is to blame. They could at least ship the patch for the time being. So feel free to open a ticket on Debian. The problem with sugar-emulator: Somehow the native X sessions' priority is higher then Xephyr's. So even if the function for 'Alt+Tab' is coded into Sugar. The emulator (on Xephyr) still won't be able to catch that. If Xephyr has a global keyboard grab, it will get any keyboard event, including Alt-Tab (and anything else your window manager might catch otherwise). You can toggle the global keyboard and mouse grab by pressing Ctrl+Shift, like it tells you in the Xephyr title bar. VNC acquires a global keyboard grab iff running in full screen mode. Aleksey suggested we have to disable the 'Alt+Tab' combination in Sugar-Emulator. What do you mean? Sascha [1] http://sascha.silbe.org/patches/metacity-ungrab-keybindings.patch -- 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
[Sugar-devel] requesting reviews
Hi, please don't submit the same patch for review to both trac and the mailing list, otherwise the review discussion bifurcates. Thanks, Tomeu ___ 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 Mon, Sep 6, 2010 at 9:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote: I don't think you can give Sugar an accountname as a startup parameter, so there's at least something to change. When you start Sugar, you are already in an user account, so you don't really need to give it an username. What is going to allow the user to choose an account with which to log in is a display manager and you have several implementations to choose from. All should work fine with Sugar. Hi, the display manager look and feel should integrate well with the rest of the UI. We could pick a suggested dm and provide an upstream theme for it. Not sure how account name and sugar nick name should interact. Ideally they would be the same I think, but then you can't change the name easily. Finally account management is going to be tricky because it requires privileges and deployment requirements may vary. Marco ___ 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 Mon, Sep 6, 2010 at 10:05 AM, Marco Pesenti Gritti ma...@marcopg.org wrote: Not sure how account name and sugar nick name should interact. Ideally they would be the same I think, but then you can't change the name easily. A possible approach might be sugar nick name == account full name. I think at least gdm has a way to show full name instead of user name. Marco ___ 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
Excerpts from Samuel Klein's message of Mon Sep 06 02:24:28 +0200 2010: Supporting user accounts is not a novel mechanism, and probably sufficient, but doing it in a Sugar-like way would still benefit from child-focused design and input. While a display manager similar in (graphical) design to Sugar might be done by a member of Sugar Labs, it's still entirely separate from the software component Sugar. 2. If the Peru government wants Sugar to adapt to being used by multiple users (in what way exactly?), let _them_ do the work. The question of the right way to support multiple users on a single Sugar instance (usb key, computer) is separate from who will do the work. Which is why I said those are orthogonal reasons. I had similar experiences, though they were well used by a few students. I'd like to hear more details about what Peru is planning - which sounds more like a fixed group sharing a computer than that sort of traditional 'lab'. +1 on hearing more details before trying to reinvent the wheel. 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] Patch to display 'Sugar inside Xephyr' instead of 'Xephyr on' in the title bar. Ticket #2285
On Sun, Sep 5, 2010 at 5:12 PM, Ishan Bansal is...@seeta.in 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'] Looks fine to me. I would change the appends to use += too for consistency. (Ideally we would translate this but it's probably too much trouble) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] requesting reviews
On Mon, Sep 6, 2010 at 10:00 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, please don't submit the same patch for review to both trac and the mailing list, otherwise the review discussion bifurcates. I would add this to http://wiki.sugarlabs.org/go/Talk:Development_Team/Code_Review in the paragraph about old workflow. Marco ___ 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 Sun, Sep 5, 2010 at 3:44 PM, Dipankar Patro dipan...@seeta.in wrote: Hi, In reference to ticket #2290 (http://bugs.sugarlabs.org/ticket/2290) I have uploaded a patch (have attached it too). Problem: in the register procedure the time out of connection was not implemented, for an unavailable server. Solution in Patch: - Have implemented a TimedOut connection (TimedOutServerProxy( ) function) which encounters the problem of unavailable servers. - The connection timeout can be changed in seconds through the variable : 'timeout'. The default setting is at : timeout=socket._GLOBAL_DEFAULT_TIMEOUT Change it to : timeout=10, to find Sugar does not freeze anymore. How long is the default timeout? Are we freezing because we are doing the xmlrpc requests synchronously? Marco ___ 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
Excerpts from Marco Pesenti Gritti's message of Mon Sep 06 11:05:07 +0200 2010: Not sure how account name and sugar nick name should interact. Ideally they would be the same I think, but then you can't change the name easily. I'd treat the user account name as an internal implementation detail like the Jabber user name (all OLPC builds use olpc as the account name as you are probably aware). The equivalent of changing the Jabber nick name is adjusting the GECOS field: sascha.si...@twin:~$ chfn -f 'Sascha Silbe (Sugar Labs Oompa-Loompa extraordinaire)' chfn: Permission denied. OK, well, you need to fix /etc/login.defs first. :) sascha.si...@twin:~$ chfn -f 'Sascha Silbe (Sugar Labs Oompa-Loompa extraordinaire)' Password: sascha.si...@twin:~$ We already pull from GECOS on first login (unless turned off via GConf); keeping GECOS and nick name synchronised would be the next logical step (independent of anything Peru is doing). 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 Mon, Sep 6, 2010 at 11:51, Marco Pesenti Gritti ma...@marcopg.org wrote: On Sun, Sep 5, 2010 at 3:44 PM, Dipankar Patro dipan...@seeta.in wrote: Hi, In reference to ticket #2290 (http://bugs.sugarlabs.org/ticket/2290) I have uploaded a patch (have attached it too). Problem: in the register procedure the time out of connection was not implemented, for an unavailable server. Solution in Patch: - Have implemented a TimedOut connection (TimedOutServerProxy( ) function) which encounters the problem of unavailable servers. - The connection timeout can be changed in seconds through the variable : 'timeout'. The default setting is at : timeout=socket._GLOBAL_DEFAULT_TIMEOUT Change it to : timeout=10, to find Sugar does not freeze anymore. How long is the default timeout? Are we freezing because we are doing the xmlrpc requests synchronously? Previous discussion is actually in http://bugs.sugarlabs.org/ticket/2289 and not in #2290. Looks like we cannot do XML-RPC with GIO because it doesn't support POST for http requests. The right component in our stack would be libsoup but we find again that we need introspection to use it because nobody cared to write, maintain and package python bindings for it. This makes xmlrpclib usage async, but it also uses private API: http://www.mail-archive.com/py...@daa.com.au/msg12971.html So maybe the best we can do for now is indeed setting a timeout. Regards, Tomeu Marco ___ 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] Alt + Tab issue on sugar-emulator
Excerpts from Tomeu Vizoso's message of Mon Sep 06 10:46:43 +0200 2010: [Alt-Tab doesn't work] That's probably due to the same bug I've hit on Debian and Bernie before me on Fedora 11. Also note that Xephyr has been almost fully rewritten lately and is now kind-of-maintained again. So may make sense to just update to a recent version. This bug occurs in native sessions (i.e. regular X server) as well (which is the reason I patched metacity at all - Xephyr is so broken for me that I wouldn't even notice Alt-Tab not working). 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] Enhancing Sugar to support multiple users
Excerpts from Marco Pesenti Gritti's message of Mon Sep 06 11:11:53 +0200 2010: A possible approach might be sugar nick name == account full name. I think at least gdm has a way to show full name instead of user name. (At least) KDM can even show pictures for each user = XO icons. But since AFAIK there's no standard on where to put these and in which format, I'd definitely leave this integration issue up to the integrators i.e. distributions and their downstreams. 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] Bug tracking Vs Patch review
Excerpts from Bert Freudenberg's message of Thu Sep 02 23:28:39 +0200 2010: On Fedora 13, git-send-email is not requires by sugar-jhbuild. If this is the official way to submit patches, then git-email should be added to sysdeps. Added (on all distros). 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 03.09.2010, at 10:47, Tomeu Vizoso wrote: On Fri, Sep 3, 2010 at 00:10, Bert Freudenberg b...@freudenbergs.de 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? - Bert - Signed-off-by: Bert Freudenberg b...@freudenbergs.de --- 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/ / repository type=git name=git.gnome.org href=git://git.gnome.org/ - repository type=svn name=squeakvm.org -href=http://squeakvm.org/svn/squeak/branches/; trunk-template=olpc/ + repository type=tarball name=squeakvm.org + href=http://squeakvm.org/unix/release// repository type=git name=git.imendio.com href=git://git.imendio.com/projects// repository type=tarball name=telepathy @@ -61,10 +61,13 @@ dep package=abiword/ /dependencies /tarball - autotools id=squeak -branch repo=squeakvm.org module=olpc checkoutdir=squeak/ -dependencies -/dependencies + autotools id=squeak autogen-template=/bin/sh autogen.sh --prefix=%(prefix)s +branch module=Squeak-4.0.3.2200-src.tar.gz version=4.0.3.2200 + repo=squeakvm.org + hash=sha256:87cd3f708cb3d330f6d74931fd7488784f45b0f467f14e2dc6fbdc9d3df97189 size=3623094 + patch file=squeak-autogen.patch strip=0 / + patch file=squeak-makefile.patch strip=0 / +/branch /autotools autotools id=hulahop branch module=hulahop/mainline.git checkoutdir=hulahop/ 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 @@ package name=automake1.9/ package name=avahi-daemon/ package name=avahi-autoipd/!-- for ad-hoc network support -- + package name=cmake/ package name=evince/ package name=g++/ package name=gcc/ 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
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Mon, Sep 06, 2010 at 12:53:23PM +0200, Sascha Silbe wrote: (At least) KDM can even show pictures for each user = XO icons. But since AFAIK there's no standard on where to put these and in which format, I'd definitely leave this integration issue up to the integrators i.e. distributions and their downstreams. Agreed, this is a downstream integration issue, not a Sugar issue. See also The GDM Face Browser. http://library.gnome.org/admin/gdm/stable/overview.html.en Both KDM and GDM appear to handle ~/.face.icon so a simple way to achieve something useful might be to have Sugar write this file (if it previously wrote the file) when the colour choice is changed in the control panel. Sugar currently does not maintain an image avatar for users, in the way that other social networking or instant messaging systems do, but I would not be surprised to find a demand for that somewhen. -- 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] git send-email (was: Re: Bug tracking Vs Patch review)
Excerpts from Bert Freudenberg's message of Fri Sep 03 00:06:23 +0200 2010: Also, mail sent this way gets blocked, see below. I'll send it again using my regular mailer. There are two issues: 1. You are a second class internet citizen (dial-up), so you need to relay your mails via a first class citizen (provider, e.g. your ISP). 2. You haven't set up git-email correctly: user.email isn't set. IIRC it should have told you that when sending. It's falling back to account name@host name which won't work on the majority of boxes. We (= not me ;) ) should look for and link to a good tutorial explaining how to set up and use git send-email. If anyone has difficulty getting it to work with their provider, we can set up an SMTP relay for sugarlabs.org (authenticated SMTP, port 587). For reference, here's my ~/.gitconfig: === Begin === [user] email = sascha-...@silbe.org name = Sascha Silbe [url gitori...@git.sugarlabs.org:] pushInsteadOf = git://git.sugarlabs.org/ [alias] send-to-ml-multi = !git send-email -s --annotate --summary --cover-letter --add-header=\Reply-To: Sascha Silbe sascha-ml-reply-to-$(python -c 'import time; t=time.gmtime(); print \%d-%d\ % (t.tm_year, t.tm_mon//4+1)')@silbe.org\ send-to-ml-single = !git send-email -s -p --stat --add-header=\Reply-To: Sascha Silbe sascha-ml-reply-to-$(python -c 'import time; t=time.gmtime(); print \%d-%d\ % (t.tm_year, t.tm_mon//4+1)')@silbe.org\ # tg mail doesn't use format-patch, so add-header doesn't work :( # tg-send-to-ml-single = !tg mail -s \-p --stat --add-header=\\\Reply-To: Sascha Silbe sascha-ml-reply-to-$(python -c 'import time; t=time.gmtime(); print \%d-%d\ % (t.tm_year, t.tm_mon//4+1)')@silbe.org tg-send-to-ml-single = !tg mail -s \-p --stat --annotate\ [sendemail] from = Sascha Silbe sascha-...@silbe.org chainreplyto = false signedoffcc = false suppressfrom = true confirm = always suppresscc = all [color] diff = auto [diff] renames = copies === End 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] Bug tracking Vs Patch review
Excerpts from Gonzalo Odiard's message of Thu Sep 02 22:49:46 +0200 2010: The ticket must be closed in Trac when the code its commited? In general, yes. We consider it fixed when the code is in git. The ticket might be kept open if it's going to be backported to some previous version (keywords olpc-0.84 resp. dextrose I think) or if the patch is just a temporary workaround. Other organisations have a more complicated process that keeps on tracking the status until the fix is in a release / at the user, but I don't think we have anyone willing to do the extra work. I haven't seen the backporters (maintainers of 0.84 and 0.88 branches) asking for a better way to track what they need to backport, so I guess everyone is happy with the process so far (except for the patch review, but that's a separate issue). 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] Sugar 0.88 doesn report all favourite connections to NetworkManager at startuo
Hi list, While making mods to NM autoconnection feature I've come across a weird behaviour from the favourites connections (/home/olpc/.sugar/ connections.cfg) reported to NetworkManager at startup. What I've seen is that -only at startup- just one connection gets reported to real_get_best_autoconnection (a function within nm-device-wifi.c), thus being this one the one that gets chosen by NM (if there's an AP that matches it). At first I thought it was that the wireless scans did not report all the APs within range, but later -by debugging the program I found out that only one favourite connection was reported (from several in connections.cfg) and all APs where seen. This behaviour doesn't repeat itself if the autoconnection feature gets executed after this first time. I've already opened a ticket in sugar's track, that is waiting to be accepted. This happened with sugar 0.88 [Dextrose] and NetworkManager 0.7.2.997, on the XO 1. Any ideas on what might be causing this? Thanks for everything. Cheers -- 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] git send-email (was: Re: Bug tracking Vs Patch review)
On 06.09.2010, at 13:23, Sascha Silbe wrote: Excerpts from Bert Freudenberg's message of Fri Sep 03 00:06:23 +0200 2010: Also, mail sent this way gets blocked, see below. I'll send it again using my regular mailer. There are two issues: 1. You are a second class internet citizen (dial-up), so you need to relay your mails via a first class citizen (provider, e.g. your ISP). 2. You haven't set up git-email correctly: user.email isn't set. IIRC it should have told you that when sending. Actually my mail address was set in git, and used correctly as you can see in the bounce report. It's falling back to account name@host name which won't work on the majority of boxes. No, that's just sendmail, which doesn't know or respect the mail address given to git. It's true I did not configure sendmail in that Linux machine. Instead it used a direct SMTP connection but was blocked by paranoid mail receivers. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
On Mon, Sep 6, 2010 at 13:33, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Gonzalo Odiard's message of Thu Sep 02 22:49:46 +0200 2010: The ticket must be closed in Trac when the code its commited? In general, yes. We consider it fixed when the code is in git. The ticket might be kept open if it's going to be backported to some previous version (keywords olpc-0.84 resp. dextrose I think) or if the patch is just a temporary workaround. Other organisations have a more complicated process that keeps on tracking the status until the fix is in a release / at the user, but I don't think we have anyone willing to do the extra work. Downstreams could do this, but then it may be better to have them using a separate tracker or things will get quite messy. Regards, Tomeu I haven't seen the backporters (maintainers of 0.84 and 0.88 branches) asking for a better way to track what they need to backport, so I guess everyone is happy with the process so far (except for the patch review, but that's a separate issue). 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] Enhancing Sugar to support multiple users
On 5 September 2010 13:57, Christoph Derndorfer christoph.derndor...@gmail.com 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 ___ 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
Excerpts from James Cameron's message of Mon Sep 06 13:18:20 +0200 2010: [XO icons in display manager] http://library.gnome.org/admin/gdm/stable/overview.html.en Both KDM and GDM appear to handle ~/.face.icon [...] Interesting, thanks for the pointer! Given that there actually is some kind of standard, we could even include it upstream. Sugar currently does not maintain an image avatar for users, in the way that other social networking or instant messaging systems do, but I would not be surprised to find a demand for that somewhen. The Sugar source code has comments indicating that this was planned (and maybe even in some prototype), but never finished. Given that as of 0.90 Sugar is a regular Telepathy client, it shouldn't be hard to add (mostly a UI issue). 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] Re: [PATCH] Protected-Activities-Support.3
On Sat, Sep 4, 2010 at 22:18, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Kandarp Kaushik's message of Sat Sep 04 21:41:10 +0200 2010: Thanks for submitting the patch with git send-email, I could apply it now. Please: - test your patch before submitting it (there's a syntax error) - provide a useful subject and description - fix the white space errors (I recommend using git config --global color.diff auto to enable diff coloring) - adjust the _add_erase_option() docstring: only user activities (i.e. those in ~/Activities) can be removed at all, so user or unprotected activities doesn't make sense. On the ticket [1] Gary suggested to deactivate (instead of remove) the Erase option for protected activities (like we're already doing for system activities). +1 from me, but maybe someone else from the design team wants to chime in. Hi Design team, Any preference for disabling or removing options in palettes that are not activable in a specific moment? Regards, Tomeu Sascha [1] https://bugs.sugarlabs.org/ticket/2087 -- 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
[Sugar-devel] [DESIGN] giving feedback when a transfer finishes (was Re: #2111 NORM: File Transfer don't work: the transfer never finish)
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 On Mon, Sep 6, 2010 at 15:17, Sugar Labs Bugs bugtracker-nore...@sugarlabs.org wrote: #2111: File Transfer don't work: the transfer never finish +--- Reporter: Dcastelo | Owner: tomeu Type: defect | Status: new Priority: Normal | Milestone: 0.88.x Component: sugar | Version: 0.88.x Severity: Unspecified | Keywords: r? Distribution: OLPC | Status_field: Assigned +--- Comment(by Dcastelo): Ok, I think that I made a mistake when i applied/tested the patch before, I tested it again and if user clicks Dismiss the palette is closed. Another mistake was that I forgot my original report and I changed the palette behaviour to hide it without user intervention. :) However I think that is not clear for user, talking with teachers here in Uruguay they prefer remove the palette without user intervention (the patch that i sent), or modify the palette for express that the transfer is complete in a clearly way. Maybe is just a problem with the dismiss label text, maybe if we show in this label Transfer Complete will be more clear for users. -- Ticket URL: http://bugs.sugarlabs.org/ticket/2111#comment:8 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] git send-email
Excerpts from Bert Freudenberg's message of Mon Sep 06 14:10:50 +0200 2010: 2. You haven't set up git-email correctly: user.email isn't set. IIRC it should have told you that when sending. Actually my mail address was set in git, and used correctly as you can see in the bounce report. Ah, you're right. It seems git send-email leaves it up to the MTA to choose the enveloper sender by default, relying on the latter being configured appropriately. Please try setting sendemail.envelopesender to auto. That should cause git send-email to specify the address from the From: header as envelope sender. Your other issue (dial-up) is independent of that, of course. BTW: sas...@silbe.org usually only receives SPAM, so it's easy for me to overlook any legitimate mail sent their. Please use my Sugar Labs address (silbe@) instead if you'd like to contact me privately. For patches sent to sugar-devel it isn't necessary. 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] Enhancing Sugar to support multiple users
On Mon, Sep 6, 2010 at 2:05 PM, Daniel Drake d...@laptop.org wrote: On 5 September 2010 13:57, Christoph Derndorfer christoph.derndor...@gmail.com 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. 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Home button in Browse
Hi, I can well imagine there had been several discussions about this before, even so a quick search of the archives did not reveal something: Deployment(s) have been asking how to go back to the home page (OLPC start page / Sugar Labs start page) in the Browse activity. I think in 0.84, as we resume by default, we see more learners to have problems with that, because in 0.82 we did start a new session when clicking on the activity icon, hence the Browse activity came up with the starting page in most cases. I would say, adding a button that brings you back to the defined default page would be a good addition. There is even an icon in artwork already (attached) :) What do others think? Thanks in advance for your feedback, Simon attachment: go-home.svg___ 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 6 September 2010 15:25, Simon Schampijer si...@schampijer.de wrote: Hi, I can well imagine there had been several discussions about this before, even so a quick search of the archives did not reveal something: Deployment(s) have been asking how to go back to the home page (OLPC start page / Sugar Labs start page) in the Browse activity. I think in 0.84, as we resume by default, we see more learners to have problems with that, because in 0.82 we did start a new session when clicking on the activity icon, hence the Browse activity came up with the starting page in most cases. I would say, adding a button that brings you back to the defined default page would be a good addition. There is even an icon in artwork already (attached) :) What do others think? Thanks in advance for your feedback, Simon Sounds good to me. I'm just a bit worried that the toolbar is getting ever more crowded, now with new tabs and whatnot. ___ 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 10:14 AM, Tomeu Vizoso wrote: On Mon, Sep 6, 2010 at 02:24, Samuel Kleinmeta...@gmail.com wrote: On Sun, Sep 5, 2010 at 5:28 PM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Christoph Derndorfer's message of Sun Sep 05 21:57:09 +0200 2010: 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 ). I don't think we should change anything in Sugar, for two orthogonal reasons: 1. There is already an existing, proven, well-working mechanism to support multiple users on the same machine that's way older than Sugar: user accounts. Check out any computer lab at a university to see how it works (though I suppose you already know). Supporting user accounts is not a novel mechanism, and probably sufficient, but doing it in a Sugar-like way would still benefit from child-focused design and input. It's something that would be good to see as part of / a flavor of Sugar one day, rather than as an external hack by people trying to use Sugar as nature never intended. I'm confused by this, Sugar's architecture follows closely that of other modern X11-based desktops which also means it will just work fine in a multi-user system. Running parallel instances of Sugar each on its own account is something that should be completely supported by Sugar's architecture and not a hack at all. 2. If the Peru government wants Sugar to adapt to being used by multiple users (in what way exactly?), let _them_ do the work. The question of the right way to support multiple users on a single Sugar instance (usb key, computer) is separate from who will do the work. (If OTOH you use one account per child, there's nothing to change in Sugar, so no reason for a ticket). I don't think you can give Sugar an accountname as a startup parameter, so there's at least something to change. When you start Sugar, you are already in an user account, so you don't really need to give it an username. What is going to allow the user to choose an account with which to log in is a display manager and you have several implementations to choose from. All should work fine with Sugar. I believe Simon has used this deployment mode in his pilots in Berlin. Regards, Tomeu Yes, we [1] use GDM to login. The school server uses the school's LDAP server to authenticate the learner. NFS is used to bind network drives; hence to make the learner's Sugar profile available. So either you have several accounts on one machine or you use a remote authentication system. 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] [DESIGN] Home button in Browse
On 09/06/2010 04:27 PM, Lucian Branescu wrote: On 6 September 2010 15:25, Simon Schampijersi...@schampijer.de wrote: Hi, I can well imagine there had been several discussions about this before, even so a quick search of the archives did not reveal something: Deployment(s) have been asking how to go back to the home page (OLPC start page / Sugar Labs start page) in the Browse activity. I think in 0.84, as we resume by default, we see more learners to have problems with that, because in 0.82 we did start a new session when clicking on the activity icon, hence the Browse activity came up with the starting page in most cases. I would say, adding a button that brings you back to the defined default page would be a good addition. There is even an icon in artwork already (attached) :) What do others think? Thanks in advance for your feedback, Simon Sounds good to me. I'm just a bit worried that the toolbar is getting ever more crowded, now with new tabs and whatnot. I see your concern, though I think one more button is fine. They always say just one more... :) 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
+1 We don't have other view of the library right now. Gonzalo On Mon, Sep 6, 2010 at 11:25 AM, Simon Schampijer si...@schampijer.dewrote: Hi, I can well imagine there had been several discussions about this before, even so a quick search of the archives did not reveal something: Deployment(s) have been asking how to go back to the home page (OLPC start page / Sugar Labs start page) in the Browse activity. I think in 0.84, as we resume by default, we see more learners to have problems with that, because in 0.82 we did start a new session when clicking on the activity icon, hence the Browse activity came up with the starting page in most cases. I would say, adding a button that brings you back to the defined default page would be a good addition. There is even an icon in artwork already (attached) :) What do others think? Thanks in advance for your feedback, 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] [DESIGN] Error/Warning Icons for alerts
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. What do others think? Thanks in advance for your feedback, Simon [1] http://dev.laptop.org/ticket/10312 attachment: emblem-warning.svg___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Home button in Browse
Excerpts from Simon Schampijer's message of Mon Sep 06 16:25:03 +0200 2010: I would say, adding a button that brings you back to the defined default page would be a good addition. There is even an icon in artwork already (attached) :) 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. 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] Home button in Browse
On 06.09.2010, at 17:50, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Mon Sep 06 16:25:03 +0200 2010: I would say, adding a button that brings you back to the defined default page would be a good addition. There is even an icon in artwork already (attached) :) 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. Go-home would be the button I press most often, to counteract auto-resuming. - Bert - ___ 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 6 September 2010 16:53, Bert Freudenberg b...@freudenbergs.de wrote: On 06.09.2010, at 17:50, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Mon Sep 06 16:25:03 +0200 2010: I would say, adding a button that brings you back to the defined default page would be a good addition. There is even an icon in artwork already (attached) :) 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. Yeah. And I should probably make a new toolbar with all the tab buttons that Terminal has. Go-home would be the button I press most often, to counteract auto-resuming. - Bert - Wouldn't a clearer explanation of auto-resuming in the UI be a better fix to this particular issue? ___ 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 05:53 PM, Bert Freudenberg wrote: On 06.09.2010, at 17:50, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Mon Sep 06 16:25:03 +0200 2010: I would say, adding a button that brings you back to the defined default page would be a good addition. There is even an icon in artwork already (attached) :) 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. Go-home would be the button I press most often, to counteract auto-resuming. This sounds like a fallen hint what you think about auto resume (at least in Browse) ;D I agree with Lucian, this should be fixed somewhere else (if). 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
Excerpts from Bert Freudenberg's message of Mon Sep 06 17:53:41 +0200 2010: Go-home would be the button I press most often, to counteract auto-resuming. FWIW you can hold Alt while clicking on the activity to start a new instance instead of resuming the most recent one. 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] ticket:305
Hi all, I am working on bug http://bugs.sugarlabs.org/ticket/305. I have identified the part of code where the changes have to made. I have committed the required changes in sugar-jhbuild present on my system. Can anyone guide me on how we can test the changes made by running sugar-emulator using sugar-jhbuild. I did run the following commands after making the changes in the code - 1. ./sugar-jhbuild build 2. ./sugar-jhbuild run sugar-emulator For reference i have attached the link to the part of file where i think the changes have to be made http://pastebin.com/0wxLhZ1u (the file can be also viewed by- sugar-jhbuild/source/sugar-artwork/gtk/theme/sugar-100.gtkrc) Regards ishan ___ 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 9/6/2010 12:34 PM, Sascha Silbe wrote: Excerpts from Bert Freudenberg's message of Mon Sep 06 17:53:41 +0200 2010: Go-home would be the button I press most often, to counteract auto-resuming. FWIW you can holdAlt 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... --Chris ___ 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
Sorry for that duplicate bug. Missed out that lfaraone already filed the bug. I have attached the revised patch. (uploaded at bugs.sl.o too) * changed things (subject, description, etc) according to Sascha Silbe's suggestions. @ Marco : The default timeout is way too long (unable to find out exact time). Yes, the process is synchronous, thats why Sugar is freezing. @ Tomeu: Thanks for the review. Will try to get the registration process asynchronous. Regards, Dipankar On Mon, Sep 6, 2010 at 4:12 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 6, 2010 at 11:51, Marco Pesenti Gritti ma...@marcopg.org wrote: On Sun, Sep 5, 2010 at 3:44 PM, Dipankar Patro dipan...@seeta.in wrote: Hi, In reference to ticket #2290 (http://bugs.sugarlabs.org/ticket/2290) I have uploaded a patch (have attached it too). Problem: in the register procedure the time out of connection was not implemented, for an unavailable server. Solution in Patch: - Have implemented a TimedOut connection (TimedOutServerProxy( ) function) which encounters the problem of unavailable servers. - The connection timeout can be changed in seconds through the variable : 'timeout'. The default setting is at : timeout=socket._GLOBAL_DEFAULT_TIMEOUT Change it to : timeout=10, to find Sugar does not freeze anymore. How long is the default timeout? Are we freezing because we are doing the xmlrpc requests synchronously? Previous discussion is actually in http://bugs.sugarlabs.org/ticket/2289 and not in #2290. Looks like we cannot do XML-RPC with GIO because it doesn't support POST for http requests. The right component in our stack would be libsoup but we find again that we need introspection to use it because nobody cared to write, maintain and package python bindings for it. This makes xmlrpclib usage async, but it also uses private API: http://www.mail-archive.com/py...@daa.com.au/msg12971.html So maybe the best we can do for now is indeed setting a timeout. Regards, Tomeu Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel From a2cf4863eca617bcd57008730e13ab8af95e7cfa Mon Sep 17 00:00:00 2001 From: Dipankar Patro dipan...@seeta.in Date: Mon, 6 Sep 2010 21:42:51 +0530 Subject: [PATCH] Register widget click event reflects a timeout on unavailability of servers [Ticket #2289] The register widget when clicked, used to cause sugar to freeze. Added a timeout facilitated ServerProxy() so that connection to schoolserver is dropped in case it is not available. --- src/jarabe/desktop/schoolserver.py | 28 ++-- 1 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/jarabe/desktop/schoolserver.py b/src/jarabe/desktop/schoolserver.py index 62519df..e60e26f 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 @@ -76,6 +77,29 @@ 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 __init__(self, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, *args, **kwargs): +xmlrpclib.Transport.__init__(self, *args, **kwargs) +self.timeout = timeout + +def make_connection(self, host): +host, extra_headers, x509 = self.get_host_info(host) +return TimeoutHTTP(host, timeout=self.timeout) + +class TimeoutServerProxy(xmlrpclib.ServerProxy): + Creates a server proxy with Timeout facility. + Timeout sent in argument can be used to drop connection + for unavailable servers +def __init__(self, url, timeout, *args, **kwargs): +kwargs['transport'] = TimeoutTransport(timeout=timeout, use_datetime=kwargs.get('use_datetime', 0)) +xmlrpclib.ServerProxy.__init__(self, url, *args, **kwargs) + def register_laptop(url=REGISTER_URL): profile = get_profile() @@ -95,7 +119,7 @@ def register_laptop(url=REGISTER_URL): nick = client.get_string('/desktop/sugar/user/nick') -server = ServerProxy(url) +server = TimeoutServerProxy(url,10) try: data = server.register(sn, nick, uuid_, profile.pubkey) except (Error, socket.error): -- 1.7.0.4 ___ 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 06.09.2010, at 18:34, Sascha Silbe wrote: Excerpts from Bert Freudenberg's message of Mon Sep 06 17:53:41 +0200 2010: Go-home would be the button I press most often, to counteract auto-resuming. FWIW you can hold Alt while clicking on the activity to start a new instance instead of resuming the most recent one. I know. But I only remember when I clicked already ;) I guess we're going to add a home button to Etoys, too. It's too late for this release but probably in the next. inline: Etoys-Home.png - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SL bug #1520
Bernie, I am working on SL #1520 - http://bugs.sugarlabs.org/ticket/1520 with Dipankar. We have identified the problem with reviews from Sascha and Tomeu. Appreciate your reviews and support. Sascha wrote that you have fixed this issue on Fedora. Can you please provide us the link for the patch so that we could study it, and expedite the process of fixing it in other distributions like Debian? Appreciate your support. Regards, Mukul ___ 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
Excerpts from Simon Schampijer's message of Mon Sep 06 17:35:58 +0200 2010: 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. Sounds good to me. 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] screenreader for sugar
no, I tested with gnome desktop. 2010/9/3 Tomeu Vizoso to...@sugarlabs.org On Thu, Sep 2, 2010 at 18:25, Esteban Arias ear...@plan.ceibal.edu.uy 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 to...@sugarlabs.org On Wed, Sep 1, 2010 at 14:51, Esteban Arias ear...@plan.ceibal.edu.uy 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 pbrobin...@gmail.com On Wed, Sep 1, 2010 at 10:24 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Aug 20, 2010 at 14:10, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Aug 20, 2010 at 14:08, Esteban Arias ear...@plan.ceibal.edu.uy 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
Re: [Sugar-devel] SL bug #1520
Excerpts from Mukul Gupta's message of Mon Sep 06 19:27:32 +0200 2010: [metacity disable-keybindings not working] Sascha wrote that you have fixed this issue on Fedora. Can you please provide us the link for the patch so that we could study it, and expedite the process of fixing it in other distributions like Debian? I already included the link to the patch in my mail. It might be easy to overlook if you're not used to citations in emails. Check below my greeting (but above the signature), the line starting with [1]. 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] Home button in Browse
Excerpts from chm's message of Mon Sep 06 18:51:56 +0200 2010: FWIW you can holdAlt 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 -- 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] Home button in Browse
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. Adding yet another top-level button for go-home would clutter things too much IMO. We should expose our keyboard accelerators in the palettes, but that's an orthogonal issue as web browsing is usually done with a pointing device. It's faster for the user to click some button than to switch to the keyboard and back. 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] Error/Warning Icons for alerts
On Mon, Sep 6, 2010 at 9:05 PM, Simon Schampijer si...@schampijer.de 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. What do others think? Thanks in advance for your feedback, Simon [1] http://dev.laptop.org/ticket/10312 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel [1] http://people.sugarlabs.org/~anish/sl1842.png [2] http://lists.sugarlabs.org/archive/sugar-devel/2010-July/025194.html -- Anish ___ 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 06.09.2010, at 21:00, Sascha Silbe wrote: Excerpts from chm's message of Mon Sep 06 18:51:56 +0200 2010: FWIW you can holdAlt 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. That would be awesome! - Bert - ___ 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 Dipankar Patro's message of Mon Sep 06 19:04:04 +0200 2010: I have attached the revised patch. (uploaded at bugs.sl.o too) Please use git send-email to send patches so they appear as inline text rather than attachments. With many email clients it's hard to reply to text attachments. I still think class TimeoutServerProxy could be eliminated and that this change would make the code simpler and easier to understand. * changed things (subject, description, etc) according to Sascha Silbe's suggestions. Thanks! Let me suggest some further improvements: Subject: [PATCH] Register widget click event reflects a timeout on unavailability of servers Time out on registration process to prevent indefinite UI hang (SL#2289) [Ticket #2289] The convention so far was to append the ticket number to the subject so it appears in one-line commit logs. Mentioning it separately is OK, but if you're already changing the summary and description it makes sense to adjust it. The register widget when clicked, used to cause sugar to freeze. Added a timeout facilitated ServerProxy() so that connection to schoolserver is dropped in case it is not available. 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. As you can see it's still not perfect, but hopefully conveys the rationale behind the patch and the high-level changes it makes better. The focus in patch descriptions is on what the effect of the change is and why it is done, not so much how it is achieved (that's visible in the patch itself). Choosing a good description is hard, even after years of training. But it makes life a lot easier if you're trying to understand some piece of code months or years later. Give git blame some file and git log commit ID^..commit ID a try sometime to see how to use the commit log to understand some code. (There are probably even GUI tools for that, but as I'm a console freak myself I don't know about any). @ Marco : The default timeout is way too long (unable to find out exact time). Yes, the process is synchronous, thats why Sugar is freezing. The chosen timeout of 10 seconds seems sensible to me, FWIW. It's long enough to allow a busy server (even a remote one) to answer and short enough so the user doesn't give up and reset the machine. 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 Mon, Sep 6, 2010 at 6:04 PM, Dipankar Patro dipan...@seeta.in wrote: Sorry for that duplicate bug. Missed out that lfaraone already filed the bug. I have attached the revised patch. (uploaded at bugs.sl.o too) * changed things (subject, description, etc) according to Sascha Silbe's suggestions. @ Marco : The default timeout is way too long (unable to find out exact time). Yes, the process is synchronous, thats why Sugar is freezing. With Tomeu clarification the very short timeout make sense. As Sascha suggested the log should explain why we are doing this though. I think it would be good to also put a similar comment in a FIXME in the code. Marco ___ 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 Mon, Sep 6, 2010 at 11:42 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Previous discussion is actually in http://bugs.sugarlabs.org/ticket/2289 and not in #2290. Looks like we cannot do XML-RPC with GIO because it doesn't support POST for http requests. The right component in our stack would be libsoup but we find again that we need introspection to use it because nobody cared to write, maintain and package python bindings for it. So many reasons to move to introspection :) Marco ___ 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
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. I've worked at two places that mounted /home on our personal workstations via NFS. We did occasionally login from other machines but the main reason for using NFS was for sharing and centralizing the backup. Both worked, but there were lots of quirks, and nobody tried to take their machines home at night. Note that in addition to /home, you have to keep /etc/passwd and various other files synchronized. Another consideration when using NSF is security. It has a long history of weak security. At both of the places where I used NFS, we lived with it. (We were all mature adults working for the same company and such. Personnel and payroll were on different systems. ...) In the context of schools, it might get interesting if the teachers are storing their files on the same server. -- It's been a long time since I worked with a slosh by hand system. I've forgotten all the details. We were happy with it, but we weren't switching workstations often. I'd expect there are lots of modern software packages designed to keep laptops synchronized. One of them might fit the XO usage pattern. With the right wrapper, one of the source-control packages might work. It might be reasonable to modify the current backup/restore code to do the sloshing. One catch for an XO is that the file system is tiny so you would have to delete the previous user's files to make room for the next user. NB: You really don't want to delete them if they haven't been copied back yet. Another possible problem is that the network load is likely to be synchronized, say at the beginning of the school day when the machines get handed off from one user to the next. -- What's the backup mechanism on current school servers? If the truth lives on my XO and the school server is just a backup, I might be willing to not backup the school server. On the other hand, if the truth lives on the school server, I'd really want another layer or two of backup. 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. ... -- These are my opinions, not necessarily my employer's. I hate spam. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [olpc-nz] Twi translation
I've put in a request at http://bugs.sugarlabs.org/ticket/2276# Is there someone i can ping to get this moving? just keep to do so while we have a volunteer interested. On Fri, Sep 3, 2010 at 12:32 AM, David Farning dfarn...@gmail.com wrote: I have forwarded this to sugar-devel. Often I have seen sysamindu handle these requests on IRC. But I believe he has returned to school. david On Thu, Sep 2, 2010 at 4:54 AM, Tabitha Roder tabi...@tabitha.net.nz wrote: On 31 August 2010 09:10, Brenda Wallace bre...@coffee.geek.nz wrote: My colleague, Charlie, has vounteered to do Twi translations of sugar text. Twi is the language of Ghana. Anyone on this list set up translation before? Can you point on the way to get an interface infront of Charlie so he can go for it? I got Tongan, Maori and Samoan started. Best thing to do is submit request to http://bugs.sugarlabs.org/ that says please create Twi language and add terminology project and glucose project. We suggest the terminology project (these are like keywords that give you a start point for all the other projects) and glucose project (the main file for the majority of words found in the Sugar interface) before tackling the others. The translation team should respond pretty quick. Charlie will need access to Sugar (on a Stick is fine) to see the words in context while doing the translation. Tabitha ___ olpc-nz mailing list olpc...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-nz -- Kotahi tamaiti, Kotahi rorohiko iti: no Aotearoa http://laptop.org.nz ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar-0.84] journal scan of external media
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. -- James Cameron http://quozl.linux.org.au/ From 0400edfa92760dc67f4fcd3579fd3fe4d5442ba9 Mon Sep 17 00:00:00 2001 From: James Cameron qu...@laptop.org Date: Tue, 7 Sep 2010 10:58:14 +1000 Subject: [PATCH 1/2] fix for non-completion of scan of external media, dev.laptop.org #10140 _recurse_dir() adds an instance of itself to the gobject idle loop once for each directory on external media. The _pending_directories counter is skewed if os.listdir() fails, which it would do if a directory was not readable. This causes the scan to never complete; the journal keeps showing the progress bar. This patch catches and ignores exceptions encountered by os.listdir(), allowing the counter to remain more consistent. Also, the counter was not correctly tracked; there was a possibility the ready signal would be emitted before all the instances of _recurse_dir() had completed. This happened in testing. The fix is to more strictly maintain the counter. http://dev.laptop.org/ticket/10140 --- src/jarabe/journal/model.py | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/jarabe/journal/model.py b/src/jarabe/journal/model.py index 50e8dc1..c60349d 100644 --- a/src/jarabe/journal/model.py +++ b/src/jarabe/journal/model.py @@ -283,6 +283,7 @@ class InplaceResultSet(BaseResultSet): def setup(self): self._file_list = [] +self._pending_directories += 1 self._recurse_dir(self._mount_point) def stop(self): @@ -321,7 +322,11 @@ class InplaceResultSet(BaseResultSet): if self._stopped: return -for entry in os.listdir(dir_path): +try: +entries = os.listdir(dir_path) +except: +entries = [] +for entry in entries: if entry.startswith('.'): continue full_path = dir_path + '/' + entry @@ -358,10 +363,9 @@ class InplaceResultSet(BaseResultSet): logging.error('Error reading file %r: %s' % \ (full_path, traceback.format_exc())) +self._pending_directories -= 1 if self._pending_directories == 0: self.setup_ready() -else: -self._pending_directories -= 1 def _get_file_metadata(path, stat): client = gconf.client_get_default() -- 1.7.1 From 9c85022edc07742975caf0eaf9b1d793e1da2e02 Mon Sep 17 00:00:00 2001 From: James Cameron qu...@laptop.org Date: Tue, 7 Sep 2010 12:41:18 +1000 Subject: [PATCH 2/2] journal view of external media, avoid symlink loops [0.84] Inserting external media such as an operating system filesystem and then selecting the volume in journal leads to extra delay and many errors in shell.log, caused by symlink loops being followed. This patch detects symlinks, and: * avoids following symlinks to ., * avoids following symlinks to a point higher in the same path. --- src/jarabe/journal/model.py | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/src/jarabe/journal/model.py b/src/jarabe/journal/model.py index c60349d..afaecb6 100644 --- a/src/jarabe/journal/model.py +++ b/src/jarabe/journal/model.py @@ -19,7 +19,7 @@ import os 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 @@ -331,7 +331,15 @@ class
Re: [Sugar-devel] [DESIGN] Home button in Browse
Go-home would be the button I press most often, to counteract auto-resuming. FWIW you can hold Alt 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? It didn't work for me. Is that a recent change? I'm running os852 which has Sugar 0.84.16. I get the last instance of Browse that I had saved, the same thing I get without the Alt key down. But if I wait a few seconds with the cursor over the globe, it first gives me a pop-up with Browse and the name of the most recent instance, and after a few more seconds, it gives me a bigger popup showing all the saved names and a slot at the bottom saying Start. Is there a way to get out of Browse without saving anything? Auto-save saves the the current URL on top of the old name. That gets me out quickly, but if I've clicked around like I normally do, that probably breaks the name/URL binding I had setup. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel