Re: [Sugar-devel] [record] Fixes to the UI
Why don't you just fix hideAllWindows()? Because it has a specific purpose. The ui works by first moving ALL widgets off-screen (or dumping it in the corner as in this case) by calling hideAllWindows() and then resizing and moving the widgets to be displayed appropriately. If instead of moving them off-screen, I actually hide the widgets, I won't be able to resize or move them. That said, I could probably give better names to the methods in question. great variable name that you inherited, there...might as well rename it to something more standard like buttonBox while you're at it. Agreed :-) On Mon, Jun 7, 2010 at 7:32 AM, Martin Dengler mar...@martindengler.com wrote: On Mon, Jun 07, 2010 at 12:04:18AM +0530, anishmangal2...@gmail.com wrote: [...] @@ -884,6 +939,10 @@ class UI: kids[i].setButtClickedId(BUTT_CLICKED_ID) +def actuallyHideAllWindows( self ): +for i in range (0, len(self.windowStack)): +self.windowStack[i].hide_all() + def hideAllWindows( self ): for i in range (0, len(self.windowStack)): self.moveWinOffscreen( self.windowStack[i] ) Why don't you just fix hideAllWindows()? @@ -1913,22 +2036,22 @@ class ScrubberWindow(gtk.Window): self.add( self.hbox ) self.button = gtk.Button() -buttBox = gtk.EventBox() -buttBox.add(self.button) -buttBox.modify_bg( gtk.STATE_NORMAL, Constants.colorBlack.gColor ) +self.buttBox = gtk.EventBox() +self.buttBox.add(self.button) +self.buttBox.modify_bg( gtk.STATE_NORMAL, Constants.colorBlack.gColor ) great variable name that you inherited, there...might as well rename it to something more standard like buttonBox while you're at it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [record] Fixes to the UI
On Mon, Jun 07, 2010 at 12:04:18AM +0530, anishmangal2...@gmail.com wrote: This patch fixes the Record ui which is broken since versions 0.86 and later. Tested-by: James Cameron qu...@laptop.org Feedback given to Anish via #sugar IRC, some work remains. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [record] Fixes to the UI
On Mon, Jun 07, 2010 at 01:12:38PM +0530, Anish Mangal wrote: Why don't you just fix hideAllWindows()? Because it has a specific purpose. Specific purpose (distinct from what your other method has) or just different implementation? [implementation] If instead of moving them off-screen, I actually hide the widgets, I won't be able to resize or move them. Ok - I haven't read the code enough to see why that's a problem. That said, I could probably give better names to the methods in question. That'd be nice...that way it doesn't just look like you have two methods that do the same thing, one correctly and one badly. Martin pgpxvwpB0Eq9B.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [record] Fixes to the UI
Specific purpose (distinct from what your other method has) or just different implementation? Yes, distinct from what the other method does. Feedback given to Anish via #sugar IRC, some work remains. Thanks! I'll work on it later today. Cheers, Anish On Mon, Jun 7, 2010 at 2:51 PM, Martin Dengler mar...@martindengler.com wrote: On Mon, Jun 07, 2010 at 01:12:38PM +0530, Anish Mangal wrote: Why don't you just fix hideAllWindows()? Because it has a specific purpose. Specific purpose (distinct from what your other method has) or just different implementation? [implementation] If instead of moving them off-screen, I actually hide the widgets, I won't be able to resize or move them. Ok - I haven't read the code enough to see why that's a problem. That said, I could probably give better names to the methods in question. That'd be nice...that way it doesn't just look like you have two methods that do the same thing, one correctly and one badly. Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Devel Team vacancies + On sugar-0.90.
On June 7, Simon Schampijer wrote: On 06/06/2010 10:30 PM, Tomeu Vizoso wrote: SeanDaly if tomeu were here, he would say: we need someone experienced, who knows the open source way, and does not need lots of briefing to get up to speed (he will correct me if I err) You can count on me for that :) So the idea of team coordinator is that of someone who takes care for: * keeping the list of team members updated in the wiki, * making sure the mission statement is in sync with the team's activities, * announce and moderate regular meetings and publishing its minutes. So I don't think you need any special skills, just be willing to donate a few hours per month. If we had a community team, we would have a structure for the people who want to work together on such issues ;) cjb (I think the most important job the release manager does is decide whether a late change constitutes acceptable risk, and I think doing that requires deep understanding of programming and the complexity of a given bug/solution.) There seems to be a misunderstanding, maybe because OLPC had a position with the same name (and maybe our use of it is not totally appropriate). In Sugar's case, who decides what goes in and what not is the schedule, the maintainer and the release team, with input from several others. The schedule says what kind of changes can go in at every moment in the release cycle, the maintainer is expected to have enough criteria to classify every change accordingly and the release team votes on exceptions to the schedule. All about releases: http://wiki.sugarlabs.org/go/Development_Team/Release New features process and what is the release manager: http://wiki.sugarlabs.org/go/Features/Policy In this way, the release manager doesn't have as much responsibility as was implied in the meeting but he's mainly responsible for making sure that the process _for proposing new features_ is followed. It's largely an administrative role, but much more exigent than coordinating a team. The reason for having a weaker release manager and relying more on the criteria of maintainers is because by SLs being an upstream these decisions won't affect as directly to our users as downstreams are anyway expected to do integration, testing and maybe some amount of patching after each release is made. For a downstream such as OLPC or Fedora, someone needs to control very strictly what gets in at the end of the cycle because there's more pressure to get stuff in and because once you have sent the image to the factory or have started to seed a torrent it's much harder to go back and fix some bug. In the Sugar case, if a maintainer made a goof and introduced a major bug just before release, it will take some time before the code is packaged, then distributed to testers, then submitted to a stable release that users will use with some expectation of not finding major regressions. It would be great if people could search the wiki before entering in discussing a process or a role, because as you can see from the link above, that took someone quite a bit of time to write and would be sad to waste time discussing something else. Also, the docs in the wiki indeed could be clearer and any help will be welcome. To make it clearer: * the release manager is not needed to make module releases, * the release manager doesn't decide by herself if a change goes in or not, * the release manager makes sure the feature process is followed. Maybe a more appropriate name for what we call the release manager would be new feature process manager but as it's a bit long and we don't have a release manager, we ended up using that name instead. Regards, Tomeu Thanks for taking the time to lay this out as detailed. Indeed, thanks! It is true indeed that the main role of the release manager, as Sugar Labs interpreted that role... The stumbling block for me for several other people here is this line from the current Feature Policy: The main goal of the feature policy is to make systematic and predictable the process by which community ideas on how Sugar should evolve get transformed into actionable proposals. and its emphasis on process, predictability, and rigid schedules. Why is predictability the thing we want to optimize for here? You see, I want us to create a Sugar release that is *as much improved as we can get in the time allowed*, even if it winds up being improved in ways that we didn't foresee -- that we merely recognized and adopted immediately as they were suggested. To do this, we should concentrate on building the leanest, meanest, fastest coding and integration machine that we can so that we create as much opportunity as we can stand to make changes that will really improve the user experience and technology that we're providing. Velocity, momentum, and ferment should be our bywords. The reason why I want these things is that there are still
[Sugar-devel] Paint maintainer MIA?
Anybody knows if the Paint maintainer is M.I.A.? I have sent patches the last month and James Cameron has reviewed them, but there aren't any response from the maintainer. In the git repository, the last commits to change code were by Aleksey and Simon in 2009-06. I volunteer to maintainer if nobody want to take this role. -- Gonzalo Odiard SugarLabs Argentina ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint maintainer MIA?
On 06/07/2010 04:14 PM, Gonzalo Odiard wrote: Anybody knows if the Paint maintainer is M.I.A.? I have sent patches the last month and James Cameron has reviewed them, but there aren't any response from the maintainer. In the git repository, the last commits to change code were by Aleksey and Simon in 2009-06. I volunteer to maintainer if nobody want to take this role. Hi Gonzalo, these are great news! I have not seen any contributions to Paint from anybody besides Aleksey and myself. I would be just wonderful to have someone giving Paint the attention it deserves. If you are willing to, I don't see anything stopping you from doing it ;) Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint maintainer MIA?
On Mon, Jun 7, 2010 at 16:22, Simon Schampijer si...@schampijer.de wrote: On 06/07/2010 04:14 PM, Gonzalo Odiard wrote: Anybody knows if the Paint maintainer is M.I.A.? I have sent patches the last month and James Cameron has reviewed them, but there aren't any response from the maintainer. In the git repository, the last commits to change code were by Aleksey and Simon in 2009-06. I volunteer to maintainer if nobody want to take this role. Hi Gonzalo, these are great news! I have not seen any contributions to Paint from anybody besides Aleksey and myself. I would be just wonderful to have someone giving Paint the attention it deserves. If you are willing to, I don't see anything stopping you from doing it ;) Isn't Manu in LinuxTag these days? He used to keep track of who maintains Paint back when he was at OLPC. That said, Gonzalo seems to have been doing a great work and I don't think we should stop him for taking this responsibility if he wants to. Regards, Tomeu Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Devel Team vacancies + On sugar-0.90.
On Mon, Jun 7, 2010 at 16:07, Michael Stone mich...@laptop.org wrote: On June 7, Simon Schampijer wrote: On 06/06/2010 10:30 PM, Tomeu Vizoso wrote: SeanDaly if tomeu were here, he would say: we need someone experienced, who knows the open source way, and does not need lots of briefing to get up to speed (he will correct me if I err) You can count on me for that :) So the idea of team coordinator is that of someone who takes care for: * keeping the list of team members updated in the wiki, * making sure the mission statement is in sync with the team's activities, * announce and moderate regular meetings and publishing its minutes. So I don't think you need any special skills, just be willing to donate a few hours per month. If we had a community team, we would have a structure for the people who want to work together on such issues ;) cjb (I think the most important job the release manager does is decide whether a late change constitutes acceptable risk, and I think doing that requires deep understanding of programming and the complexity of a given bug/solution.) There seems to be a misunderstanding, maybe because OLPC had a position with the same name (and maybe our use of it is not totally appropriate). In Sugar's case, who decides what goes in and what not is the schedule, the maintainer and the release team, with input from several others. The schedule says what kind of changes can go in at every moment in the release cycle, the maintainer is expected to have enough criteria to classify every change accordingly and the release team votes on exceptions to the schedule. All about releases: http://wiki.sugarlabs.org/go/Development_Team/Release New features process and what is the release manager: http://wiki.sugarlabs.org/go/Features/Policy In this way, the release manager doesn't have as much responsibility as was implied in the meeting but he's mainly responsible for making sure that the process _for proposing new features_ is followed. It's largely an administrative role, but much more exigent than coordinating a team. The reason for having a weaker release manager and relying more on the criteria of maintainers is because by SLs being an upstream these decisions won't affect as directly to our users as downstreams are anyway expected to do integration, testing and maybe some amount of patching after each release is made. For a downstream such as OLPC or Fedora, someone needs to control very strictly what gets in at the end of the cycle because there's more pressure to get stuff in and because once you have sent the image to the factory or have started to seed a torrent it's much harder to go back and fix some bug. In the Sugar case, if a maintainer made a goof and introduced a major bug just before release, it will take some time before the code is packaged, then distributed to testers, then submitted to a stable release that users will use with some expectation of not finding major regressions. It would be great if people could search the wiki before entering in discussing a process or a role, because as you can see from the link above, that took someone quite a bit of time to write and would be sad to waste time discussing something else. Also, the docs in the wiki indeed could be clearer and any help will be welcome. To make it clearer: * the release manager is not needed to make module releases, * the release manager doesn't decide by herself if a change goes in or not, * the release manager makes sure the feature process is followed. Maybe a more appropriate name for what we call the release manager would be new feature process manager but as it's a bit long and we don't have a release manager, we ended up using that name instead. Regards, Tomeu Thanks for taking the time to lay this out as detailed. Indeed, thanks! It is true indeed that the main role of the release manager, as Sugar Labs interpreted that role... The stumbling block for me for several other people here is this line from the current Feature Policy: The main goal of the feature policy is to make systematic and predictable the process by which community ideas on how Sugar should evolve get transformed into actionable proposals. and its emphasis on process, predictability, and rigid schedules. Why is predictability the thing we want to optimize for here? Guess the wiki could have been more explicit about what is intended to make predictable. The idea is that before we had the feature process, whatever new stuff went into a release depended solely on what the maintainer thought it was a good idea. We actually didn't change that, but with the feature process the community can give a clear message to maintainers about what they would like to see in the next release. So before, people would propose their features in the mailing list, in irc, or whatever, and they would need to convince each maintainer individually
Re: [Sugar-devel] Paint maintainer MIA?
On Mon, Jun 7, 2010 at 6:24 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Jun 7, 2010 at 16:22, Simon Schampijer si...@schampijer.de wrote: On 06/07/2010 04:14 PM, Gonzalo Odiard wrote: Anybody knows if the Paint maintainer is M.I.A.? I have sent patches the last month and James Cameron has reviewed them, but there aren't any response from the maintainer. In the git repository, the last commits to change code were by Aleksey and Simon in 2009-06. I volunteer to maintainer if nobody want to take this role. Hi Gonzalo, these are great news! I have not seen any contributions to Paint from anybody besides Aleksey and myself. I would be just wonderful to have someone giving Paint the attention it deserves. If you are willing to, I don't see anything stopping you from doing it ;) Isn't Manu in LinuxTag these days? He used to keep track of who maintains Paint back when he was at OLPC. I think Manu (CCed) would fully support this handover. He has his hand pretty full getting the Seeta developers up to speed developing and maintaining Sugar on Ubuntu. Seeta, has a good deal of experience in abiword. So, I believe they will be volunteering to take maintainership of write. Once Lucian gets up to speed converting browse to webkit, Activity Central will volunteer to assist development and maintainership of browse. david That said, Gonzalo seems to have been doing a great work and I don't think we should stop him for taking this responsibility if he wants to. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH][record] Fixes to the UI
On 6 June 2010 15:54, Anish Mangal anishmangal2...@gmail.com wrote: At least for myself, I'd like to see more detail here -- how was it broken? Sure. The record UI consists of many windows/widgets. In a particular mode or view, it displays and resizes the widgets appropriate for that view the tries to hide the other windows by moving them off-screen. There was probably a reason why it moved them off screen instead of hiding them. Do you have any idea what it is? The patch (which I must confess is not an ideal fix), works by resizing (to size 1px by 1px) and hiding the widgets not required in a particular view/mode. To accomplish that, I created the 'resizewindows' method. Also, in the 'updatevideocomponents' method I hide the widgets not required in a particular view. This is a great start but we should look towards that 'ideal fix' route. If we are no longer moving windows offscreen, I would expect your patch to remove a load of code that does that, but I don't see it. Also, if you are hiding widgets, I don't see any reason to resize them to 1x1. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint maintainer MIA?
On Mon, Jun 7, 2010 at 8:34 PM, David Farning dfarn...@gmail.com wrote: On Mon, Jun 7, 2010 at 6:24 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Jun 7, 2010 at 16:22, Simon Schampijer si...@schampijer.de wrote: On 06/07/2010 04:14 PM, Gonzalo Odiard wrote: Anybody knows if the Paint maintainer is M.I.A.? I have sent patches the last month and James Cameron has reviewed them, but there aren't any response from the maintainer. In the git repository, the last commits to change code were by Aleksey and Simon in 2009-06. I volunteer to maintainer if nobody want to take this role. Hi Gonzalo, these are great news! I have not seen any contributions to Paint from anybody besides Aleksey and myself. I would be just wonderful to have someone giving Paint the attention it deserves. If you are willing to, I don't see anything stopping you from doing it ;) Isn't Manu in LinuxTag these days? He used to keep track of who maintains Paint back when he was at OLPC. I think Manu (CCed) would fully support this handover. He has his hand pretty full getting the Seeta developers up to speed developing and maintaining Sugar on Ubuntu. Thanks David. Appreciate your kind regards and pointers. I would be happy to have Gonzalo work with us towards maintaining Paint and fixing bugs over this summer. In reference to Bernie's recommendation, we did hire an intern, Kamakshi Aggarwal, who'll be working with pointers from Nathalia Sautchuk Patrício, one of the original developers of Oficina. We have a huge pile of tickets now. She will be starting her training on Paint during this week. Gonzalo, will highly appreciate if you and Kamakshi work together on this project. Will be forwarding her the documentation on Paint sometime soon, and will copy you on the memos. Thank you for your initiative. Gonzalo, we do have our priorities well defined for Paint. I'll send you the list of top 5 test track items, which need immediate attention from our side. Seeta, has a good deal of experience in abiword. So, I believe they will be volunteering to take maintainership of write. David, thank you. Yes, we do have two developers, Diksha and Lakky, who look after Newspaper activity under the guidance of Vijit, and they will be getting trained on PyAbiword. Depending upon their bandwidth to take up and support multiple projects, they'll get started on Write. Again, I would like to start with high floor and low ceiling. Will let expectations build up depending upon the performance. Once Lucian gets up to speed converting browse to webkit, Activity Central will volunteer to assist development and maintainership of browse. David, do we have an answer on how this shift will affect activities like SocialCalc? Will we be receiving documentation on how we could shift our base to webkit with optimal hacking time spend from our side? Regards, Manu david That said, Gonzalo seems to have been doing a great work and I don't think we should stop him for taking this responsibility if he wants to. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint maintainer MIA?
On Mon, Jun 7, 2010 at 3:17 PM, Manusheel Gupta m...@laptop.org wrote: On Mon, Jun 7, 2010 at 8:34 PM, David Farning dfarn...@gmail.com wrote: On Mon, Jun 7, 2010 at 6:24 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Jun 7, 2010 at 16:22, Simon Schampijer si...@schampijer.de wrote: On 06/07/2010 04:14 PM, Gonzalo Odiard wrote: Anybody knows if the Paint maintainer is M.I.A.? I have sent patches the last month and James Cameron has reviewed them, but there aren't any response from the maintainer. In the git repository, the last commits to change code were by Aleksey and Simon in 2009-06. I volunteer to maintainer if nobody want to take this role. Hi Gonzalo, these are great news! I have not seen any contributions to Paint from anybody besides Aleksey and myself. I would be just wonderful to have someone giving Paint the attention it deserves. If you are willing to, I don't see anything stopping you from doing it ;) Isn't Manu in LinuxTag these days? He used to keep track of who maintains Paint back when he was at OLPC. I think Manu (CCed) would fully support this handover. He has his hand pretty full getting the Seeta developers up to speed developing and maintaining Sugar on Ubuntu. Thanks David. Appreciate your kind regards and pointers. I would be happy to have Gonzalo work with us towards maintaining Paint and fixing bugs over this summer. In reference to Bernie's recommendation, we did hire an intern, Kamakshi Aggarwal, who'll be working with pointers from Nathalia Sautchuk Patrício, one of the original developers of Oficina. We have a huge pile of tickets now. She will be starting her training on Paint during this week. Gonzalo, will highly appreciate if you and Kamakshi work together on this project. Will be forwarding her the documentation on Paint sometime soon, and will copy you on the memos. Thank you for your initiative. Gonzalo, we do have our priorities well defined for Paint. I'll send you the list of top 5 test track items, which need immediate attention from our side. Seeta, has a good deal of experience in abiword. So, I believe they will be volunteering to take maintainership of write. David, thank you. Yes, we do have two developers, Diksha and Lakky, who look after Newspaper activity under the guidance of Vijit, and they will be getting trained on PyAbiword. Depending upon their bandwidth to take up and support multiple projects, they'll get started on Write. Again, I would like to start with high floor and low ceiling. Will let expectations build up depending upon the performance. Once Lucian gets up to speed converting browse to webkit, Activity Central will volunteer to assist development and maintainership of browse. David, do we have an answer on how this shift will affect activities like SocialCalc? Will we be receiving documentation on how we could shift our base to webkit with optimal hacking time spend from our side? Regards, Manu Not yet, this is Lucian Branescu Mihaila's (lucian), mentored by Luis Gustavo Lira, GSOC project. david That said, Gonzalo seems to have been doing a great work and I don't think we should stop him for taking this responsibility if he wants to. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] VNC for Projector View
Hello All. Please one question.: One software for view the image of the XO at Projector 3M --hp ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] VNC for Projector View
On Mon, Jun 7, 2010 at 17:37, Hernan Pachas hernan.pac...@gmail.com wrote: One software for view the image of the XO at Projector 3M Your question is somewhat vague. Are you trying to display the XO's screen on another computer? If so, you want http://wiki.laptop.org/go/Remote_display -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Attention Activity Developers: SoaS Activity Inclusion Criteria
Hi all, at today's SoaS meeting [1], we agreed on applying the SoaS Activity Inclusion Criteria [2] as outlined in the wiki to the activity selection for the upcoming release of SoaS v.4. We'd like to encourage you to work towards meeting these goals and to submit your proposals for activities and further features following the feature process [3] according to the release schedule [4]. The final deadline to have features *approved* (please submit your proposals well in advance) is July 27. We're especially lead to this step to ensure to continued stability of future Sugar on a Stick releases and look forward to working with you! Please email the SoaS list or our release team with any concerns. --Sebastian Dziallas [1] http://me.etin.gs/sugar-meeting/sugar-meeting.minutes.20100607_1510.html [2] http://wiki.sugarlabs.org/go/SoaS_Activity_Criteria [3] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_release_process#Feature_process [4] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick#Release_schedule ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint maintainer MIA?
I think Manu (CCed) would fully support this handover. He has his hand pretty full getting the Seeta developers up to speed developing and maintaining Sugar on Ubuntu. Thanks David. Appreciate your kind regards and pointers. I would be happy to have Gonzalo work with us towards maintaining Paint and fixing bugs over this summer. In reference to Bernie's recommendation, we did hire an intern, Kamakshi Aggarwal, who'll be working with pointers from Nathalia Sautchuk Patrício, one of the original developers of Oficina. We have a huge pile of tickets now. She will be starting her training on Paint during this week. Gonzalo, will highly appreciate if you and Kamakshi work together on this project. Will be forwarding her the documentation on Paint sometime soon, and will copy you on the memos. Thank you for your initiative. Gonzalo, we do have our priorities well defined for Paint. I'll send you the list of top 5 test track items, which need immediate attention from our side. Ok Manu. My first idea it's close almost all tickets opened. Then I have a prototype to change the Text Tool to enable styles. How we will work toghether? You will include my patches in the repository or will be co mainteiners? I want to work in the list and not duplicate efforts. Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Attention Activity Developers: SoaS Activity Inclusion Criteria
On Mon, Jun 07, 2010 at 11:54:45PM +0200, Sebastian Dziallas wrote: at today's SoaS meeting [1], we agreed on applying the SoaS Activity Inclusion Criteria [2] as outlined in the wiki [...] You've decided to apply as policy a draft document which describes itself as not reflecting policy. Suggestion: remove the draft status, approve the document, and remove section 2.11 (template text) to the discussion page. to the activity selection for the upcoming release of SoaS v.4. We'd like to encourage you to work towards meeting these goals and to submit your proposals for activities and further features following the feature process [3] according to the release schedule [4]. I've looked through the process. It is discouraging and complex. I suggest that people other than activity developers be encouraged to run through the process on behalf of discouraged or absent activity developers. We're especially lead to this step to ensure to continued stability of future Sugar on a Stick releases [...] It isn't clear to me how this process will increase or ensure stability of the Sugar on a Stick releases. Which particular meaning of stability are you using; a lack of change, or a lack of reported defects? -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
OS 240py XO-1 Though I cannot see any way to create tabs in browse, sometimes clicking links in frames creates tabs which behave erratically eg zero width tab http://wiki.sugarlabs.org/images/e/ec/Screenshot_of_Browse_0s240py_.png Tony ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here Comments? Additions? Substitutions? Deletions? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Attention Activity Developers: SoaS Activity Inclusion Criteria
On Mon, Jun 7, 2010 at 2:54 PM, Sebastian Dziallas sebast...@when.com wrote: Hi all, at today's SoaS meeting [1], we agreed on applying the SoaS Activity Inclusion Criteria [2] as outlined in the wiki to the activity selection for the upcoming release of SoaS v.4. We'd like to encourage you to work towards meeting these goals and to submit your proposals for activities and further features following the feature process [3] according to the release schedule [4]. The final deadline to have features *approved* (please submit your proposals well in advance) is July 27. We're especially lead to this step to ensure to continued stability of future Sugar on a Stick releases and look forward to working with you! Please email the SoaS list or our release team with any concerns. --Sebastian Dziallas [1] http://me.etin.gs/sugar-meeting/sugar-meeting.minutes.20100607_1510.html [2] http://wiki.sugarlabs.org/go/SoaS_Activity_Criteria [3] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_release_process#Feature_process [4] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick#Release_schedule ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep The criteria page lists attributes that are either yes or no (binary). I had suggested a weighted scoring approach way back for G1G1 activities. Here's that thread. http://www.mail-archive.com/olpc-o...@lists.laptop.org/msg00641.html The idea is to score each attribute on a more granular scale than 0/1 and then weight each attribute based on importance for a particular implementation. cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor, Information Systems Director, Campus Business Solutions San Francisco State University http://verma.sfsu.edu/ http://opensource.sfsu.edu/ http://cbs.sfsu.edu/ http://is.sfsu.edu/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
