Re: [Sugar-devel] code for register widget
On Wed, Sep 1, 2010 at 03:11, Luke Faraone l...@faraone.cc wrote: On 08/28/2010 05:02 AM, u...@dev.seeta.in wrote: Ref to LP bug #617813: https://bugs.launchpad.net/ubuntu/+source/sugar-0.88/+bug/617813 Hi, I am working on this bug, and I want to go through the code for register widget and the processes it carries out with the networking interface also. But after going through a lot of files in sugar-0.88 package source, I wasn't able to get near to it. It would be great if somebody can provide pointers regarding it. Hi Dipankar, whenever I want to find out which code is related to a string displayed in the UI, I grep the relevant modules for that string in this way: $ cd /opt/sugar-jhbuild/source/sugar $ git grep Register Hope that helps, Tomeu Regards, Dipankar I haven't the faintest idea. This would probably be a good question to ask on the sugar-devel mailing list. CCing them on this reply. -- ╒═╕ │Luke Faraone ╭Debian / Ubuntu Developer╮│ │http://luke.faraone.cc ╰Sugar Labs, Systems Admin╯│ │PGP: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 │ ╘═╛ ___ 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] Sugarbot on OLPC Sugarlabs
Hi all, We are trying to run Sugarbot on OLPC Sugarlabs. we use to refer sugarbot * * http://code.google.com/p/sugarbot/*OLPC Sugar GUI automation project (http://code.google.com/p/sugarbot/wiki/RunningSugarbot), but I cannot install Sugarbot on OLPC.reason the instructions provided by the above site , Is not clear enough for me. I use olpc xo 1.5 OS 851 firmware q3a50, please give necessary advice to install Sugarbot. Looking forward to hear from you. http://code.google.com/p/sugarbot/ * Thanks, Regards, Asiri. ** http://code.google.com/p/sugarbot/ * http://code.google.com/p/sugarbot/* ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] screenreader for sugar
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. Regards, Tomeu Regards, Tomeu 2010/8/20 Gonzalo Odiard godi...@gmail.com In this thread http://lists.laptop.org/pipermail/olpc-sur/2010-April/005829.html there are people interested. You can contact Esteban Arias also http://lists.laptop.org/pipermail/olpc-uruguay/2010-February/001653.html Gonzalo On Fri, Aug 20, 2010 at 8:41 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Aug 20, 2010 at 12:53, Gonzalo Odiard godi...@gmail.com wrote: Yes, there are interest in La Rioja, Argentina. In olpc-sur there are request for this. Great, do we have people there who can try things out and help decide what remains to be done? Regards, Tomeu Gonzalo On Fri, Aug 20, 2010 at 6:16 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, is there any interest in a deployment somewhere for a screenreader that allows blind people use the Sugar UI when paired with keyboard navigation? I think most of the pieces are there, but without knowing how it could be used I cannot really test. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard Responsable de Desarrollo (pasando la antorcha...) Sistemas Australes ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Esteban Arias Investigación y Desarrollo - Plan Ceibal Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.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] screenreader for sugar
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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] wanting to try recent Sugar, problems
Excerpts from S Page's message of Wed Sep 01 03:59:53 +0200 2010: I wanted to see how the library and Browse work in recent Sugar. I downloaded the weekly testing soas-i386-20100826.15.iso from http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Beta From discussions on the soas mailing list I gather these are known to broken. Peter Robinson is going to look into it, but didn't get around to yet. AFAICT you should have better luck with Mirabelle (currently available at [5]). It's based on Sugar 0.88, but I don't think there have been any changes since 0.88 in the areas you're currently interested in. * Can an XO-1 boot from this .iso if I turn it into a Live USB? Supposedly the F13 glibc incompatibility with Geode was fixed in July ( https://bugzilla.redhat.com/show_bug.cgi?id=579838 -- great stuff from Dont Close Unfixed Bugs who must be John Gilmore in a mask ;-) ). On XOs you might want to try Dextrose [1]. It's based on Sugar 0.88 as well. * I tried to get Sugar jhbuild to work on Kubuntu several months ago, I never succeeded and it left me with package incompatibility difficulties. sugar-jhbuild on Ubuntu is troublesome in general and for Ubuntu versions newer than Karmic (9.10) it's completely broken because they dropped python-xpcom [2]. There's nothing we can do on our side, it needs to be fixed by Ubuntu. You can help by voting on the bug reports [2,3]. Any suggestions? Ideally my PC environment would continue running and I don't lose my OLPC build. I can recommend KVM. Just put Debian Squeeze inside a VM and install the sucrose-0.88 package. The Debian team (including several developers from Activity Central / SEETA now) has been doing great work; I've been running this on my XO-1.5 for quite some time now and encountered no bugs other than those in the upstream parts. If you want the very latest Sugar code, you can instead install sugar-jhbuild inside the VM (but don't install Sugar distro packages and sugar-jhbuild in parallel on the same VM, it'll cause trouble). Read is broken [4] on all recent systems, no matter what distribution. Sascha [1] http://wiki.sugarlabs.org/go/Dextrose [2] https://bugs.launchpad.net/sugar/+bug/480407 [3] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/325706 [4] https://bugs.sugarlabs.org/ticket/1900 [5] http://spins.fedoraproject.org/soas/ -- 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] Automatic saving (was: Re: [DESIGN] Etoys 4.1)
Excerpts from forster's message of Wed Sep 01 01:07:27 +0200 2010: Create a program in Pippy, then look at one of the examples. All your work will be overwritten. That's a Critical bug, please file a ticket at https://bugs.sugarlabs.org (with severity set to Critical). I have viewed a favourite holiday photo in Browse, then used that Browse session to surf the net, overwriting that photo (can't replicate that now OS373pyg). If you ever can reproduce it, please file a ticket for this one too (severity Critical again). I would be happy to have a global setting in control panel for all Activities for autosave vs a dialogue which gave a choice on exit. Would that break existing Activities? It would break the entire design of Sugar. Though there is a case for autosave for raw beginners, Automatic saving isn't for beginners, it's important for everyone. its contrary to Sugar's goal of empowering users to give them no control of when saving occurs. While no ceiling ultimately includes giving the user the power to shoot themselves in the foot, it's not a goal to let that happen as part of the everyday process. You got a point, of course. There are currently two things missing from (mainline) Sugar that affect this use case: 1. version support 2. A revert all my changes since I opened this activity button (_independent_ of the Stop button) I've worked [1] on #1, but nobody cared to try it out [2]. #2 is just a shortcut; the user can always remove the latest version by using the Journal. I'm aware that the current implementation of version support is not suitable for Sugar running on XO-1 (and _maybe_ XO-1.5) because it increases the storage overhead and has no easy way to clean up old versions, but on regular PCs which nowadays have hard disks in the TB (terabytes) range (about 1000 times that of the XO-1) I don't accept that argument. I will continue working on version support, but as I'm a single person and have other things to work on (including finishing my studies and trying to come up with ways to pay the rent) it will take a lot of time. Sascha [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore [2] http://wiki.sugarlabs.org/go/Version_support_for_datastore/Howto -- 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] wanting to try recent Sugar, problems
don't install Sugar distro packages and sugar-jhbuild in parallel on the same VM, it'll cause trouble). Can you elaborate what would be the nature of these problems? I've been trying to get a clean jhbuild env to work under f13. gabble/salut don't work when I run the sugar-emulator. and I can't share activities. To test whether is this was a system-wide problem, I installed the sugar-* rpm's as well. The package-installed sugar-emulator starts up well; gabble/salut don't crash and I can get activities to be shared. Sascha -- Anish ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Keep button (was: Re: [RELEASE] Etoys 4.1.2384)
Excerpts from Gary Martin's message of Tue Aug 31 20:07:12 +0200 2010: My first gut reaction (not having seen it yet) is that the Keep button is a real problem generally (and causes confusion and misunderstanding in Sugar). Habitually training kids to click that icon each time before exiting will, for all other activities, generate many confusing duplicate Journal entries over time and make matters even worse. +1 For the Etoys case, as a workaround for not knowing your clean/dirty state, I think having the regular Stop UI button that when clicked _always_ displayed some sort of Do you want to Keep the changes to this project in the Journal? Keep/Don't Keep dialogue. Having the Stop button ask which version (the one in the Journal or the one currently loaded) to destroy is a bad idea, but unsolvable without version support. Please avoid the Keep terminology in this context; it's only going to confuse users even more. 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
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: 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió: Yes, we agreed on that, but then, just for the sake of argument, several unchecked statements were made that unfairly represented the current Sugar development model and the work of several members of our community. [...] I'm criticizing the development process, not the community. While we seem to have diametrically opposed positions on what's engulfing Sugar's development, we seem to agree that we indeed have a problem of some kind. Believe it or no, I highly respect you for all the work you've done for Sugar and for taking the time to analyze the situation with me. I'm actually sorry that few others seem interested in having this discussion. Moving forward: how are we going to reach consensus on changing (or not changing) our development model? Shall we have a vote among all current Sugar Labs members? Only people who ever contributed a patch? Only those who have patches in git? Shall we ask the oversight board to make a decision? When I started to work on Dextrose, I immediately felt the need to fix the upstream code acceptance process, starting from how we do code reviews. Six months later nothing has changed, and I had to do most of the work outside the mainline tree, causing problems for everyone. It's not too late: some deployments still intend to contribute some of their work upstream. They simply need someone from within Sugar Labs to make a few steps towards them. In case it needs to be said, I'm extremely grateful at Christian, Gary, Eben, Eduardo and the others that put their experience, effort and time thinking about our UI, discussing it with others, drawing mockups for other people's features, etc Me too. The dedication of our community is not being questioned. Unfortunately, I have seen people spend months coding a feature and not having found 30 seconds to write a heads-up email to the list asking for user experience feedback. At some point I took a minute to write such emails for 3 other people's features. Obviously it helps if you start the discussion just before you start coding, and not just after. Ha! I've also seen the exact opposite happen: Tincho's initial design proposals for the backup/restore feature and for the resource meter were mostly ignored... Then we went on implementing those designs, test, integrate and finally submit patches. At this point, people started asking to redesign both the UI and the implementation. So we gave up. Both Uruguay and Paraguay find the backup/restore feature really useful. It would be extremely useful also for other deployments and SoaS users. But it won't be in mainline until someone rewrites it, which probably means never. And here's where we should keep into account non-technical factors. Why would a deployment that is already happy with how the feature works today take the extra time to rewrite it according to how an upstream wants it? The long-term benefit of upstreaming patches is always unclear, especially to managers. If we put too much of a burden on contributors, we're simply going to loose them. We could go around saying it was their fault for not following procedures X, Y and Z, but it's ultimately our loss. Sometimes UI designers come up with an idea that nobody would implement. In other cases, programmers come up with UI changes that designers reject. When you get both, the work needs to go through maintainer approval of each affected module. Again, you are misrepresenting me just for the sake of argument, You? This thread is not about you, don't take it personally. You happen to be another person who cares to re-discuss our processes, this is why I'm having this conversation with you. there's a wide chasm between giving others the chance to opine and taking those opinions seriously, and having to reach unanimity on a perfectly defined design. So you agree that the final decision to include code in Sugar should be in the hands on just one person who takes full responsibility for the evolution (or lack thereof) of Sugar? Because, to me, this is exactly what Sugar is missing today. Having some form of reviews is great, but we broke up Sugar in tightly coupled modules, so that any non-trivial change often spans across 2 or 3. Typically it's sugar + sugar-toolkit + sugar-artwork. One person is working on merging them, several others have preferred just to complain about it. Once you've established a lightweight workflow, merging patches is in itself a no-brainer! All the maintainer has to do is git am patches_to_apply.mbox and resolve any conflicts. If we managed to approve patches in a timely fashion, they would apply cleanly almost all the time. As you know, in 6 months I've accumulated in Dextrose over 100 patches for Sugar. Even though managing a patch queue is somewhat harder than simply merging them, only a tiny amount of my time went in it. The actual time sinks were testing and interaction with the
Re: [Sugar-devel] Autosave and Keep button
On 01.09.2010, at 14:01, Sascha Silbe wrote: Excerpts from Gary Martin's message of Tue Aug 31 20:07:12 +0200 2010: My first gut reaction (not having seen it yet) is that the Keep button is a real problem generally (and causes confusion and misunderstanding in Sugar). Habitually training kids to click that icon each time before exiting will, for all other activities, generate many confusing duplicate Journal entries over time and make matters even worse. +1 For the Etoys case, as a workaround for not knowing your clean/dirty state, I think having the regular Stop UI button that when clicked _always_ displayed some sort of Do you want to Keep the changes to this project in the Journal? Keep/Don't Keep dialogue. Having the Stop button ask which version (the one in the Journal or the one currently loaded) to destroy is a bad idea, but unsolvable without version support. Please avoid the Keep terminology in this context; it's only going to confuse users even more. Sascha That's one of the reasons I did not want to overload the exit button with saving functionality. It simply exits (after confirming) without ever saving now. To avoid confusion, it does not look like a regular stop button: inline: PastedGraphic-1.png But you can't really discuss autosaving and keeping separately. They go hand in hand. If an activity cannot autosave, it has to rely on the keep button, right? And keeping should create a new entry - that's how it is in every activity. Only autosave destructively overwrites the current entry. I am warming up to Gary's suggestion though because it's the only way to avoid needless Journal entries, unless we introduce a save/save-as distinction. Incidentally, on other platforms Etoys does versioning itself - every project saved has a version number embedded in the file name that is not visible in the UI. In the file-open dialog, all but the highest numbered versions are hidden. Now maybe if the Journal had a hide attribute for an entry, the Journal would look less cluttered. Also, when running out of space the hidden entries could be used to free up space. Wait, that's re-inventing the trash can ... but maybe not a bad idea after all. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Request for comments: A Proposed way to report Soas tests
I have been using this format to report testing of Soas Nightly Composes. [1] Please comment on the usability of such a format. Tom Gilliard satellit [1] http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick_release_process#Test_Matrix ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity title update
On 07/19/2010 03:17 AM, Gonzalo Odiard wrote: On Sun, Jul 18, 2010 at 9:57 PM, James Cameronqu...@laptop.org wrote: On Sun, Jul 18, 2010 at 05:41:08PM -0300, Gonzalo Odiard wrote: Can this resolve the problem? [r...@aronax graphics]# diff -u toolbutton.py.ori toolbutton.py --- toolbutton.py.ori2010-07-18 17:39:27.374544801 -0300 +++ toolbutton.py2010-07-18 17:39:58.198297844 -0300 @@ -160,3 +160,5 @@ def do_clicked(self): if self.palette: self.palette.popdown(True) +else: +gtk.ToolButton(self) From my testing the focus-out event is propagated when we hit the stop button. focus-out is emitted, though we do save first. I have added now a line that just saves the title when hitting stop. Furthermore the focus-out-event handler is disconnected to not receive events when the activity is deconstructed (can be seen in current code). http://bugs.sugarlabs.org/attachment/ticket/1948/0001-Save-title-when-closing-1948.patch I think that is an ok solution (at least for 0.84). Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Request for comments: A Proposed way to report Soas tests
Caryl; I added a section for Mac Testing. Thanks for the feedback. I do not have a Mac so I will rely on others to use this section to report results Tom Gilliard satellit http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick_release_process#Macintosh_Testing Caryl Bigenho wrote: Hi Tom and all... You have done a great job organizing this. The only thing I would suggest is adding something for Mac testers, maybe a separate chart, that refers to the method (and version of the method) they are using... Virtual Box or boot-helper CD or something else if something else will work too. Also, it should include the model of the Mac. There are actually some folks in SoCal who are working on trying to get it to run on the old G4 (PowerPC) Macs. Caryl Date: Wed, 1 Sep 2010 07:50:32 -0700 From: satel...@bendbroadband.com To: s...@lists.sugarlabs.org CC: sugar-devel@lists.sugarlabs.org Subject: [SoaS] Request for comments: A Proposed way to report Soas tests I have been using this format to report testing of Soas Nightly Composes. [1] Please comment on the usability of such a format. Tom Gilliard satellit [1] http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick_release_process#Test_Matrix ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Request for comments: A Proposed way to report Soas tests
On Wed, Sep 1, 2010 at 4:11 PM, Caryl Bigenho cbige...@hotmail.com wrote: Hi Tom and all... You have done a great job organizing this. The only thing I would suggest is adding something for Mac testers, maybe a separate chart, that refers to the method (and version of the method) they are using... Virtual Box or boot-helper CD or something else if something else will work too. Also, it should include the model of the Mac. There are actually some folks in SoCal who are working on trying to get it to run on the old G4 (PowerPC) Macs. How are they using PowerPCs? What PPC distribution are they using for this? Peter Caryl Date: Wed, 1 Sep 2010 07:50:32 -0700 From: satel...@bendbroadband.com To: s...@lists.sugarlabs.org CC: sugar-devel@lists.sugarlabs.org Subject: [SoaS] Request for comments: A Proposed way to report Soas tests I have been using this format to report testing of Soas Nightly Composes. [1] Please comment on the usability of such a format. Tom Gilliard satellit [1] http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick_release_process#Test_Matrix ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Automatic saving (was: Re: [DESIGN] Etoys 4.1)
Create a program in Pippy, then look at one of the examples. All your work will be overwritten. That's a Critical bug, please file a ticket at https://bugs.sugarlabs.org (with severity set to Critical). done Ticket #2271 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Findings for Register Bug LP #617813
(let's always cc sugar-devel@ when we discuss sugar bugs, so the rest of the Sugar development community can jump in with better suggestions than mine) El Thu, 02-09-2010 a las 00:45 +0530, Dipankar Patro escribió: Hello Bernie, Following are the findings and plan of action for the LP Bug : #617813 Problem : Sugar freezes when we try to register on emulator Findings: We think that sugar is not handling the inaccessible sites/servers properly. The current code just checks for regular errors. It doesn't have provisions for long time lags. This can easily be rectified a small code to stop register procedure if the time elapsed is more than allowed lag time. Plan of action: Add the required snippet in /usr/share/pyshared/jarabe/desktop/schoolserver.py at line 100 somewhat similar to if (t45 seconds), a message Wish if you could provide some pointers on this. The problem is that schoolserver registration code uses blocking I/O. There's no way you can test for a timeout, because your code will not be executed while the network operation is going on. GUI applications cannot generally use blocking networking operations like that. In order to fix this bug, this code should be rewritten using asynchronous callbacks. The good news is that somone already proposed a solution for this problem a very time ago: http://bugs.sugarlabs.org/ticket/1152 The bad news is that this patch was written for Sugar 0.82 and it will probably need some adaptation. Hope this helps, -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
Guys, honestly this whole discussion is getting a bit ridiculous, lots of rhetoric and very little practical disagreement. We agree that we should try out reviews on the mailing list, let's just do it. I'm pretty confident we can setup and improve patchwork to help us tracking patch status reliably. I don't have a lot of time but I will commit to help out with both infrastructure and the reviews themselves. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
