Re: [Sugar-devel] gtk.Label expanding/aligning issue
On Fri, Sep 18, 2009 at 23:10, Lucian Branescu lucian.brane...@gmail.com wrote: I'm having trouble with making a gtk.Label expand to the whole screen. You mean the whole screen or the whole available space? I've tried various combinations of box packing options, label props and box props, no success so far. AFAICS, you have all the expand=True and fill=True that should be necessary. From just looking at the code, I would suspect the scrolled window is having an unexpected effect. My code lives here http://github.com/lucian1900/webquest Very clean code, congrats! I've also attached a screenshot with this. What's the problem with this, you would like the text to extend also to the left and right borders? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] sugar-0.85.8
On Fri, Sep 18, 2009 at 21:30, Jonas Smedegaard d...@jones.dk wrote: On Fri, Sep 18, 2009 at 12:42:58PM -0400, Tomeu Vizoso wrote: * Install sugar-emulator.desktop application file #1139 Please do not ship autogenerated desktop file with tarball. Noone but Tomeu needs a file hardcoded to execute /home/tomeu/sugar-jhbuild/install/bin/sugar-emulator :-P Ooops, thanks for telling, will look at it in a bit. Regards, Tomeu Kind regards, - 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) iQIcBAEBCgAGBQJKs9/fAAoJECx8MUbBoAEhOTkP/2zkcPvCoqP4QE8hLqpoMnb8 fgt606g7FZm0IKLdzsW6U3sNrwqBrVg0nCsUkjYQpL6mZ54gA4DOT9PsDRuCVU+d 6dFVpGH+vMBv6Ttlp/O3znOpyc3BkUcWSjkLGkpmuNvNf50XndqkeM3NwbGLzOu1 KkvWG4dd+1KPd8gOnAXg8gF0u24oWi5COb9tGfgTQsoVWphs90xsiQ4/WnwBFzEx coGn/DUE/xWxSom+Y+5qZzYczfbKGvg5jWC7uomr8gp/HZVQsJ5Z/m6rIoLEQr3V 6limtBBCMMDf44Dyt4v3z6oJu1K7P485jE+drHuvSXpyjGL2hMXLg7346NxqLyK5 ZU0OP1ax0D9mUVHAI5WYAfyMy7CiDTXrY9QT8jyfKUC+dnSxXedEgCDFjtliMcIz qW/JFnej48sLzcsR1JJff3Yciz6lw6bJkiJITepECSTTVkR99j+lm+q57gv+A8qq Aez6Sv8gKDXoQTmzlvHlUbff/0P9xFE4VxWBxO9JR1WG++xick/c6eGHDbPABKb/ ySIADgwJ8AVxlaJUTIZ82f5IHqVeVHklY/CUrjEqrcMz+VJ0xjmDvuRou7Mgr3Cr T34GiDtO8u1ZN6lveSl+xRIohQx68BhpyDf1diVTrCHLfDCHvt5yuDo6J5zJK2pd v0igHkacJlKe+OMovAQx =fsI6 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] sugar-0.85.8
On Sat, Sep 19, 2009 at 11:39:33AM +0200, Tomeu Vizoso wrote: On Fri, Sep 18, 2009 at 21:30, Jonas Smedegaard d...@jones.dk wrote: On Fri, Sep 18, 2009 at 12:42:58PM -0400, Tomeu Vizoso wrote: * Install sugar-emulator.desktop application file #1139 Please do not ship autogenerated desktop file with tarball. Noone but Tomeu needs a file hardcoded to execute /home/tomeu/sugar-jhbuild/install/bin/sugar-emulator :-P Ooops, thanks for telling, will look at it in a bit. Search for /tomeu/ - I later found more autogenerated files included than the above. Regards, - 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] [IAEP] SoaS: Searching for Decision Panel volunteers.
On Fri, Sep 18, 2009 at 22:27, Chris Ball c...@laptop.org wrote: Hi all, Sebastian Dziallas has asked for clarity on how the SoaS distribution he maintains is going to be treated and considered by SL. It doesn't seem that there's consensus, so we suggest forming a Decision Panel: On the rare occasion of a contentious issue on which no general consensus can be reached, the Oversight Board is responsible for convening a Decision Panel. The Oversight Board will be responsible for determining when a Decision Panel is required and for selecting members for the Decision Panel. Members of the Oversight Board are not permitted to serve on a Decision Panel. A Decision Panel will solicit community input, discuss (in private if they deem it necessary), reach a conclusion internally, and produce a report documenting their conclusion. (Anyone may submit advice to a Decision Panel.) The Oversight Board will review and ratify Decision Panel reports. -- http://wiki.sugarlabs.org/go/Sugar_Labs/Governance This mail is to ask for volunteers for the Decision Panel. Volunteers can be anyone with an interest in the outcome, and the Oversight Board will then vote on (a) whether to convene the panel, (b) who should be on the panel, and probably (c) what the decision being paneled is. :) Please volunteer by replying to this mail if you're interested, and please do so by Thursday September 24th so that we can run the vote at the Friday September 25th SLOBs meeting. Great idea, thanks for pushing this forward. What's the role of the panel, to take the best decision, or to summarize the community opinion? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar-devel Digest, Vol 11, Issue 89
On Fri, Sep 18, 2009 at 01:51, Bill Bogstad bogs...@pobox.com wrote: On Thu, Sep 17, 2009 at 4:29 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Sep 17, 2009 at 10:17, Elena of Valhalla elena.valha...@gmail.com wrote: On Wed, Sep 16, 2009 at 4:51 PM, Jim Simmons nices...@gmail.com wrote: [...] Fedora 11 with the included Sugar environment, [...] This does not give the child all the advantages of SoaS, but it's probably far from useless. I wonder how hard would it be to configure such fedora to look for an USB key with SoaS on it and mount its home partition at login time: this would help keeping some of the advantages of SoaS (the ability to work from any computer anywhere while keeping your journal, for one) with the added convenience of being able to use older hardware. Shouldn't be too hard, this has been proposed in the past but nobody never got to implement it. I think it will be useful in some use cases, including thin clients. Writing the code/scripts to do this is moderately easy. IF the version of the base OS and Sugar on the stick is identical to the one on the hard drive. Anything else is a potential headache. For example: Sugar has already gone through at least one journal format change which was not compatible. I think the journal format was auto upgraded the first time you ran the new software. Which is fine, IF you are going to stick with that version of Sugar. Very bad, if you plan to take your stick home (or just boot from it) and end run the previous version of Sugar. There are also potential problems with system supplied (fructose?) activities, being different on the stick vs. what is on the hard drive. Then there is honey (home directory activities) vs. glucose (core sugar environment) compatibility issues. Place some limits on what has to be supported and what scenarios you are willing to have cause disaster and maybe something will happen. Would enough people be happy with Sucrose + Ribose must be identical for this to work to make it worth spending time on? Could be, perhaps we should hear first about real world scenarios on which this could be useful? Maybe on a school with computer labs all with the same Sugar version? Is there someplace obvious that one could look at in a user's home directory to figure out what version of Sugar is on the stick in order to refuse to run if versions are different? Well, the DS directory has a file containing the version of the dir layout and index format, would that be enough? What should happen when a stick is not installed? Do you want this to be a 'normal' Fedora workstation when the Sugar stick isn't installed? Or a hard drive based SoaS install? Or a Fedora with Sugar install on the hard drive? I can probably come up with a half dozen other possible use cases. Clarify your desires/use cases and maybe someone (maybe even me) will spend some time on it. Yeah, wonder how we can get more info about what is needed from the field. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.85.9
Hi, this release just removes some autogenerated files from the tarball. Thanks to Jonas Smedegaard for noticing it and to Daniel Drake for telling the solution. == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.85.9.tar.bz2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] SLOBs Position on SoaS
2009/9/19 Chris Ball c...@laptop.org: Should Sugar Labs be a Linux distributor, rather than just an upstream producing Sugar releases? Should SL be neutral about distributions containing Sugar, and refuse to endorse one over another? Should 'Sugar on a Stick' be a phrase that SL asks its community to avoid using unless they refer to the SoaS-Fedora distribution? After speaking with Sebastian on IRC, I think we concluded that really only the 3rd question is of importance to him at this time. The other 2, which may involve a lot more consideration and discussion could be avoided for now (that would be my vote). The 3rd question is important to Sebastian because of some doubt regarding the 'ownership' and usage of the name Sugar on a Stick. This is perfectly understandable given that: - Sugar on a stick has been a concept within the community for a long time, only recently has it become a solid, mainstream implementation (and even then, there was still a strong element of concept in the marketing) - Non-Fedora distros have also started making sugar distros that run from live USB, and although they haven't been named Sugar on a stick, I recall at least a few mentions from people in the community referring to them that way - Another party registered the domain name sugaronastick.com This question has been discussed on the mailing list a few times and we have a couple of conflicting responses: 1. Give the name Sugar on a stick to Sebastian's project and discourage anyone else from using it 2. Let him use the name for now, but make no promises because if we find a better live USB project in the future, we'll move the sugar on a stick name over to *that* one (for the purposes of clarity of marketing?) This is the discussion that would benefit from a decision from the oversight or decision groups, and because it's quite specific, hopefully it can be answered without too much beating around the bush. Sebastian, I hope the above is an accurate summary :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What is Sugar LiveUSB
On Fri, Sep 18, 2009 at 11:43:53PM -0600, Douglas McClendon wrote: Martin Dengler wrote: On Fri, Sep 18, 2009 at 02:54:30PM -0400, Bill Bogstad wrote: There seems to be a lack of consensus of what SoaS actually is or what it's goals (use cases) should be. I'd like to say I see your point, but across the internet that's a dangerous thing to say in the face of the somewhat amusing ambiguigty of trying to talk about that thing whose identity we can't agree upon. Here is a question from the perspective of an outsider to this list (at least until very recently)- I too was a bit confused by sugaronastick.com. Perhaps what could clear up my confusion is this simple question- Who/what is the legal entity Sugar On A Stick. None exists AFAICS. Specifically the owner of the copyright on the content of the main sugaronastick.com page, which has at the bottom (c) 2009 Sugar on a Stick. This appears to be a spurious copyright assertion, as no such legal entity exists. The owner of the domain can probably do something about it: $ whois sugaronastick.com [...] Registrant: Aristoi Consulting Services 49 Thornberry Rd Winchester, MA 01890 US [...] Administrative, Technical Contact: Meeks, Caroline carol...@meekshome.com Aristoi Consulting Services 49 Thornberry Rd Winchester, MA 01890 US 781-721-0395 I believe Caroline is aware and plans to address this confusion. -dmc Martin pgpaDQJ09fkRy.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar-devel Digest, Vol 11, Issue 89
On Sat, Sep 19, 2009 at 6:34 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Sep 18, 2009 at 01:51, Bill Bogstad bogs...@pobox.com wrote: Could be, perhaps we should hear first about real world scenarios on which this could be useful? Maybe on a school with computer labs all with the same Sugar version? From discussions, I've had with Caroline about GPA, this would be useful on some of the machines there: Low memory machines would already be setup to page to disk. Would ameliorate the slow booting of dedicated Sugar machines. Would ameliorate filesystem performance issues caused by USB 1.1 ports. Is there someplace obvious that one could look at in a user's home directory to figure out what version of Sugar is on the stick in order to refuse to run if versions are different? Well, the DS directory has a file containing the version of the dir layout and index format, would that be enough? It wouldn't be complete. I asked about Sucrose + Ribose explicitly because that encompasses the entirety of likely compatibility issues. DS versioning might be the most important one, but not the only one possible. BTW, one wacky idea I had was to have multiple SoaS versions on the hard drive in the same format as on USB flash and after figuring out which one matched the stick, boot that one off the hard disk while using the stick for the users home directory and the root filesystem overlay file. I'm not sure how to go about determine the SoaS from the squasfs/kernel/initrd file either. I don't recall of the isolinux.cfg file has this info or not.This might be a better way to determine a sticks SoaS version rather then looking in the home directory though. Bill Bogstad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] gtk.Label expanding/aligning issue
To be more precise, I'd like all the text except the first paragraph to extend to the left and right borders. 2009/9/19 Tomeu Vizoso to...@sugarlabs.org: On Fri, Sep 18, 2009 at 23:10, Lucian Branescu lucian.brane...@gmail.com wrote: I'm having trouble with making a gtk.Label expand to the whole screen. You mean the whole screen or the whole available space? I've tried various combinations of box packing options, label props and box props, no success so far. AFAICS, you have all the expand=True and fill=True that should be necessary. From just looking at the code, I would suspect the scrolled window is having an unexpected effect. My code lives here http://github.com/lucian1900/webquest Very clean code, congrats! I've also attached a screenshot with this. What's the problem with this, you would like the text to extend also to the left and right borders? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] gtk.Label expanding/aligning issue
On Sat, Sep 19, 2009 at 15:38, Lucian Branescu lucian.brane...@gmail.com wrote: To be more precise, I'd like all the text except the first paragraph to extend to the left and right borders. Do you know if the vbox they are in extends to those borders or not? I use to write a small gtk script that reproduces the widget hierarchy so I can play more easily with the different options. Regards, Tomeu 2009/9/19 Tomeu Vizoso to...@sugarlabs.org: On Fri, Sep 18, 2009 at 23:10, Lucian Branescu lucian.brane...@gmail.com wrote: I'm having trouble with making a gtk.Label expand to the whole screen. You mean the whole screen or the whole available space? I've tried various combinations of box packing options, label props and box props, no success so far. AFAICS, you have all the expand=True and fill=True that should be necessary. From just looking at the code, I would suspect the scrolled window is having an unexpected effect. My code lives here http://github.com/lucian1900/webquest Very clean code, congrats! I've also attached a screenshot with this. What's the problem with this, you would like the text to extend also to the left and right borders? Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [support-gang] which Sugar(s) will/should run on XO's? [was: Sugar-devel Digest, Vol 11, Issue 94]
On Sat, Sep 19, 2009 at 16:25, Yamandu Ploskonka yamap...@gmail.com wrote: It's hard for me to understand why we are dropping so fast support for the XO-1. I'm not sure why you say that, who is dropping support for the XO-1? I'm just pointing out that we need help coordinating the effort of doing new releases. It is not logical, does not make sense to drop the biggest user base Sugar has, except when we account for human feelings of pain and betrayal that accompany the lore involving OLPC and such. If those feelings were above the mission, I would have gotten a real job long time ago. While Sugar, as-is, is painfully slow and flaky on the XO, it is still the very best we have, And the XO is currently how Sugar makes its bigger impact, so... and while we could get away from it and proclaim mission accomplished, Not sure who is saying that. well, that didn't work for that other guy, did it? Which other guy? IMHO, yes, at some moment it's vamoose and so on, but that should not come any earlier than when we have another, bigger thing going in terms of user base. Even then I don't think it will make sense to dump aside all the learning potential of the XO-1 machines. It's true that today the needed resources are not in the place where need to be, but I see this as just an accident that will be solved at some point. I understand what you say, Tomeu, and I am grateful for it. I'm not so sure I was understood ;) I'm just afraid that, as tight as we are now, that individual would have to come from the outside, and spend a lt of time gaining credibility, and so on, before getting to a level of effectiveness that would get the job done. Why the outside? olpc-nz and the support gang are outsiders? I personally don't think that I should drop my current responsibilities and take this instead, but you could be a good candidate to lead the effort ;) We just need someone to keep track of what has been done, what is still to be done, which items are owned and which are for grabs, etc. No in-depth knowledge of anything is needed, just coordinate the different efforts that are already going on and advertise the areas that need help. Regards, Tomeu Yama Tomeu Vizoso wrote: snip About the particular effort of pushing forward one more stable release for the XO-1, I strongly think we need a single individual that will lead the effort and tie together the different teams that will be working on it. -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Glucose 0.84 and 0.85 packaged for Debian!
Hi all, As subject says, Glucose (and some of Fructose) 0.84.0 and 0.85.7 is now packaged for Debian! More info at http://wiki.debian.org/Sugar and http://wiki.sugarlabs.org/go/Community/Distributions/Debian . - 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] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!
On Sun, Sep 20, 2009 at 00:32, Jonas Smedegaard d...@jones.dk wrote: Hi all, As subject says, Glucose (and some of Fructose) 0.84.0 and 0.85.7 is now packaged for Debian! More info at http://wiki.debian.org/Sugar and http://wiki.sugarlabs.org/go/Community/Distributions/Debian . Wow, tomorrow will give it a go. Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Debian-olpc-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!
I tried them out briefly in a VM this morning, worked great. A couple of questions. I don't understand the debian work flow. I see that you are carrying .82, .84, and .85. Will you continue to carry all of them going forward? Do you have a recommended work flow for basing downstream packages on work. I got my mind wrapped around git-buildpackage last night. I cloned your work and tried build some of them on GnewSense. It there a prefered method for setting the upstream for third and lower generation packages? The best I could come up with is: 1. git.sl.org - upstream 2. manually sync /debian from git.debian.org to git.gnewsense.org 3. do final work in git.gnewsense.org david On Sat, Sep 19, 2009 at 5:43 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Sep 20, 2009 at 00:32, Jonas Smedegaard d...@jones.dk wrote: Hi all, As subject says, Glucose (and some of Fructose) 0.84.0 and 0.85.7 is now packaged for Debian! More info at http://wiki.debian.org/Sugar and http://wiki.sugarlabs.org/go/Community/Distributions/Debian . Wow, tomorrow will give it a go. Thanks, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Debian-olpc-devel mailing list debian-olpc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-olpc-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Debian-olpc-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!
Hi David - and everyone else, [please don't cross-post: respond only to OLPC list as requested] On Sat, Sep 19, 2009 at 06:49:00PM -0500, David Farning wrote: I tried them out briefly in a VM this morning, worked great. Wauw, you are quick! Good to hear that that at least initial tests work. I do expect bugs to be discovered still, as so far I have only tested the packages myself on my own laptop... I don't understand the debian work flow. I see that you are carrying .82, .84, and .85. Will you continue to carry all of them going forward? The current packages was hard work to do, as they implement a tight multi-track packaging scheme that I have never before tried out: Each git tracks one upstream subproject, with branches for each upstream branch, branches for each Debian packaging overlay, and a branch for binary diffs to recreate each registered upstream released tarball. Branch upstream tracks head of upstream development. Branch upstream-0.84 tracks upstream mainainance of older branch. Branch master is head of Debian packaging development. Branch master-0.84 tracks Debian maintainance of older branch. Branch pristine-tar contains binary diffs for tarball recreation. Branches upstream and master is branched off as upstream-0.86 and master-0.86 when needed to make room for a new round of development releases. The plan is to maintain a) newest upstream branch and b) newest stable branch and possibly c) additional older stable releases. A) and b) is sometimes one and the same, and c) depends on interest them both upstream, in the Alioth OLPC team and among users. So the end result might at some times be a single maintained branch, or it may be several. In other words, the plan is to track at least head of development and head of stable. And to leave a trail behind of all stable releases for others to spawn off from if they so choose. Do you have a recommended work flow for basing downstream packages on work. There are several ways to derive from the Debian packages: a) Create a fork of the Gits at Alioth b) Rebuild/repackage source packages released for Debian I strongly recommend to *not* fork the Gits but instead help work on getting packages released for Debian and then grab the resulting source packages and derive from there - or even better: try hard to not need to repackage at all, but stay close enough to Debian that binary packages can be used directly. I recommend this not only to work as much as possible together (which should be enough reason in itself) but also because I fear that forks on the Git level makes it more difficult to give back without complicating too much. The Git structure is pretty complex already, *without* anyone pouring in commits from sideports, backports, forwardports or whatever! That said, it _is_ possible to juggle with Git but it is *not* for beginners. And please do not expect me to help out - I already run the OLPC team as a one-man show so I have absolutely no interest in spending additional time in *not* gaining more manpower to that team. I got my mind wrapped around git-buildpackage last night. I cloned your work and tried build some of them on GnewSense. It there a prefered method for setting the upstream for third and lower generation packages? The best I could come up with is: 1. git.sl.org - upstream No. upstream is a mixture of Sugarlabs Git and Sugarlabs tarball releases merged in. 2. manually sync /debian from git.debian.org to git.gnewsense.org 3. do final work in git.gnewsense.org Is Alioth such a cruel place to work together? Is it me - am I awful to work with? Why do you ask for my advice on how to most effectively avoid working together with me?!? Do whatever you want. But my advice is to *develop* the packaging unified at Alioth, and only (optionally!) fork the resulting source packages when released for Debian. My advice to less adventurous folks than David here is to help package more activities before diving into the Glucose parts. And with that I mean first class activities, i.e. activities written in arch-independent Python without exotic non-Sugar dependencies. Calculate is a marvellous example of a first class activity: It stays backwards compatible with 0.82, by carefully wrapping newer funky features and preserve fallbacks. When you (upstream) wants to keep it simple for users by shooting yourself in the foot with that too simple versioning system, there is really only one sane solution: Keep the activities backwards compatible! Hope you will engage more than just fork off, - 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
Re: [Sugar-devel] [Debian-olpc-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!
On Sun, Sep 20, 2009 at 12:43:25AM +0200, Tomeu Vizoso wrote: On Sun, Sep 20, 2009 at 00:32, Jonas Smedegaard d...@jones.dk wrote: As subject says, Glucose (and some of Fructose) 0.84.0 and 0.85.7 is now packaged for Debian! More info at http://wiki.debian.org/Sugar and http://wiki.sugarlabs.org/go/Community/Distributions/Debian . Wow, tomorrow will give it a go. Looking forward to that! Please do post to the Alioth list about your experiences or any questions you might have about Debian(-like) packaging. I need to prepare for some talks I will be giving in Taiwan in a week, so have patience with my responses: Do ping me if you still haven't heard from me in 2 weeks from now. I might respond faster, but really I shouldn't - I should be preparing my talks instead! :-/ Please do not cross-post: Respond only to the Alioth list when the topic is Debian packaging specific. - 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] Smile activity version 1
Hi Tony, Sorry for taking so long to respond to this one. I had a similar problem in Colors! and solved it by adding a timer event while playback was running: 1350def start_update_timer(self): 1351if self.update_timer: 1352gobject.source_remove(self.update_timer) 1353 1354# The timer priority is chosen to be above PRIORITY_REDRAW (which is PRIORITY_HIGH_IDLE_20, but not defined in PyGTK). 1355self.update_timer = gobject.timeout_add(1, self.update, priority=gobject.PRIORITY_HIGH_IDLE+30) The update event would trigger a paint event and return True when playback was active, else return False if playback was done. When playback was started again it would start the timer running again. This starting and stopping prevents pegging the CPU all the time. Anyway, this might help solve your problem by forcing the event loop to run, although it does sound like the root problem could be a different issue. Best, Wade On Thu, Sep 3, 2009 at 12:02 PM, Tony Anderson t...@olenepal.org wrote: Hi, I am always tempted to blame my code, but the same problem appeared in the Ambulant demo wrapper (player_pygtk.py) on Ubuntu. It appears only in the python wrapper (not the C++ version). The Ambulant team has opened a ticket. The problem appears to be an interaction between the gtk.main() event loop and the Ambulant redraw logic. Player_pygtk.py doesn't call gtk.main but instead uses a loop: while gtk.events_pending(): gtk.main_iteration() I think it is safe to rule out Sugar as a culprit, but not my building of the Ambulant package! Yours, Tony Tomeu Vizoso wrote: On Wed, Sep 2, 2009 at 18:31, Tony Andersont...@olenepal.org wrote: I posted version 1 of the Smile activity to activities.sugarlabs.org. It matches the code posted on gitorious. The Smile activity implements the open source Ambulant SMIL3 player. It plays a variety of media types. More importantly it can play a complex multimedia presentation including text, images, audio, and video using a standard SMIL script. My goal is to use the Smile activity to play children's stories so that they can see the text highlighted karaoke-style while listening to the story's audio track and looking at background images. Similar to the Quiz and ShowNTell activities, the Smile activity plays a bundle with an extension '.smxo' and mime_type 'application/x-smile' which contains the controlling SMIL script and the associated media files. Version 1 has two serious problems. Video playback and multimedia playback does not redraw correctly (playback is advanced by moving the mouse!). In addition, it is possible to replay only be re-selecting the presentation. The pause and stop buttons do not work correctly. I hope that both of these problems will be resolved in version 2 by the end of September. Hi Tony, do you know if the cause for these problems in the Ambulant SMIL3 player or in the activity code? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Smile activity version 1
By way of introduction for the newer contributors-- Wade started and was the first co-ordinator of the Activities Team. He took a break last spring for the birth of a child:) I wonder if he has looked at activities.sugarlabs.org lately. It has had over 680,000 activity downloads, most of them since June. Congratulation on the baby and starting something pretty cool. david On Sat, Sep 19, 2009 at 8:42 PM, Wade Brainerd wad...@gmail.com wrote: Hi Tony, Sorry for taking so long to respond to this one. I had a similar problem in Colors! and solved it by adding a timer event while playback was running: 1350 def start_update_timer(self): 1351 if self.update_timer: 1352 gobject.source_remove(self.update_timer) 1353 1354 # The timer priority is chosen to be above PRIORITY_REDRAW (which is PRIORITY_HIGH_IDLE_20, but not defined in PyGTK). 1355 self.update_timer = gobject.timeout_add(1, self.update, priority=gobject.PRIORITY_HIGH_IDLE+30) The update event would trigger a paint event and return True when playback was active, else return False if playback was done. When playback was started again it would start the timer running again. This starting and stopping prevents pegging the CPU all the time. Anyway, this might help solve your problem by forcing the event loop to run, although it does sound like the root problem could be a different issue. Best, Wade On Thu, Sep 3, 2009 at 12:02 PM, Tony Anderson t...@olenepal.org wrote: Hi, I am always tempted to blame my code, but the same problem appeared in the Ambulant demo wrapper (player_pygtk.py) on Ubuntu. It appears only in the python wrapper (not the C++ version). The Ambulant team has opened a ticket. The problem appears to be an interaction between the gtk.main() event loop and the Ambulant redraw logic. Player_pygtk.py doesn't call gtk.main but instead uses a loop: while gtk.events_pending(): gtk.main_iteration() I think it is safe to rule out Sugar as a culprit, but not my building of the Ambulant package! Yours, Tony Tomeu Vizoso wrote: On Wed, Sep 2, 2009 at 18:31, Tony Andersont...@olenepal.org wrote: I posted version 1 of the Smile activity to activities.sugarlabs.org. It matches the code posted on gitorious. The Smile activity implements the open source Ambulant SMIL3 player. It plays a variety of media types. More importantly it can play a complex multimedia presentation including text, images, audio, and video using a standard SMIL script. My goal is to use the Smile activity to play children's stories so that they can see the text highlighted karaoke-style while listening to the story's audio track and looking at background images. Similar to the Quiz and ShowNTell activities, the Smile activity plays a bundle with an extension '.smxo' and mime_type 'application/x-smile' which contains the controlling SMIL script and the associated media files. Version 1 has two serious problems. Video playback and multimedia playback does not redraw correctly (playback is advanced by moving the mouse!). In addition, it is possible to replay only be re-selecting the presentation. The pause and stop buttons do not work correctly. I hope that both of these problems will be resolved in version 2 by the end of September. Hi Tony, do you know if the cause for these problems in the Ambulant SMIL3 player or in the activity code? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] thinking about knavbar
Pavel ji, shall I merge your code in myself or would u like me to walk u through how to do it w/ git? I should be at @sugar for most of today btw Pavel ji means Pavel sir in Nepali ;) On Sun, 2009-09-20 at 04:37 +0100, Pavel Mocan wrote: New update for Karma CSS and HTML. Live at www.mpavel.ro/projects/Karma/ I had to change quite a lot of the HTML as it was not using the HTML5 syntax. This way the source code brings more semantic to the whole document and the structure of it becomes more obvious. The CSS file has been reduced from 400 lines of code to 200. The 'chakra.css' file was sectioned into areas where css properties apply to. However, I still think there is room for improvement. More general properties should be added and things such as sub navigation menus (months, weeks) and articles (lessons) should have the appearance improved. Some notes about coding: - With HTML5 there is no need to put in the type property for the script tag. It recognises it automatically. Same for CSS. This means you can write scriptjs code here/script and stylecss style here/style in html5 documents and they will be valid. - In HTML, you are only allowed to use the same id value for only one element on that page (it's meant to be unique). So, for example, you can't have two div that have id=myElement. - With CSS it is good to take an object oriented approach. For example, if there are elements who need to be floating to left or right, two classes can be created: floatLeft and floatRight. Elements that need to float to the left will obviously have class=floatLeft. If that element needs a big margin, it can be done in another class .bigMargin with the element having class=floatLeft bigMargin. Hope eveything is fine, email me with anything (feedback, suggestions, critic, etc) Regards, Pavel M. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] thinking about knavbar
On Sun, 2009-09-20 at 04:37 +0100, Pavel Mocan wrote: New update for Karma CSS and HTML. Live at www.mpavel.ro/projects/Karma/ I had to change quite a lot of the HTML as it was not using the HTML5 syntax. This way the source code brings more semantic to the whole document and the structure of it becomes more obvious. The CSS file has been reduced from 400 lines of code to 200. The 'chakra.css' file was sectioned into areas where css properties apply to. However, I still think there is room for improvement. More general properties should be added and things such as sub navigation menus (months, weeks) and articles (lessons) should have the appearance improved. I agree! Some notes about coding: - With HTML5 there is no need to put in the type property for the script tag. It recognises it automatically. Same for CSS. This means you can write scriptjs code here/script and stylecss style here/style in html5 documents and they will be valid. good to know, that save me a lot of typing - In HTML, you are only allowed to use the same id value for only one element on that page (it's meant to be unique). So, for example, you can't have two div that have id=myElement. R we using the same element ID more than once anywhere? - With CSS it is good to take an object oriented approach. For example, if there are elements who need to be floating to left or right, two classes can be created: floatLeft and floatRight. Elements that need to float to the left will obviously have class=floatLeft. If that element needs a big margin, it can be done in another class .bigMargin with the element having class=floatLeft bigMargin. +1 tks for your help! -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] thinking about knavbar
http://edward.oconnor.cx/2009/09/using-the-html5-sectioning-elements This blog post has a great example of how to use html5 tags in a semantically meaningful way. On Sun, 2009-09-20 at 04:37 +0100, Pavel Mocan wrote: New update for Karma CSS and HTML. Live at www.mpavel.ro/projects/Karma/ I had to change quite a lot of the HTML as it was not using the HTML5 syntax. This way the source code brings more semantic to the whole document and the structure of it becomes more obvious. The CSS file has been reduced from 400 lines of code to 200. The 'chakra.css' file was sectioned into areas where css properties apply to. However, I still think there is room for improvement. More general properties should be added and things such as sub navigation menus (months, weeks) and articles (lessons) should have the appearance improved. Some notes about coding: - With HTML5 there is no need to put in the type property for the script tag. It recognises it automatically. Same for CSS. This means you can write scriptjs code here/script and stylecss style here/style in html5 documents and they will be valid. - In HTML, you are only allowed to use the same id value for only one element on that page (it's meant to be unique). So, for example, you can't have two div that have id=myElement. - With CSS it is good to take an object oriented approach. For example, if there are elements who need to be floating to left or right, two classes can be created: floatLeft and floatRight. Elements that need to float to the left will obviously have class=floatLeft. If that element needs a big margin, it can be done in another class .bigMargin with the element having class=floatLeft bigMargin. Hope eveything is fine, email me with anything (feedback, suggestions, critic, etc) Regards, Pavel M. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
