Re: [Sugar-devel] [IAEP] "Make Your Own Sugar Activites!" is on Lulu.com
Thanks James! I will buy a few copies now. Can we also get the free PDF download working? http://www.lulu.com/product/file-download/make-your-own-sugar-activities/12995553 Currently the error message is: You do not have access to the page you requested. http://www.lulu.com/forbidden.php On 10/7/2010 10:24 AM, James Simmons wrote: A couple of people had expressed interest in buying a printed copy of "Make Your Own Sugar Activities!" from Lulu.com, only to find it was not available. We had to remove it from the site to rework the book, making the fonts bigger and more readable, improving the page breaks, and creating brand new art for the front cover. I just got a review copy this weekend and it's a vast improvement. We've made the book available again, and you can get it here: http://www.lulu.com/product/paperback/make-your-own-sugar-activities/12995552 It's available as a beautiful Crown Quarto sized paperback and also as a free PDF download which is perfect for use with the Read Activity. This might be a great stocking stuffer for that special geek in your life. I don't get any money from the sales of this book; that goes to FLOSS Manuals, who provided the software that made creating the book possible. That doesn't mean I don't want it to be a best seller! James Simmons ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] chooser/datastore documentation
I am struggling with getting my activities to behave in consistent ways when using the chooser and datastore.find() between Sugar 0.84 and more recent Sugar versions. (For example, I cannot get find() to process mime-type query in 0.84 but it will handle a title query. The exact opposite seems to be true in 0.90. Of course, I could be doing it all wrong.) Similarly, I cannot get what_filter to work with non-GENERIC mime types, but that again could be user error. (I am trying to choose only Python objects, for example.) I've searched unsuccessfully for documentation on what works in which versions. Does such documentation exist somewhere? thanks. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
Ticket with the start of implementation: http://bugs.sugarlabs.org/ticket/2425 Gonzalo On Thu, Oct 7, 2010 at 1:39 PM, Daniel Drake wrote: > On 4 October 2010 15:27, Gonzalo Odiard wrote: > > What do others think about this approach? Packagers? > > A clearer way to discuss this would be to just send a patch. That way > there is no doubt over the details of the implementation that you are > proposing. > > Daniel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v3 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
Sorry , in that case , as I misunderstood the meaning of the tag Reviewed-by and will keep this fact in my mind while making future patches and will certainly remove your name from the reviewed by tag of this patch in its next version. Once again my apologies for the matter. Regards Anurag On Thu, Oct 7, 2010 at 10:17 PM, Sascha Silbe wrote: > Excerpts from Anurag Chowdhury's message of Fri Oct 08 00:06:02 +0200 2010: > >> v2 was Reviewed-By: Sascha Silbe > > No, I certainly did NOT give my Reviewed-By on this code. As I already > told Ishan [2]: > >>> I reviewed it, but since there were things I wanted to be >>> changed, I did not "grant" my Reviewed-By: tag. The meaning of that >>> tag is that I reviewed the patch _and_ believe it to be fit for >>> inclusion, standing with my reputation behind that judgement (see [1], >>> section 14). > > Sascha > > [1] http://www.kernel.org/doc/Documentation/SubmittingPatches > [2] https://lists.sugarlabs.org/archive/sugar-devel/2010-September/027376.html > -- > 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] Memory leak in Sugar -- how to dump Py data structures?
On 8 October 2010 03:34, Martin Langhoff wrote: > See http://dev.laptop.org/ticket/10386 for details. The sugar-session > process in 10.1.2 grows slowly... > > There's some form of leak somewhere. Maybe we are triggerin a real > python leak, maybe we have reference loops. How do we trace this? > This post seems pretty good [1]. It cites a tool that creates an object graph that visually represents what is happening in memory.[2] [1] http://www.lshift.net/blog/2008/11/14/tracing-python-memory-leaks [2] http://mg.pov.lt/blog/python-object-graphs.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] how to ask a question -- was Re: Ticket no #2210 words don't changed when language is changed
On Thu, Oct 7, 2010 at 2:21 PM, Tomeu Vizoso wrote: > On Thu, Oct 7, 2010 at 20:08, David Farning wrote: >> On Thu, Oct 7, 2010 at 1:54 AM, Ishan Bansal wrote: >>> Hi >>> >>> I am working on the ticket http://bugs.sugarlabs.org/ticket/2210. >>> >>> To solve the above bug i am thinking of clearing the text in the text to be >>> translate box when ever the language to be translated is being changed. >>> Please provide suggestion on any better approach to deal with this bug. >> >> Over the last month this list has seen a significant increase in >> requests for pointers. >> >> Asking questions is an healthy part of learning, but asking for >> 'pointers' is _not_ going to be particularly helpful. It shifts the >> effort to the person answering the question rather then the person >> asking the question. Effectively asking questions is an art. Asking >> question is so important that Eric Raymond, author of the Cathedral >> and the Bazaar, has written and maintained an article about how to ask >> questions the smart way at >> http://www.catb.org/esr/faqs/smart-questions.html . >> >> I strongly suggest reading the article. The time spent learning how >> to ask questions the smart way... and asking questions the smart way >> will pay for itself very quickly. Questions asked the smart way will >> generally get quicker responses and better answers. >> >> Two additional points >> -- If you are new to the list please clearly describe 1) What you >> know, 2) What you don't know, 3) and what you think you have to learn >> to solve your problem. This provides the person answering the >> question a sense of scope. > > This is very well put, lately I have felt like I would need to explain > most I know about software engineering in order to give an useful > reply. And if anyone feels dumb expressing what they don't know. Please note that I just committed one of the biggest mistakes in mailing list manners:( I hijacked this thread without reseting the subject.We all make mistakes and we all get peer reviewed. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ticket no #2210 words don't changed when language is changed
On Thu, Oct 7, 2010 at 20:08, David Farning wrote: > On Thu, Oct 7, 2010 at 1:54 AM, Ishan Bansal wrote: >> Hi >> >> I am working on the ticket http://bugs.sugarlabs.org/ticket/2210. >> >> To solve the above bug i am thinking of clearing the text in the text to be >> translate box when ever the language to be translated is being changed. >> Please provide suggestion on any better approach to deal with this bug. > > Over the last month this list has seen a significant increase in > requests for pointers. > > Asking questions is an healthy part of learning, but asking for > 'pointers' is _not_ going to be particularly helpful. It shifts the > effort to the person answering the question rather then the person > asking the question. Effectively asking questions is an art. Asking > question is so important that Eric Raymond, author of the Cathedral > and the Bazaar, has written and maintained an article about how to ask > questions the smart way at > http://www.catb.org/esr/faqs/smart-questions.html . > > I strongly suggest reading the article. The time spent learning how > to ask questions the smart way... and asking questions the smart way > will pay for itself very quickly. Questions asked the smart way will > generally get quicker responses and better answers. > > Two additional points > -- If you are new to the list please clearly describe 1) What you > know, 2) What you don't know, 3) and what you think you have to learn > to solve your problem. This provides the person answering the > question a sense of scope. This is very well put, lately I have felt like I would need to explain most I know about software engineering in order to give an useful reply. Regards, Tomeu > The answer someone provides is based on the > knowledge and needs for the person asking the question. > > -- Answer as many questions as you ask. > > david > > >> Please provide pointers on the following problems- >> >> 1. Please explain me the code "model, _iter = column.get_selected()" >> >> 2. How can i check when is the language to be translated is being changed. >> >> Regards >> >> ishan >> >> ___ >> 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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ticket no #2210 words don't changed when language is changed
On Thu, Oct 7, 2010 at 1:54 AM, Ishan Bansal wrote: > Hi > > I am working on the ticket http://bugs.sugarlabs.org/ticket/2210. > > To solve the above bug i am thinking of clearing the text in the text to be > translate box when ever the language to be translated is being changed. > Please provide suggestion on any better approach to deal with this bug. Over the last month this list has seen a significant increase in requests for pointers. Asking questions is an healthy part of learning, but asking for 'pointers' is _not_ going to be particularly helpful. It shifts the effort to the person answering the question rather then the person asking the question. Effectively asking questions is an art. Asking question is so important that Eric Raymond, author of the Cathedral and the Bazaar, has written and maintained an article about how to ask questions the smart way at http://www.catb.org/esr/faqs/smart-questions.html . I strongly suggest reading the article. The time spent learning how to ask questions the smart way... and asking questions the smart way will pay for itself very quickly. Questions asked the smart way will generally get quicker responses and better answers. Two additional points -- If you are new to the list please clearly describe 1) What you know, 2) What you don't know, 3) and what you think you have to learn to solve your problem. This provides the person answering the question a sense of scope. The answer someone provides is based on the knowledge and needs for the person asking the question. -- Answer as many questions as you ask. david > Please provide pointers on the following problems- > > 1. Please explain me the code "model, _iter = column.get_selected()" > > 2. How can i check when is the language to be translated is being changed. > > Regards > > ishan > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v3 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
Excerpts from Anurag Chowdhury's message of Fri Oct 08 00:06:02 +0200 2010: > v2 was Reviewed-By: Sascha Silbe No, I certainly did NOT give my Reviewed-By on this code. As I already told Ishan [2]: >> I reviewed it, but since there were things I wanted to be >> changed, I did not "grant" my Reviewed-By: tag. The meaning of that >> tag is that I reviewed the patch _and_ believe it to be fit for >> inclusion, standing with my reputation behind that judgement (see [1], >> section 14). Sascha [1] http://www.kernel.org/doc/Documentation/SubmittingPatches [2] https://lists.sugarlabs.org/archive/sugar-devel/2010-September/027376.html -- 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] Proposal of dotted activity version number
On 4 October 2010 15:27, Gonzalo Odiard wrote: > What do others think about this approach? Packagers? A clearer way to discuss this would be to just send a patch. That way there is no doubt over the details of the implementation that you are proposing. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On Thu, Oct 07, 2010 at 12:45:11PM -0300, Gonzalo Odiard wrote: On Thu, Oct 7, 2010 at 12:22 PM, Jonas Smedegaard wrote: So the proposed 1.2.3-peru numbering scheme really is a 1.2.3 scheme with an optional trailing taint hint? [snip] It probably makes better sense to clearly distinguish those two essentially separate issues: [snip] It's clear in the previous examples? Nope. You insist on discussing both issues together. Very confusing. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Schedule after Sugar 0.90.0 is released --- or "After the game is before the game"
On 10/07/2010 06:28 PM, David Farning wrote: On Thu, Oct 7, 2010 at 2:38 AM, Simon Schampijer wrote: On 10/06/2010 04:54 PM, Simon Schampijer wrote: === Testing 0.90 === So far we have not seen much testing of 0.90 yet, that is why the bug fix releases noted above are so important to us. We need as well your help to actually discover the bugs! There are basically three ways how you can test as of today (besides using sugar-jhbuild): * Install Fedora 14 on a machine and install the Sugar desktop * Test using Sugar on a stick: Get one of the nightly snapshots [4] and put it on a usb key. You can find instructions about it at [5]. It is good to subscribe to the Soas mailing list (low traffic) [6] for announcement and discussions in that case. * If you have an XO (XO-1 or XO-1.5) you can use an image from [7]. If you are aware of any other distribution where Sugar 0.90 can be tested easily please comment. Ubuntu Sugar Remix is being released in about three days. Releasing USR with sugar .90 required us to coordinate too many moving pieces. I expect that .90 will be available on Debian within two week (thanks Jonas). We will then sync the Debian packages to Ubuntu Maverick (they will be available in a ppa) a week or so later (thanks Seeta). david Thanks David, these are great news! Please keep us posted. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH v3 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
When we click on the icon of an activity we see a pulsing icon of that activity before the activity starts and usually there is a time delay between the clicking of the icon and appearance of the pulsing icon , where tha amount of delay differs by the complexity of the icon i.e. more complex the icon is larger is the delay. So here we tried to reduce that delay if not completely obliterate it , by making the duration of the first 5 pulses larger and during these 5 times the icon will only be zoomed in and not zoomed out so as to reduce the frame calculation load on the processor, Hence reducing the delay. --- src/sugar/graphics/animator.py |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) v1 was Reviewed-By: Simon Schampijer v2 was Reviewed-By: Sascha Silbe v2->v3 Corrected Range parameter in the for loop and reformatted the code according to pep-8 diff --git a/src/sugar/graphics/animator.py b/src/sugar/graphics/animator.py index 8fb298b..3121e6e 100644 --- a/src/sugar/graphics/animator.py +++ b/src/sugar/graphics/animator.py @@ -25,7 +25,7 @@ import gobject EASE_OUT_EXPO = 0 EASE_IN_EXPO = 1 - +i = 1 class Animator(gobject.GObject): @@ -140,6 +140,10 @@ class Animation(object): # last frame frame = self.end else: +for i in range(0, 5): +easing = EASE_IN_EXPO +duration = duration * 100 +i = i + 1 if easing == EASE_OUT_EXPO: frame = change * (-pow(2, -10 * t / duration) + 1) + start elif easing == EASE_IN_EXPO: -- 1.7.2.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Schedule after Sugar 0.90.0 is released --- or "After the game is before the game"
On Thu, Oct 7, 2010 at 2:38 AM, Simon Schampijer wrote: > On 10/06/2010 04:54 PM, Simon Schampijer wrote: >> >> === Testing 0.90 === >> So far we have not seen much testing of 0.90 yet, that is why the bug >> fix releases noted above are so important to us. We need as well your >> help to actually discover the bugs! There are basically three ways how >> you can test as of today (besides using sugar-jhbuild): >> >> * Install Fedora 14 on a machine and install the Sugar desktop >> >> * Test using Sugar on a stick: Get one of the nightly snapshots [4] and >> put it on a usb key. You can find instructions about it at [5]. It is >> good to subscribe to the Soas mailing list (low traffic) [6] for >> announcement and discussions in that case. >> >> * If you have an XO (XO-1 or XO-1.5) you can use an image from [7]. >> >> If you are aware of any other distribution where Sugar 0.90 can be >> tested easily please comment. Ubuntu Sugar Remix is being released in about three days. Releasing USR with sugar .90 required us to coordinate too many moving pieces. I expect that .90 will be available on Debian within two week (thanks Jonas). We will then sync the Debian packages to Ubuntu Maverick (they will be available in a ppa) a week or so later (thanks Seeta). david > In some cases there are new rpms for Sugar 0.90 that are not in a build yet > and you want to verify if those fix an issue, you can do the following: > > - download the new rpm and put it on a usb-key. > > - insert that usb-key in an XO > > - open a terminal and to become user root type: > su > > - then update the rpm with the following command: > rpm -U sugar-0.90.2-1.fc14.noarch.rpm > > Note: You have to add the path to the file on the usb-key to the command > from above. Usually the path is something like /media/[random > characters]/sugar-0.90.2-1.fc14.noarch.rpm > > Sugar is a noarch rpm [1] for sugar-toolkit you have to pick the i686 rpm > [2]. > > - then restart Sugar > > Regards, > Simon > > [1] sugar: http://koji.fedoraproject.org/koji/buildinfo?buildID=199034 > [2] sugar-toolkit: > http://koji.fedoraproject.org/koji/buildinfo?buildID=199033 > > > ___ > 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] Memory leak in Sugar -- how to dump Py data
On Thu, Oct 7, 2010 at 11:53 AM, Martin Langhoff wrote: > Great. thanks! Setup a test machine and keeping an eye on it. Even without waiting much, it's clear we're leaking objects referred to the UI representation of the access points. `iwlist scan ` spots 37 APs, and that's roughly what you see in the UI. Some with weak signal appear and disappear -- How did I find this? Using heapy, I see that the top 3 entries have 120, 120 and 363 objects, and they grow "in concert". When I "dump" the entries of the top one with .theone, the object looks like a UI widget for an AP. If I do for n in range(120): hp.heap()[0].byid[n].theone['_primary_text'] what I see is the ESSIDs of the APs -- repeated multiple times. cheers, m -- martin.langh...@gmail.com 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] Memory leak in Sugar -- how to dump Py data
On Thu, Oct 7, 2010 at 10:47 AM, Michael Stone wrote: > Tomeu wrote some instructions here: > > http://wiki.laptop.org/go/Memory_leak_testing > http://wiki.sugarlabs.org/go/Development_Team/Memory/Leak_testing (mirror) Great. thanks! Setup a test machine and keeping an eye on it. m -- martin.langh...@gmail.com 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] Proposal of dotted activity version number
On Thu, Oct 7, 2010 at 12:22 PM, Jonas Smedegaard wrote: > So the proposed 1.2.3-peru numbering scheme really is a 1.2.3 scheme with > an optional trailing taint hint? > > Yes, the last part is optional. In my first mail I put examples of valid numbers: Valid numbers: 23 23.2 23.2.5 23.2.5-peru 23.2.5-uru Then for the activity developers, probably they will continue with integer numbers, but other players have other possibilities: * OLPC or Dextrose can create version activities where are maintaining old releases: example Browse 108.1 * Daniel Castelo and the people from LATU in Uruguay can create a customization to a activity: example Speak 18.1-uru * People from other deployments can test and use the activity modified in Uruguay. The packagers will need to package only the common activities. The dotted scheme is supported for dpkg, rpm, etc. It probably makes better sense to clearly distinguish those two essentially > separate issues: > > * mainline numbering >+ integer >+ triple integers >+ Debian-style triple string scheme >+ other? > * how to officially handle "slight forks" >+ extending triple integers with fourth integer/string >+ non-version suffix to version >+ separate field >+ no official support >+ other? > > It's clear in the previous examples? > The easiest for Debian would be if you version your code using triple > integers, as that properly supports multiple branches (which you _are_ > doing, whether you admit it or not!). > > debian care not about deployment forks, but I sure recommend that you do > support it properly - which means make room for it in the versioning string > and admit that forks are versioned too - not only a non-versioned flag. > > I don't think we need to support versioning in the forks (uru or peru cases). They can use the first part, adding numbers to manage their versions. Gonzalo > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCgAGBQJMreWmAAoJECx8MUbBoAEhfpIP/2P6RWUKyJF5IMoE0LBMaG29 > 3CX9WkTSp7M3eh6S2zaJYxvU6HgOxDAYqbtYctyRbtIX+z7tFSvS4RIanwGcUYbr > b6xX5l1p2YYpvT3P8JCSNAb90bwdmsOByYvhcDJuvZ1rDJlLl9t/jFn6bnvHaIZi > VrNh3FxNMg1rK1JMBtSTmKLJKRdKszHJQz6eC/0xr6E8kFq4VeuppHkyvSxa8HCq > /oXL1nzylVziPDrdGWqrDfqMr+sQ/hv1O77M9brDYEWZfXfjoJxmKFEDDbbAr18O > rI90kzat19lWvZGnS/PyZxS2SMY9NbK8b4yWC8p+luKx/2gP5dsw6V/JMIX0besB > ju1kEMQFzt/hZSgWhynjqNED1iyr+5IUFLmA9NLzuFhmS0nJ26L4277Q4heEk7/L > 9lR0cnic902RVIY60sr3p9bZklNrVIGIST5RJzuj8n6/CPJfctTL0NBsxzwVS0SB > 7lXhfrDd6JV122fxXeKHI95hFZroHsSby2GoLLIbTmbrV1CjqyvZ4Uz521xSCYjQ > FAIeO9+khwNXLzg99O9lsTfpm8q0yiPLHmq0HeORGFzCwnnhf5E6FRLTrd0JGass > jFqYSz/bsmgEji9YUIHs1gpIFInLU/1oOQgQswVopIKHTxLeYcH3evt6c3fD9QwM > mY8cqELdjJxbTEoHgT54 > =P0DA > -END PGP SIGNATURE- > > ___ > 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] Testing Problem using Fedora LiveUSB Creator (was: Schedule after Sugar 0.90.0 is released)
FWIW, I've been trying to give recent daily builds a test run - both to spot problems in the projected 0.90 release and see how my own activities fare. I download the x386 .iso and install it with Fedora LiveUSB Creator (v3.9 - see further below) on my WinXP system. All goes along fine until I attempt to boot my computer using the resultant USB stick. It won't boot. It gets to a test screen with a SYSLINUX line at the top and a blinking dot on line 2, and stays there. Final SoaS builds boot fine via LiveUSB Creator, but to my knowledge, all nightly SoaS builds I've tried have suffered the above fate. Is this expected? Is there a (simple) alternative? (Is this a bug?) Also (Luke), I've had to use v3.9 to make my SoaS sticks rather than v3.9.2. The latter won't install on my XP machine; it complains about a configuration error and suggests reinstalling (which I've done to no avail). I've also uninstalled before reinstalling; nothing seems to help. Reverting to v3.9, everything works fine. Art Hunkins - Original Message - From: "Simon Schampijer" To: "Sugar Devel" Sent: Wednesday, October 06, 2010 10:54 AM Subject: [Sugar-devel] [ANNOUNCE] Schedule after Sugar 0.90.0 is released --- or "After the game is before the game" Dear Sugar community, after successfully releasing 0.90 there should be a to celebrate what has been achieved and then we can start thinking what to do next. Some items are rather near term goals but there is as well the long road that leads to a new release --- 0.92 (1.0). === Branching === After the final release of a module, a branch should be created to host further stable development. If you do not have an 'unstable' commit yet you can leave your branch as is, as this ease the work for translators by not having to translate for two branches. The details about branching are described at [1]. === Bug fix release === To make sure we have the latest packages in F14 before the Final Change deadline happens the 18th of October [2], I added another bug fix release [3]. As Fedora is the bleeding edge at the moment we just backpack on this date. * 0.90.1 will be the 15th of October * 0.90.2 will be the 27th of October === Testing 0.90 === So far we have not seen much testing of 0.90 yet, that is why the bug fix releases noted above are so important to us. We need as well your help to actually discover the bugs! There are basically three ways how you can test as of today (besides using sugar-jhbuild): * Install Fedora 14 on a machine and install the Sugar desktop * Test using Sugar on a stick: Get one of the nightly snapshots [4] and put it on a usb key. You can find instructions about it at [5]. It is good to subscribe to the Soas mailing list (low traffic) [6] for announcement and discussions in that case. * If you have an XO (XO-1 or XO-1.5) you can use an image from [7]. If you are aware of any other distribution where Sugar 0.90 can be tested easily please comment. === 0.92 === Based on the GNOME schedule I made a first draft of the 0.92 roadmap. I reintroduced the "Feature Acceptance" milestone. The idea is that the discussion about a feature does not start one day before the feature freeze. As stated in the Feature policy [9] the acceptance is a sanity check, presumed in most cases to be a formality, to ensure that new features compliment Sugar guidelines and is manageable, prior to publicizing as officially targeted for the next release. The actual code must be ready by the Feature Freeze and is reviewed by the module maintainer. On behalf of the Sugar community, Your Release Team [1] http://wiki.sugarlabs.org/go/Development_Team/Release#Branching [2] https://fedoraproject.org/wiki/Releases/14/Schedule [3] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [4] http://alt.fedoraproject.org/pub/alt/nightly-composes/soas [5] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation [6] http://lists.sugarlabs.org/listinfo/soas [7] http://dev.laptop.org/~erikos/F14_builds/ [8] http://wiki.sugarlabs.org/go/0.92/Roadmap#Schedule [9] http://wiki.sugarlabs.org/go/Features/Policy#Acceptance_of_a_feature ___ 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] Proposal of dotted activity version number
So the proposed 1.2.3-peru numbering scheme really is a 1.2.3 scheme with an optional trailing taint hint? It probably makes better sense to clearly distinguish those two essentially separate issues: * mainline numbering + integer + triple integers + Debian-style triple string scheme + other? * how to officially handle "slight forks" + extending triple integers with fourth integer/string + non-version suffix to version + separate field + no official support + other? The easiest for Debian would be if you version your code using triple integers, as that properly supports multiple branches (which you _are_ doing, whether you admit it or not!). debian care not about deployment forks, but I sure recommend that you do support it properly - which means make room for it in the versioning string and admit that forks are versioned too - not only a non-versioned flag. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Memory leak in Sugar -- how to dump Py data
See http://dev.laptop.org/ticket/10386 for details. The sugar-session process in 10.1.2 grows slowly... There's some form of leak somewhere. Maybe we are triggerin a real python leak, maybe we have reference loops. How do we trace this? Tomeu wrote some instructions here: http://wiki.laptop.org/go/Memory_leak_testing http://wiki.sugarlabs.org/go/Development_Team/Memory/Leak_testing (mirror) that might be of use to you. Also, it looks like guppy is now available directly from Fedora, packaged under the name "python-guppy". Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Memory leak in Sugar -- how to dump Py data structures?
See http://dev.laptop.org/ticket/10386 for details. The sugar-session process in 10.1.2 grows slowly... There's some form of leak somewhere. Maybe we are triggerin a real python leak, maybe we have reference loops. How do we trace this? m -- martin.langh...@gmail.com 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
[Sugar-devel] "Make Your Own Sugar Activites!" is on Lulu.com
A couple of people had expressed interest in buying a printed copy of "Make Your Own Sugar Activities!" from Lulu.com, only to find it was not available. We had to remove it from the site to rework the book, making the fonts bigger and more readable, improving the page breaks, and creating brand new art for the front cover. I just got a review copy this weekend and it's a vast improvement. We've made the book available again, and you can get it here: http://www.lulu.com/product/paperback/make-your-own-sugar-activities/12995552 It's available as a beautiful Crown Quarto sized paperback and also as a free PDF download which is perfect for use with the Read Activity. This might be a great stocking stuffer for that special geek in your life. I don't get any money from the sales of this book; that goes to FLOSS Manuals, who provided the software that made creating the book possible. That doesn't mean I don't want it to be a best seller! James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Downgrading activities not allowed. (#2164)
From: Shanjit Singh Jajmann , Anubhav Aggarwal
Downgrading an activity is now made possible. When a .xo file of a version
older than the currently installed version is clicked, a downgrading option is
made available, by popping up of a confirmation alert. Depending upton the
choice selected you can downgrade the activity.
---
src/jarabe/journal/journalactivity.py | 36 +++--
src/jarabe/journal/listview.py|7 +++-
src/jarabe/journal/misc.py| 56 -
src/jarabe/model/bundleregistry.py| 18 +++---
4 files changed, 91 insertions(+), 26 deletions(-)
mode change 100644 => 100755 src/jarabe/journal/misc.py
mode change 100644 => 100755 src/jarabe/model/bundleregistry.py
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..2af55d3 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -28,6 +28,7 @@ import os
from sugar.graphics.window import Window
from sugar.graphics.alert import ErrorAlert
+from sugar.graphics.alert import ConfirmationAlert
from sugar.bundle.bundle import ZipExtractException, RegistrationException
from sugar import env
@@ -128,7 +129,7 @@ class JournalActivity(Window):
self.connect('window-state-event', self.__window_state_event_cb)
self.connect('key-press-event', self._key_press_event_cb)
self.connect('focus-in-event', self._focus_in_event_cb)
-
+
model.created.connect(self.__model_created_cb)
model.updated.connect(self.__model_updated_cb)
model.deleted.connect(self.__model_deleted_cb)
@@ -136,7 +137,6 @@ class JournalActivity(Window):
self._dbus_service = JournalActivityDBusService(self)
self.iconify()
-
self._critical_space_alert = None
self._check_available_space()
@@ -145,7 +145,29 @@ class JournalActivity(Window):
alert.connect('response', self.__alert_response_cb)
self.add_alert(alert)
alert.show()
-
+
+def __activity_alert1_cb(self):
+ if misc.check_previous_install() == 1 and misc.return_checked()==0:
+ alert1 = ConfirmationAlert()
+ logging.debug('value of misc is %d',
misc.check_previous_install())
+ alert1.props.title=_('Previous Version Found')
+ alert1.props.msg = _('A previous version of an installed activity
was found. Are you sure you want to continue with installation ?
If Yes click Ok and the
activity icon of the older .xo file in the Journal')
+ alert1.connect('response', self.__alert1_response_cb)
+ self.add_alert(alert1)
+ alert1.show()
+
+def __alert1_response_cb(self, alert1, response_id):
+if response_id is gtk.RESPONSE_OK:
+logging.debug('value of checked initial %d', misc.return_checked())
+logging.debug('Installing previous version')
+self.remove_alert(alert1)
+misc.checked = 1
+logging.debug('value of checked final %d', misc.return_checked())
+
+elif response_id is gtk.RESPONSE_CANCEL:
+logging.debug('Cancelled by user')
+self.remove_alert(alert1)
+
def __alert_response_cb(self, alert, response_id):
self.remove_alert(alert)
@@ -166,6 +188,8 @@ class JournalActivity(Window):
self._list_view = ListView()
self._list_view.connect('detail-clicked', self.__detail_clicked_cb)
self._list_view.connect('clear-clicked', self.__clear_clicked_cb)
+self._list_view.connect('icon-clicked', self.__icon_clicked_cb)
+logging.debug('icon clicked in main')
self._main_view.pack_start(self._list_view)
self._list_view.show()
@@ -195,7 +219,11 @@ class JournalActivity(Window):
keyname = gtk.gdk.keyval_name(event.keyval)
if keyname == 'Escape':
self.show_main_view()
-
+
+def __icon_clicked_cb(self,a):
+ logging.debug('value of misc is %d',
misc.check_previous_install())
+ self.__activity_alert1_cb()
+
def __detail_clicked_cb(self, list_view, object_id):
self._show_secondary_view(object_id)
diff --git a/src/jarabe/journal/listview.py b/src/jarabe/journal/listview.py
index 3d6281a..3dbcc2d 100644
--- a/src/jarabe/journal/listview.py
+++ b/src/jarabe/journal/listview.py
@@ -466,8 +466,12 @@ class ListView(BaseListView):
__gsignals__ = {
'detail-clicked': (gobject.SIGNAL_RUN_FIRST,
gobject.TYPE_NONE,
- ([object]))
+ ([object])),
+'icon-clicked': (gobject.SIGNAL_RUN_FIRST,
+ gobject.TYPE_NONE,
+ ([]))
}
+
def __init__(s
Re: [Sugar-devel] [PATCH v2 Sugar] Pulsing icon delayed by 5 seconds or so SL#2080
Excerpts from Anurag Chowdhury's message of Thu Oct 07 20:26:41 +0200 2010: > +COUNTER = 1 > > class Animator(gobject.GObject): Please see PEP-8 [1], "Code lay-out", "Blank Lines", first paragraph. > +for COUNTER in range(0, 5): > + easing = EASE_IN_EXPO > + duration = duration*100 > + COUNTER = COUNTER + 1 Please read the Python tutorial regarding for-loops [2] and the range function [3]. Also local variables should be lowercase. Sascha [1] http://www.python.org/dev/peps/pep-0008/ [2] http://docs.python.org/tutorial/controlflow.html#for-statements [3] http://docs.python.org/tutorial/controlflow.html#the-range-function -- 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] Proposal of dotted activity version number
On Wed, Oct 6, 2010 at 8:58 AM, Gonzalo Odiard wrote: > > > On Tue, Oct 5, 2010 at 9:49 PM, C. Scott Ananian wrote: > >> If you're going to use something other than simple integers, I suggest >> either: >> >> a) a string of dotted integers. You should *always* be able to >> subdivide a release if necessary. >> Strings like "peru" belong (in my opinion) in release notes or the >> name of the activity or anywhere else. They don't tell you anything >> about version ordering. If the problem is that you can't put a new >> release between 0 and 1, why are you creating a system that causes the >> same problem, except between 0.0.0 and 0.0.1? >> >> > Yes, you are right. The string part don't tell us anything about version > ordering > The idea is use a string of dotted integers to indicate the order and the > string part only to indicate a customization. > Why? We have activity groups today for this. > Because a teacher, a kid or a technician from Uruguay can see Peru have a > customization, download, test and use. > But the customization part does not imply order because it's not logic use > the alphabetic order (Peru < Ruanda < Uruguay?) > Then I plan to ignore the customization when I compute the order. > > >> b) use the debian version numbering system *exactly*. It has been >> shown to work in the real world, and it is well documented. The >> current proposal is neither (yet). We do not need to burden the world >> with yet another ad-hoc numbering system. Please build on other >> people's work instead of re-inventing the wheel. Just because the >> debian system has features you don't *think* you need (yet) is not a >> reason to bypass it. There are great benefits to sharing a commons. >> >> > I agree with not reinvent the wheel, but not with using the debian > versions. Why not the Fedora, Gentoo or OSX? > If you want, we will be using the linux kernel numbering system :) > > > >> Of course, my preference is to keep the existing simple integers and >> solve the version precedence problem in other ways. Perhaps important >> activities should be encouraged to "count by ten" when increasing >> verson numbers -- or perhaps the tight dependency of Browse on a given >> Sugar version should be fixed. >> >> > Integer number does not solve the problems we have today. > Not the problems of the developers, but the downstreams. > I am working with OLPC fixing Browse in sugar 0.84. The version we are > using is Browse 108, but I cant release Browse 109 because already exists. > The same problem we have, will have Dextrose or anybody who maintains a > older branch. > I Agree, is a real problem that we have in deployments. > And "count by ten" it's not a good idea. > > > >> A truely forward-thinking replacement would replace the integer >> version numbers with a git-style version tree. Just say, "this >> activity replaces the activity bundle with manifest hash abcdef". >> That is more decentralized, and more accurate. Each activity >> could/should contain a list of URLs describing the canonical source >> for both itself (authoritative) and its (say) 10 immediate parents >> (non-authoritative). This proposal could be elaborated -- and it >> paves the way for a truely decentralized activity repository, where >> activities are created *and hosted* by children *on their own >> machines*. (Isn't this stil the vision of Sugar?) >> > > No. Git it's fantastic but it's not the solution to all. > That would be a clear example of "Second system effect" [1] > > Gonzalo > > > [1] http://en.wikipedia.org/wiki/Second-system_effect > > >> --scott >> ___ >> 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 > > -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 2 601 57 73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH v2 Sugar] Pulsing icon delayed by 5 seconds or so SL#2080
When we click on the icon of an activity we see a pulsing icon of that activity before the activity starts and usually there is a time delay between the clicking of the icon and appearance of the pulsing icon , where tha amount of delay differs by the complexity of the icon i.e. more complex the icon is larger is the delay. So here we tried to reduce that delay if not completely obliterate it , by making the duration of the first 5 pulses larger and during these 5 times the icon will only be zoomed in and not zoomed out so as to reduce the frame calculation load on the processor, Hence reducing the delay. --- src/sugar/graphics/animator.py |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) v1 was Reviewed-By : Simon Schampijer v1->v2 : reformated code style using pylint and pep-8 format diff --git a/src/sugar/graphics/animator.py b/src/sugar/graphics/animator.py index 8fb298b..335c69e 100644 --- a/src/sugar/graphics/animator.py +++ b/src/sugar/graphics/animator.py @@ -25,7 +25,7 @@ import gobject EASE_OUT_EXPO = 0 EASE_IN_EXPO = 1 - +COUNTER = 1 class Animator(gobject.GObject): @@ -140,6 +140,10 @@ class Animation(object): # last frame frame = self.end else: +for COUNTER in range(0, 5): + easing = EASE_IN_EXPO + duration = duration*100 + COUNTER = COUNTER + 1 if easing == EASE_OUT_EXPO: frame = change * (-pow(2, -10 * t / duration) + 1) + start elif easing == EASE_IN_EXPO: -- 1.7.2.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Alt-tab key does not work in F14 and sugar-emulator #2300
Excerpts from Simon Schampijer's message of Thu Oct 07 09:52:19 +0200 2010: > Bernie can you give some light on the issue in Xorg and where it has > been fixed, if? See [1] for a start. > Right, best would be of course to get the Xorg fix in distros. That would require someone to isolate the commit that fixed it and backport it to the Xorg versions the distros are shipping. I have no idea how much effort that would be. Sascha [1] https://lists.sugarlabs.org/private/sugar-devel/2010-September/027099.html -- 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] Alt-tab key does not work in F14 and sugar-emulator #2300
On Thu, 2010-10-07 at 09:52 +0200, Simon Schampijer wrote: > Hi Sascha, > > thanks for your comments. > > On 10/06/2010 03:38 PM, Sascha Silbe wrote: > > Excerpts from Simon Schampijer's message of Wed Oct 06 15:21:29 +0200 2010: > > > >> I have been bumping into [1] [...] > > > > Just to avoid confusion: This has nothing to do with how you run Sugar > > (i.e. it will occur both with sugar-emulator and running Sugar as a > > "regular" desktop session). It is (according to Bernie - I didn't quite > > grok the code) a bug in some versions of Xorg and will appear on some > > distro versions, independent of how you installed Sugar (native distro > > packages or sugar-jhbuild). > > > > It's supposed to be fixed (haven't checked myself yet) in recent Xorg > > versions. Bernie has also written a patch that lets metacity work around > > the bug. With that patch applied, "metacity-message disable-keybindings" > > works fine again. > > Bernie can you give some light on the issue in Xorg and where it has > been fixed, if? For those tuning in just now, the testcase we're trying to fix is getting Metacity to effectively release keys such as Alt-TAB when someone executes "metacity-message disable-keybindings" from the command-line. This Metacity patch fixed the problem for me on Fedora 11: http://people.sugarlabs.org/bernie/patches/gnome/metacity/pending/ungrab-x-keybindings-when-they-are-disabled.patch It works by making Metacity ungrab each key individually rather than trying to ungrab them all at once with XUngrabKey(AnyKey, AnyModifier), which does not seem to work as advertised in the manpage. > Right, best would be of course to get the Xorg fix in distros. Bernie > might have made the metacity workaround with a good reason, though. > Let's see, I hope Bernie can point us to the Xorg issue. I thought the problem had been fixed in the X server by recent commits to dix/grabs.c:DeletePassiveGrabFromList(), but apparently it's still there. Now I'm a little confused, because ungrabbing seems to work on at least some systems. I'm not sure which particular combinations of X server and Metacity can trigger it. These are the suspected functions, we still have no incriminating evidence to declare one them them definitely guilty: http://cgit.freedesktop.org/xorg/xserver/tree/dix/grabs.c#n417 http://git.gnome.org/browse/metacity/tree/src/core/keybindings.c#n737 Perhaps Peter or Owen can shred some light? -- // 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] Freeing resources when switching away from activity
Excerpts from Tomeu Vizoso's message of Thu Oct 07 10:28:03 +0200 2010: > Sounds like a very good idea to me. Filed as #2416 so we don't forget about it. Not marked as sugar-love as X11/GTK callbacks can get rather tricky. Sascha [1] https://bugs.sugarlabs.org/ticket/2416 -- 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 no #2210 words don't changed when language is changed
On Thu, Oct 7, 2010 at 08:54, Ishan Bansal wrote: > Hi > > I am working on the ticket http://bugs.sugarlabs.org/ticket/2210. > > To solve the above bug i am thinking of clearing the text in the text to be > translate box when ever the language to be translated is being changed. > Please provide suggestion on any better approach to deal with this bug. > > Please provide pointers on the following problems- > > 1. Please explain me the code "model, _iter = column.get_selected()" You should be able to find out by yourself, some references: http://www.pygtk.org/pygtk2tutorial/index.html http://www.pygtk.org/docs/pygtk/class-gtktreeselection.html#method-gtktreeselection--get-selected Regards, Tomeu > 2. How can i check when is the language to be translated is being changed. > > Regards > > ishan > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Hardcode env variable TERM to xterm #2394
On 10/07/2010 10:31 AM, Tomeu Vizoso wrote: On Wed, Oct 6, 2010 at 21:24, Sascha Silbe wrote: Excerpts from simon's message of Wed Oct 06 14:11:04 +0200 2010: Patch needed in 0.90 AFAICT it's needed on Fedora 14, not Sugar 0.90. Are we sure yet this was an intentional change by libvte and not just a mistake? In the latter case we should probably make the setting depend on specific libvte versions so we don't break if they decide to use a different set of control codes (=> different $TERM) in the future. Agreed, I think we should understand well what's going on before accepting a hack upstream. If we confirm that we need that hack, then we should put that information in a ticket and reference it from the code. Regards, Tomeu Agreed, I first thought it was another issue when reading other comments about it. I have nailed it down as the following so far: https://bugzilla.gnome.org/show_bug.cgi?id=631589 Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Hardcode env variable TERM to xterm #2394
On 10/06/2010 09:24 PM, Sascha Silbe wrote: Excerpts from simon's message of Wed Oct 06 14:11:04 +0200 2010: Patch needed in 0.90 AFAICT it's needed on Fedora 14, not Sugar 0.90. Are we sure yet this was an intentional change by libvte and not just a mistake? In the latter case we should probably make the setting depend on specific libvte versions so we don't break if they decide to use a different set of control codes (=> different $TERM) in the future. Hi Sascha, thanks for your thoughts. I have overseen the fact that we actually do set it to xterm [1]. I am just experimenting a bit to see what is going on. Regards, Simon [1] http://git.sugarlabs.org/projects/terminal/repos/mainline/blobs/master/terminal.py#line449 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Hardcode env variable TERM to xterm #2394
On Wed, Oct 6, 2010 at 21:24, Sascha Silbe wrote: > Excerpts from simon's message of Wed Oct 06 14:11:04 +0200 2010: > >> Patch needed in 0.90 > AFAICT it's needed on Fedora 14, not Sugar 0.90. > Are we sure yet this was an intentional change by libvte and not just a > mistake? In the latter case we should probably make the setting depend > on specific libvte versions so we don't break if they decide to use a > different set of control codes (=> different $TERM) in the future. Agreed, I think we should understand well what's going on before accepting a hack upstream. If we confirm that we need that hack, then we should put that information in a ticket and reference it from the code. Regards, Tomeu > Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Freeing resources when switching away from activity (was: Re: [Bugs] #2413 UNSP: Hovering over the new activity toolbar activity icon so that sub toolbar appears triggers focus_out_e
On Wed, Oct 6, 2010 at 20:51, Sascha Silbe
wrote:
> Excerpts from Sugar Labs Bugs's message of Wed Oct 06 18:16:49 UTC 2010:
>
>> I decided to keep poking at this for Physics and there does seem to be an
>> activity level fix. As per a long, long lost email from Tomeu (thanks
>> Tomeu, only took me two years to re-investigate and take action). I'm
>> connecting a callback to the visibility-notify-event and then testing if
>> data.state == gtk.gdk.VISIBILITY_FULLY_OBSCURED. Took me ages to track
>> this down, but seems to be working a treat, I'm about to test outside of
>> my VM dev environment and onto an XO-1:
>
> FWIW, this is what I do in one of my activities (a simple "digital wall
> clock"):
>
> class BigDigiClockActivity(activity.Activity):
>
> def __init__(self, handle):
> [...]
> self.can_freeze = True
> self._freeze_scheduled = False
> [...]
> self.time_label.connect('size-allocate', self._size_allocate_cb)
> self._unmap_cb_handler = None
> self.time_label.connect('unmap-event', self._unmap_cb)
> self.set_canvas(self.time_label)
> self.time_label.show()
>
> [...]
> # for debug output only
> _vis_map = {
> gtk.gdk.VISIBILITY_UNOBSCURED: 'unobscured',
> gtk.gdk.VISIBILITY_PARTIAL: 'partial',
> gtk.gdk.VISIBILITY_FULLY_OBSCURED: 'fully obscured',
> }
> def _visibility_cb(self, widget, event, *args):
> """X window has changed."""
> logging.debug('visibility = %r', self._vis_map.get(event.state,
> event.state))
> self._set_may_freeze(event.state == gtk.gdk.VISIBILITY_UNOBSCURED)
>
> def _unmap_cb(self, *args):
> """X window has been unmapped (i.e. is invisible now)."""
> logging.debug('unmap')
> self._set_may_freeze(False)
>
> def _size_allocate_cb(self, widget, allocation, *args):
> """Size for self.time_label has been (re)set.
>
> Recalculate font size if necessary."""
> [...]
> if self._unmap_cb_handler is None:
> window = self.time_label.get_parent()
> self._unmap_cb_handler = window.connect('unmap-event',
> self._unmap_cb)
> window.connect('visibility-notify-event', self._visibility_cb)
> window.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK)
>
> [...]
> def _set_may_freeze(self, may_freeze):
> self._hide_cursor(may_freeze)
> self.may_freeze = may_freeze
> if may_freeze:
> self._schedule_freeze()
> else:
> self._set_dcon_freeze(False)
>
>
> For other activities there might be a better match than size-allocate
> for when to connect the callbacks to the window.
>
> Perhaps we could move some of this to sugar.activity.activity.Activity
> so activity authors could concentrate on the resource freeing part?
> Maybe even coupled with a timer to prevent us from slowing down quick
> activity switches (i.e. the user switching forth and back between two
> activities in quick succession).
Sounds like a very good idea to me.
Regards,
Tomeu
> Sascha
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Alt-tab key does not work in F14 and sugar-emulator #2300
Hi Sascha, thanks for your comments. On 10/06/2010 03:38 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Wed Oct 06 15:21:29 +0200 2010: I have been bumping into [1] [...] Just to avoid confusion: This has nothing to do with how you run Sugar (i.e. it will occur both with sugar-emulator and running Sugar as a "regular" desktop session). It is (according to Bernie - I didn't quite grok the code) a bug in some versions of Xorg and will appear on some distro versions, independent of how you installed Sugar (native distro packages or sugar-jhbuild). It's supposed to be fixed (haven't checked myself yet) in recent Xorg versions. Bernie has also written a patch that lets metacity work around the bug. With that patch applied, "metacity-message disable-keybindings" works fine again. Bernie can you give some light on the issue in Xorg and where it has been fixed, if? ISTR somebody got in touch with the metacity maintainers to land the workaround, but don't know what got of it. To get the workaround (or an Xorg fix) into distros we will also need to report this bug to them. For Debian nobody did this so far and for Ubuntu there has been no follow-up from the reporter so the ticket is marked as Incomplete. [1] Right, best would be of course to get the Xorg fix in distros. Bernie might have made the metacity workaround with a good reason, though. Let's see, I hope Bernie can point us to the Xorg issue. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Schedule after Sugar 0.90.0 is released --- or "After the game is before the game"
On 10/06/2010 04:54 PM, Simon Schampijer wrote: === Testing 0.90 === So far we have not seen much testing of 0.90 yet, that is why the bug fix releases noted above are so important to us. We need as well your help to actually discover the bugs! There are basically three ways how you can test as of today (besides using sugar-jhbuild): * Install Fedora 14 on a machine and install the Sugar desktop * Test using Sugar on a stick: Get one of the nightly snapshots [4] and put it on a usb key. You can find instructions about it at [5]. It is good to subscribe to the Soas mailing list (low traffic) [6] for announcement and discussions in that case. * If you have an XO (XO-1 or XO-1.5) you can use an image from [7]. If you are aware of any other distribution where Sugar 0.90 can be tested easily please comment. In some cases there are new rpms for Sugar 0.90 that are not in a build yet and you want to verify if those fix an issue, you can do the following: - download the new rpm and put it on a usb-key. - insert that usb-key in an XO - open a terminal and to become user root type: su - then update the rpm with the following command: rpm -U sugar-0.90.2-1.fc14.noarch.rpm Note: You have to add the path to the file on the usb-key to the command from above. Usually the path is something like /media/[random characters]/sugar-0.90.2-1.fc14.noarch.rpm Sugar is a noarch rpm [1] for sugar-toolkit you have to pick the i686 rpm [2]. - then restart Sugar Regards, Simon [1] sugar: http://koji.fedoraproject.org/koji/buildinfo?buildID=199034 [2] sugar-toolkit: http://koji.fedoraproject.org/koji/buildinfo?buildID=199033 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
