Re: [Sugar-devel] [SoaS] [IAEP] Attention Activity Developers: SoaS Activity Inclusion Criteria
--- Mar 8/6/10, Sameer Verma sve...@sfsu.edu ha scritto: Da: Sameer Verma sve...@sfsu.edu Oggetto: Re: [SoaS] [IAEP] Attention Activity Developers: SoaS Activity Inclusion Criteria A: Sebastian Dziallas sebast...@when.com Cc: Devel de...@lists.laptop.org, iaep i...@lists.sugarlabs.org, Sugar devel sugar-devel@lists.sugarlabs.org, Sugar on a Stick List s...@lists.sugarlabs.org Data: Martedì 8 giugno 2010, 07:29 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 +1 ciao carlo -- 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/ ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] music USB keyboard for Tamtam
I'm looking for a musical keyboard device (black and white keys like on a piano) that plugs into USB on a XO and allows one to play music via TamTam. Does such a device exist? If so, pointers? 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
Re: [Sugar-devel] music USB keyboard for Tamtam
On Tue, Jun 8, 2010 at 3:34 AM, Sameer Verma sve...@sfsu.edu wrote: I'm looking for a musical keyboard device (black and white keys like on a piano) that plugs into USB on a XO and allows one to play music via TamTam. Does such a device exist? If so, pointers? Well, I don't know if any such keyboard is supported by TamTam, but there are a lot of relatively cheap USB piano keyboards out there, like: http://www.thinkgeek.com/electronics/musical-instruments/af36/ --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] music USB keyboard for Tamtam
On Tue, Jun 8, 2010 at 3:34 AM, Sameer Verma sve...@sfsu.edu wrote: I'm looking for a musical keyboard device (black and white keys like on a piano) that plugs into USB on a XO and allows one to play music via TamTam. Does such a device exist? If so, pointers? I think gitori...@git.sugarlabs.org/sun-moon-music/mainline.git is intended to work with a musical keyboard. -walter 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 -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Sun-Moon Music MC-1
Activity Homepage: http://activities.sugarlabs.org/addon/4308 Sugar Platform: 0.84 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26930/sunmoonmusicmc-1.xo Release notes: Sun-Moon Music MC - Two realtime sonic environments for children (Brother Sun Music and Sister Moon Music). Requires 1 or more MIDI controllers with 8-9 knobs/sliders. Collaborative performance encouraged. (Note: Sugar 0.82 is not supported.) Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Sun-Moon Music-1
Activity Homepage: http://activities.sugarlabs.org/addon/4307 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26929/sunmoonmusic-1.xo Release notes: Sun-Moon Music - Two realtime sonic environments for children (Brother Sun Music and Sister Moon Music). Requires MIDI controller with 8-9 knobs/sliders. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 12:54 AM, Michael Stone mich...@laptop.org wrote: 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. :) Bernie gather more rumors this weekend in an impromptu meeting in IRC. Not sure where the log is, but the list is similar. 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 -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] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 12:54 AM, Michael Stone mich...@laptop.org wrote: 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 I'll also write up a Feature page for Multiple Home Views (e.g., my math class home view, my home home view, etc.) -walter Comments? Additions? Substitutions? Deletions? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- 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] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 5:54 AM, Michael Stone mich...@laptop.org wrote: 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? I would also like to add an item regarding making sure the 0.90 release works properly with all the upcoming changes (deprecations being the big one) for the gnome-3 release. In 0.88 for Sugar on a Stick we saw the start of these issues with the issues with Read, its possible this could only get worse over the next 6 months. It would also be worth looking at things like dconf for the things that are currently stored in GConf. It would be worthwhile updating the default jhbuild config to reflect the gnome minimum versions covering the usual gnome suspects and gstreamer / telepathy etc. as that should make it easier for developers to pick up issues over the coming months sooner rather than later. Cheers, Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar-Devel] Sugar Web Engine
Hi Luncian, On Sun, Jun 6, 2010 at 2:33 PM, Lucian Branescu lucian.brane...@gmail.com wrote: I've received even less feedback from upstreams about their respective engines. There are still 2 issues: 1) Mozilla have given up on having xulrunner work as a distro-provided VM and now they just bundle it.. They plan some major changes to embedding and they have no plan forward that would allow hulahop to exist. It's no longer just about maintaining hulahop, but the entire stack up from gecko. Sorry, the statement above seems inconclusive. Have you actually received confirmation from Mozilla that xulrunner is no longer going to be supported or is it just assumed due to their silence? Is that published somewhere if its official? There are a number of both open and closed projects that depend on xulrunner so I would be somewhat surprised if they dropped support for it. Songbird. TomTom Home, Komodo IDE and OpenKomodo are all based on xulrunner. Its also used as part of a number of Mozilla projects. The other component that hulahop uses that caused us issues during the SoaS v3 release time frame was the support of pyxpcom was dropped from the main codebase. My understanding for the reason for this was actually a request from ActiveState (developers of Komodo/openKomodo) who are the maintainers of that code so they could develop and release it on a separate timeline to the main xulrunner release. Its still supported even if not in certain distros. You might find contacting them directly to find out their plans might yield quicker and better results. 2) pywebkitgtk does not have a clear future. The changelog shows activity, but stable maintenance is not assured 3) webkitgtk+ and PyGI might be the best solution, but it doesn't yet work everywhere. From a technical p.o.v. the bits missing from PyGI should not (significantly) hinder Browse, since web engines tend to have comparatively little interaction with their GUIs. Right now, the only option that would actually works everywhere we care about is pywebkitgtk. While it may not be future-proof, PyGI would be targeting the same webkit API, so switching should be very easy. Since it's already late into the project, unless someone has a better idea, I'll stick to fully porting Browse to pywebkitgtk, using any Surf code that is relevant. This should result in a fully-working Browse with SSB features in time for GSoC that also has a clear enough future. Sorry for the delayed response. It might be better in the short term to stick with hulahop / xulrunner until PyGI gets to a state that its usable. Let me know if I can help. Peter On 31 May 2010 13:41, Lucian Branescu lucian.brane...@gmail.com wrote: Since I got little feedback about the time, there will be a meeting in #sugar-meeting at 3PM GMT On 31 May 2010 10:09, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, May 30, 2010 at 01:58, Lucian Branescu lucian.brane...@gmail.com wrote: In case you don't already know, I'm doing a GSoC project on improving the browser engine situation in Sugar http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser My exams haven't finished yet (last one on Wednesday), so before I start working, I want the opinion of people that use web engines in sugar applications or that are otherwise interested in web engines for sugar on how to proceed. I'd like answers to questions like Should I drop hulahop and focus on webkit? or Is an API like hulahop's nice?, etc. What we need to find out in order to find the right answers to that is what's the future of xulrunner. If Mozilla plans to drop some part of their platform essential for hulahop, or if distros are not willing to keep packaging it in a way that hulahop can work, then we should just forget about it and move to webkit. I'd like to set up a meeting on #sugar-meeting on Monday between 9 AM and 9 PM GMT, depending on the availability of attendees. Great idea! Regards, Tomeu Individual chats/ml are also welcome, but an IRC meeting would be ideal. ___ 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] [Sugar-Devel] Sugar Web Engine
On 8 June 2010 15:01, Peter Robinson pbrobin...@gmail.com wrote: Hi Luncian, On Sun, Jun 6, 2010 at 2:33 PM, Lucian Branescu lucian.brane...@gmail.com wrote: I've received even less feedback from upstreams about their respective engines. There are still 2 issues: 1) Mozilla have given up on having xulrunner work as a distro-provided VM and now they just bundle it.. They plan some major changes to embedding and they have no plan forward that would allow hulahop to exist. It's no longer just about maintaining hulahop, but the entire stack up from gecko. Sorry, the statement above seems inconclusive. Have you actually received confirmation from Mozilla that xulrunner is no longer going to be supported or is it just assumed due to their silence? Is that published somewhere if its official? I went by what was on the wiki. Considering feedback I did eventually get from Mozilla, the wiki was exaggerating. There are a number of both open and closed projects that depend on xulrunner so I would be somewhat surprised if they dropped support for it. Songbird. TomTom Home, Komodo IDE and OpenKomodo are all based on xulrunner. Its also used as part of a number of Mozilla projects. The other component that hulahop uses that caused us issues during the SoaS v3 release time frame was the support of pyxpcom was dropped from the main codebase. My understanding for the reason for this was actually a request from ActiveState (developers of Komodo/openKomodo) who are the maintainers of that code so they could develop and release it on a separate timeline to the main xulrunner release. Its still supported even if not in certain distros. You might find contacting them directly to find out their plans might yield quicker and better results. 2) pywebkitgtk does not have a clear future. The changelog shows activity, but stable maintenance is not assured 3) webkitgtk+ and PyGI might be the best solution, but it doesn't yet work everywhere. From a technical p.o.v. the bits missing from PyGI should not (significantly) hinder Browse, since web engines tend to have comparatively little interaction with their GUIs. Right now, the only option that would actually works everywhere we care about is pywebkitgtk. While it may not be future-proof, PyGI would be targeting the same webkit API, so switching should be very easy. Since it's already late into the project, unless someone has a better idea, I'll stick to fully porting Browse to pywebkitgtk, using any Surf code that is relevant. This should result in a fully-working Browse with SSB features in time for GSoC that also has a clear enough future. Sorry for the delayed response. It might be better in the short term to stick with hulahop / xulrunner until PyGI gets to a state that its usable. Let me know if I can help. This week I'll try to finish the prototype abstraction layer. If that works decently, I'll go with that and fully implement hulahop and pywebkitgtk backends. If not, I'll stick to hulahop, fix whatever bugs there are and implement SSB features. Peter On 31 May 2010 13:41, Lucian Branescu lucian.brane...@gmail.com wrote: Since I got little feedback about the time, there will be a meeting in #sugar-meeting at 3PM GMT On 31 May 2010 10:09, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, May 30, 2010 at 01:58, Lucian Branescu lucian.brane...@gmail.com wrote: In case you don't already know, I'm doing a GSoC project on improving the browser engine situation in Sugar http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser My exams haven't finished yet (last one on Wednesday), so before I start working, I want the opinion of people that use web engines in sugar applications or that are otherwise interested in web engines for sugar on how to proceed. I'd like answers to questions like Should I drop hulahop and focus on webkit? or Is an API like hulahop's nice?, etc. What we need to find out in order to find the right answers to that is what's the future of xulrunner. If Mozilla plans to drop some part of their platform essential for hulahop, or if distros are not willing to keep packaging it in a way that hulahop can work, then we should just forget about it and move to webkit. I'd like to set up a meeting on #sugar-meeting on Monday between 9 AM and 9 PM GMT, depending on the availability of attendees. Great idea! Regards, Tomeu Individual chats/ml are also welcome, but an IRC meeting would be ideal. ___ 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] Paint maintainer MIA?
El Mon, 07-06-2010 a las 20:40 -0300, Gonzalo Odiard escribió: 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. Let me know your git.sugarlabs.org username so I can add you as a committer. Manu, let me know the usernames of anyone else who is going to work onthe code. It would be good if anyone involved could keep running patches through this list to do some peer-reviewing before committing them to the repository. Who's gonna be the new project owner? -- // 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] [record] Fixes to the UI
El Mon, 07-06-2010 a las 03:02 +0100, Martin Dengler escribió: 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. Or maybe button_box. CamelCase does not seem to be very fashionable among Python developers. -- // 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] ANNOUNCE: Sugar 0.88 for the XO-1
El Tue, 08-06-2010 a las 13:21 +1000, fors...@ozonline.com.au escribió: 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 Simon, Lucian, any idea what may be causing this? More importantly, is Browse really unmaintained at this time? -- // 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] Paint maintainer MIA?
My git user is godiard. Gonzalo On Tue, Jun 8, 2010 at 11:58 AM, Bernie Innocenti ber...@codewiz.orgwrote: El Mon, 07-06-2010 a las 20:40 -0300, Gonzalo Odiard escribió: 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. Let me know your git.sugarlabs.org username so I can add you as a committer. Manu, let me know the usernames of anyone else who is going to work onthe code. It would be good if anyone involved could keep running patches through this list to do some peer-reviewing before committing them to the repository. Who's gonna be the new project owner? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- Gonzalo Odiard Responsable de Desarrollo Sistemas Australes ___ 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
I'm not sure what this is and I don't really have the time to look into it atm. Browse is in a difficult situation because hulahop, pywebkitgtk and webkitgtk+PyGI all have hazy futures. Over the summer I'll try and get Browse in a better situation (the plan so far is a thin abstraction layer). So many more bugs will crop up and some others will vanish. Not sure about maintenance after GSoC though, I have both uni and work, so little free time. On 8 June 2010 16:07, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 08-06-2010 a las 13:21 +1000, fors...@ozonline.com.au escribió: 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 Simon, Lucian, any idea what may be causing this? More importantly, is Browse really unmaintained at this time? -- // 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] ANNOUNCE: Sugar 0.88 for the XO-1
El Tue, 08-06-2010 a las 16:13 +0100, Lucian Branescu escribió: I'm not sure what this is and I don't really have the time to look into it atm. Browse is in a difficult situation because hulahop, pywebkitgtk and webkitgtk+PyGI all have hazy futures. Over the summer I'll try and get Browse in a better situation (the plan so far is a thin abstraction layer). Hmm... I need a quick fix for this bug (and perhaps others) by August. So many more bugs will crop up and some others will vanish. Not sure about maintenance after GSoC though, I have both uni and work, so little free time. Perhaps we could get someone like Kenny or Anish to take over Browse. -- // 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] music USB keyboard for Tamtam
The least expensive and appopriate to the XO, as well as widely available and current model (basic two-octave USB MIDI keyboard) is the Korg nanoKey. It's rugged, only $50 retail, and a lot of bang for the buck. I recommend its sister unit, the Korg nanoKontrol, as the most appropriate MIDI controller (in this case banks of sliders and knobs) for my activities. Art Hunkins Associate Professor of Music emeritus University of North Carolina at Greensboro - Original Message - From: C. Scott Ananian csc...@laptop.org To: Sameer Verma sve...@sfsu.edu Cc: Sugar-dev Devel sugar-devel@lists.sugarlabs.org Sent: Tuesday, June 08, 2010 4:56 AM Subject: Re: [Sugar-devel] music USB keyboard for Tamtam On Tue, Jun 8, 2010 at 3:34 AM, Sameer Verma sve...@sfsu.edu wrote: I'm looking for a musical keyboard device (black and white keys like on a piano) that plugs into USB on a XO and allows one to play music via TamTam. Does such a device exist? If so, pointers? Well, I don't know if any such keyboard is supported by TamTam, but there are a lot of relatively cheap USB piano keyboards out there, like: http://www.thinkgeek.com/electronics/musical-instruments/af36/ --scott -- ( http://cscott.net/ ) ___ 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] music USB keyboard for Tamtam
See my previous mail. Sun-Moon Music uses a MIDI controller with 8-9 *knobs/sliders*. (This is also known as a control surface.) What Sameer needs is something like the Korg nanoKey (your basic 25-key piano-style USB keyboard). Many 25-key and greater MIDI keyboard controllers come also with sets of knobs and/or sliders, and thus would do double-duty. Art Hunkins - Original Message - From: Walter Bender walter.ben...@gmail.com To: Sameer Verma sve...@sfsu.edu Cc: Sugar-dev Devel sugar-devel@lists.sugarlabs.org Sent: Tuesday, June 08, 2010 7:11 AM Subject: Re: [Sugar-devel] music USB keyboard for Tamtam On Tue, Jun 8, 2010 at 3:34 AM, Sameer Verma sve...@sfsu.edu wrote: I'm looking for a musical keyboard device (black and white keys like on a piano) that plugs into USB on a XO and allows one to play music via TamTam. Does such a device exist? If so, pointers? I think gitori...@git.sugarlabs.org/sun-moon-music/mainline.git is intended to work with a musical keyboard. -walter 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 -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [record] Fixes to the UI
On Tue, Jun 08, 2010 at 11:04:44AM -0400, Bernie Innocenti wrote: El Mon, 07-06-2010 a las 03:02 +0100, Martin Dengler escribió: On Mon, Jun 07, 2010 at 12:04:18AM +0530, anishmangal2...@gmail.com wrote: [...] great variable name that you inherited, there...might as well rename it to something more standard like buttonBox while you're at it. Or maybe button_box. CamelCase does not seem to be very fashionable among Python developers. Totally right - I stand corrected. @@ -884,6 +939,10 @@ class UI: kids[i].setButtClickedId(BUTT_CLICKED_ID) Loads of unfortunate areas there, too. Martin pgp6c4ZeMVAom.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
I've taken care of all the 'butt's, but virtually all the whole Record UI code is written in camelCase. If its worthwhile, I'll fix it, but it should probably be done in a separate patch. Cheers, Anish On Tue, Jun 8, 2010 at 11:01 PM, Martin Dengler mar...@martindengler.com wrote: On Tue, Jun 08, 2010 at 11:04:44AM -0400, Bernie Innocenti wrote: El Mon, 07-06-2010 a las 03:02 +0100, Martin Dengler escribió: On Mon, Jun 07, 2010 at 12:04:18AM +0530, anishmangal2...@gmail.com wrote: [...] great variable name that you inherited, there...might as well rename it to something more standard like buttonBox while you're at it. Or maybe button_box. CamelCase does not seem to be very fashionable among Python developers. Totally right - I stand corrected. @@ -884,6 +939,10 @@ class UI: kids[i].setButtClickedId(BUTT_CLICKED_ID) Loads of unfortunate areas there, too. Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Paint maintainer MIA?
El Tue, 08-06-2010 a las 12:08 -0300, Gonzalo Odiard escribió: My git user is godiard. Sascha added you to the mainline repo. Cheers! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Problems adapting activity
Hello, Recently, I've been trying to adapt a software a friend developed into an activity, but since I'm a bit newbie when it comes to sugar development, I'm having some trouble doing it. I've followed the tutorials in http://wiki.laptop.org/go/Creating_an_activity http://wiki.laptop.org/go/Activity_tutorial http://wiki.laptop.org/go/Activity_bundles with no success. I run the setup.py file on my computer, create the .xo package, export it to the XO system, install it and restart. The activity icon shows up, but when I click it, it stays on the loading screen ( white with the activity icon blinking ) but doesn't load the program. I'm trying to run it on an emulated image. Also, keep in mind that the software itself wasn't developed with the XO in mind, so, maybe I need to change something on the source code to make it work. Thank you for your help ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Problems adapting activity
Have you read this tutorial? http://en.flossmanuals.net/ActivitiesGuideSugar On Tue, Jun 8, 2010 at 3:29 PM, Alberto Arruda de Oliveira alberto.a.o...@gmail.com wrote: Hello, Recently, I've been trying to adapt a software a friend developed into an activity, but since I'm a bit newbie when it comes to sugar development, I'm having some trouble doing it. I've followed the tutorials in http://wiki.laptop.org/go/Creating_an_activity http://wiki.laptop.org/go/Activity_tutorial http://wiki.laptop.org/go/Activity_bundles with no success. I run the setup.py file on my computer, create the .xo package, export it to the XO system, install it and restart. The activity icon shows up, but when I click it, it stays on the loading screen ( white with the activity icon blinking ) but doesn't load the program. I'm trying to run it on an emulated image. Also, keep in mind that the software itself wasn't developed with the XO in mind, so, maybe I need to change something on the source code to make it work. Thank you for your help ___ 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.: 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
Re: [Sugar-devel] Problems adapting activity
Your activity didn't started. You must read the log file in /home/olpc/.sugar/default/logs/ Gonzalo On Tue, Jun 8, 2010 at 3:29 PM, Alberto Arruda de Oliveira alberto.a.o...@gmail.com wrote: Hello, Recently, I've been trying to adapt a software a friend developed into an activity, but since I'm a bit newbie when it comes to sugar development, I'm having some trouble doing it. I've followed the tutorials in http://wiki.laptop.org/go/Creating_an_activity http://wiki.laptop.org/go/Activity_tutorial http://wiki.laptop.org/go/Activity_bundles with no success. I run the setup.py file on my computer, create the .xo package, export it to the XO system, install it and restart. The activity icon shows up, but when I click it, it stays on the loading screen ( white with the activity icon blinking ) but doesn't load the program. I'm trying to run it on an emulated image. Also, keep in mind that the software itself wasn't developed with the XO in mind, so, maybe I need to change something on the source code to make it work. Thank you for your help ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard Responsable de Desarrollo Sistemas Australes ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Problems adapting activity
Hi, On 8 Jun 2010, at 19:29, Alberto Arruda de Oliveira alberto.a.o...@gmail.com wrote: Hello, Recently, I've been trying to adapt a software a friend developed into an activity, but since I'm a bit newbie when it comes to sugar development, I'm having some trouble doing it. I've followed the tutorials in http://wiki.laptop.org/go/Creating_an_activity http://wiki.laptop.org/go/Activity_tutorial http://wiki.laptop.org/go/Activity_bundles with no success. I run the setup.py file on my computer, create the .xo package, export it to the XO system, install it and restart. The activity icon shows up, but when I click it, it stays on the loading screen ( white with the activity icon blinking ) but doesn't load the program. I'm trying to run it on an emulated image. Also, keep in mind that the software itself wasn't developed with the XO in mind, so, maybe I need to change something on the source code to make it work. If you run the Log activity, have a look at the error logs for your activity, usually it's the quickest first place to look with something like this happens. Look for the 'trace back' if there is one and post here if it's not obvious to you what failed. Regards, --Gary Thank you for your help ___ 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] [PATCH] Fixes to the record UI
From: anishmangal2002 anishmangal2...@gmail.com How the existing UI works: The record UI consists of many windows/widgets. In a particular mode or view, it displays and resizes the widgets appropriate for that view and tries to hide the other windows by moving them off-screen. Now, on sugar-0.88 (and probably on versions 0.86), while trying to move the widgets off-screen, they actually get dumped at the bottom-right corner. Hence, if a user runs the existing Record activity on 0.88, he will observe that the bottom right quadrant of the screen is 'corrupted'. Fix description: The patch works by hiding or resizing (to size 1px by 1px) the widgets not required in a particular view/mode. The updateVideoComponents method has been modified to hide the widgets not required in a particular view. Widgets that can't be hidden are resized to 1 x 1 pixel. Additionally, this patch also fixes the naming of some variables (s/butt/button/g). Tested successfully on sugar-emulator-0.88, soas-mirabelle and xo1-f11-0.88. Signed-off-by: anishmangal2002 anishmangal2...@gmail.com --- button.py| 10 ++-- model.py |2 + p5_button.py | 30 +- ui.py| 199 +++--- 4 files changed, 129 insertions(+), 112 deletions(-) diff --git a/button.py b/button.py index 14b9700..2b0e85c 100644 --- a/button.py +++ b/button.py @@ -62,12 +62,12 @@ class RecdButton(TrayButton, gobject.GObject): return img -def setButtClickedId( self, id ): -self.BUTT_CLICKED_ID = id +def setButtonClickedId( self, id ): +self.BUTTON_CLICKED_ID = id -def getButtClickedId( self ): -return self.BUTT_CLICKED_ID +def getButtonClickedId( self ): +return self.BUTTON_CLICKED_ID def setup_rollover_options( self, info ): @@ -105,4 +105,4 @@ class RecdButton(TrayButton, gobject.GObject): def _itemCopyToClipboardCb(self, widget): -self.ui.copyToClipboard( self.recd ) \ No newline at end of file +self.ui.copyToClipboard( self.recd ) diff --git a/model.py b/model.py index b7f592b..e24752e 100644 --- a/model.py +++ b/model.py @@ -323,6 +323,8 @@ class Model: def startTakingPhoto( self ): self.setUpdating( True ) self.ca.glive.takePhoto() +self.ca.ui.FULLSCREEN = False +self.ca.ui.updateVideoComponents() def savePhoto( self, pixbuf ): diff --git a/p5_button.py b/p5_button.py index cf76a34..a8e10c5 100644 --- a/p5_button.py +++ b/p5_button.py @@ -25,7 +25,7 @@ class P5Button(P5): def __init__(self): P5.__init__(self) self.noloop() -self._butts = [] +self._buttons = [] self._buttonPressed = False @@ -34,10 +34,10 @@ class P5Button(P5): #iterate through the buttons to see if you've pressed any down bp = False -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -contains = self._butts[i].contains(event.x, event.y) -self._butts[i]._pressed = contains +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +contains = self._buttons[i].contains(event.x, event.y) +self._buttons[i]._pressed = contains if (contains): bp = True @@ -51,16 +51,16 @@ class P5Button(P5): pressed = [] #iterate through the buttons to see if you've released on any -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -if (self._butts[i]._pressed): -if (self._butts[i].contains(event.x, event.y)): -pressed.append( self._butts[i] ) - -if (self._butts[i]._toggle): -self._butts[i]._pressed = not self._butts[i]._pressed +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +if (self._buttons[i]._pressed): +if (self._buttons[i].contains(event.x, event.y)): +pressed.append( self._buttons[i] ) + +if (self._buttons[i]._toggle): +self._buttons[i]._pressed = not self._buttons[i]._pressed else: -self._butts[i]._pressed = False +self._buttons[i]._pressed = False for i in range( 0, len(pressed) ): pressed[i].doPressed() @@ -170,4 +170,4 @@ class Button: def isImg( self ): -return self._img != None \ No newline at end of file +return self._img != None diff --git a/ui.py b/ui.py index d89b819..e723f66 100644 --- a/ui.py +++ b/ui.py @@ -92,7 +92,7 @@ class UI: self.maxw = 49 self.maxh = 49 self.controlBarHt = 60 -self.recordButtWd = 55 +self.recordButtonWd = 55 self.pipw =
Re: [Sugar-devel] [PATCH][record] Fixes to the UI
There was probably a reason why it moved them off screen instead of hiding them. Do you have any idea what it is? This comment in ui.py explains why #we move offscreen to resize or else we get flashes on screen, and setting hide() doesn't allow resize moves * * * The original code works like this 1. Decide what widgets to display determining their size and position. 2. Move everything off screen. 3. Resize and move the widgets decided in (1) accordingly. The problem is in step (2). Moving a widget offscreen actually dumps it in the bottom right corner. How the patch fixes it. 1. Decide what widgets to display and what size they should be. 2. Move everything off screen. 3. Resize and move the widgets decided in (1) accordingly. 4. Resize to 1x1 _OR_ hide all remaining widgets. 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. Incorporated in the updated patch. Also, if you are hiding widgets, I don't see any reason to resize them to 1x1. For some widgets, when I attempt to hide them, the UI doesn't work, so I have to resize them to 1x1. (I only resize those widgets which I can't hide, so there is no redundancy) Cheers, Anish On Mon, Jun 7, 2010 at 9:38 PM, Daniel Drake d...@laptop.org wrote: 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] [PATCH] Fixes to the record UI
On Wed, Jun 09, 2010 at 12:22:19AM +0530, anishmangal2...@gmail.com wrote: From: anishmangal2002 anishmangal2...@gmail.com How the existing UI works: The record UI consists of many windows/widgets. In a particular mode or view, it displays and resizes the widgets appropriate for that view and tries to hide the other windows by moving them off-screen. Now, on sugar-0.88 (and probably on versions 0.86), while trying to move the widgets off-screen, they actually get dumped at the bottom-right corner. Hence, if a user runs the existing Record activity on 0.88, he will observe that the bottom right quadrant of the screen is 'corrupted'. Fix description: The patch works by hiding or resizing (to size 1px by 1px) the widgets not required in a particular view/mode. The updateVideoComponents method has been modified to hide the widgets not required in a particular view. Widgets that can't be hidden are resized to 1 x 1 pixel. Additionally, this patch also fixes the naming of some variables (s/butt/button/g). Tested successfully on sugar-emulator-0.88, soas-mirabelle and xo1-f11-0.88. Patch looks good for me, if it doesn't beat Daniel's release plans, I guess we can commit (you are in commiters list) it and bump new Record release (you can also release new version). I've added you to Record developers on ASLO (you should see Record in your Dev Hub on http://activities.sugarlabs.org/developers). Also all 7x versions rely on recent gst so these versions on ASLO are experimental. Signed-off-by: anishmangal2002 anishmangal2...@gmail.com --- button.py| 10 ++-- model.py |2 + p5_button.py | 30 +- ui.py| 199 +++--- 4 files changed, 129 insertions(+), 112 deletions(-) diff --git a/button.py b/button.py index 14b9700..2b0e85c 100644 --- a/button.py +++ b/button.py @@ -62,12 +62,12 @@ class RecdButton(TrayButton, gobject.GObject): return img -def setButtClickedId( self, id ): -self.BUTT_CLICKED_ID = id +def setButtonClickedId( self, id ): +self.BUTTON_CLICKED_ID = id -def getButtClickedId( self ): -return self.BUTT_CLICKED_ID +def getButtonClickedId( self ): +return self.BUTTON_CLICKED_ID def setup_rollover_options( self, info ): @@ -105,4 +105,4 @@ class RecdButton(TrayButton, gobject.GObject): def _itemCopyToClipboardCb(self, widget): -self.ui.copyToClipboard( self.recd ) \ No newline at end of file +self.ui.copyToClipboard( self.recd ) diff --git a/model.py b/model.py index b7f592b..e24752e 100644 --- a/model.py +++ b/model.py @@ -323,6 +323,8 @@ class Model: def startTakingPhoto( self ): self.setUpdating( True ) self.ca.glive.takePhoto() +self.ca.ui.FULLSCREEN = False +self.ca.ui.updateVideoComponents() def savePhoto( self, pixbuf ): diff --git a/p5_button.py b/p5_button.py index cf76a34..a8e10c5 100644 --- a/p5_button.py +++ b/p5_button.py @@ -25,7 +25,7 @@ class P5Button(P5): def __init__(self): P5.__init__(self) self.noloop() -self._butts = [] +self._buttons = [] self._buttonPressed = False @@ -34,10 +34,10 @@ class P5Button(P5): #iterate through the buttons to see if you've pressed any down bp = False -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -contains = self._butts[i].contains(event.x, event.y) -self._butts[i]._pressed = contains +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +contains = self._buttons[i].contains(event.x, event.y) +self._buttons[i]._pressed = contains if (contains): bp = True @@ -51,16 +51,16 @@ class P5Button(P5): pressed = [] #iterate through the buttons to see if you've released on any -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -if (self._butts[i]._pressed): -if (self._butts[i].contains(event.x, event.y)): -pressed.append( self._butts[i] ) - -if (self._butts[i]._toggle): -self._butts[i]._pressed = not self._butts[i]._pressed +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +if (self._buttons[i]._pressed): +if (self._buttons[i].contains(event.x, event.y)): +pressed.append( self._buttons[i] ) + +if (self._buttons[i]._toggle): +self._buttons[i]._pressed = not self._buttons[i]._pressed else: -
[Sugar-devel] [PATCH] Record - Fix for ticket #2011
From: anishmangal2002 anishmangal2...@gmail.com Ctrl+w now exits the activity Signed-off-by: anishmangal2002 anishmangal2...@gmail.com --- ui.py |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/ui.py b/ui.py index e723f66..c9ab664 100644 --- a/ui.py +++ b/ui.py @@ -741,6 +741,9 @@ class UI: elif (keyname == 'i' and event.state == gtk.gdk.CONTROL_MASK): if (not self.LIVEMODE): self.infoButtonClicked() +elif (keyname == 'w' and event.state == gtk.gdk.CONTROL_MASK): +self.ca.close() + return False -- 1.7.0.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Fixes to the record UI
On Tue, Jun 08, 2010 at 07:45:06PM +, Aleksey Lim wrote: On Wed, Jun 09, 2010 at 12:22:19AM +0530, anishmangal2...@gmail.com wrote: From: anishmangal2002 anishmangal2...@gmail.com How the existing UI works: The record UI consists of many windows/widgets. In a particular mode or view, it displays and resizes the widgets appropriate for that view and tries to hide the other windows by moving them off-screen. Now, on sugar-0.88 (and probably on versions 0.86), while trying to move the widgets off-screen, they actually get dumped at the bottom-right corner. Hence, if a user runs the existing Record activity on 0.88, he will observe that the bottom right quadrant of the screen is 'corrupted'. Fix description: The patch works by hiding or resizing (to size 1px by 1px) the widgets not required in a particular view/mode. The updateVideoComponents method has been modified to hide the widgets not required in a particular view. Widgets that can't be hidden are resized to 1 x 1 pixel. Additionally, this patch also fixes the naming of some variables (s/butt/button/g). Tested successfully on sugar-emulator-0.88, soas-mirabelle and xo1-f11-0.88. Patch looks good for me, if it doesn't beat Daniel's release plans, I guess we can commit (you are in commiters list) it and bump new Record release (you can also release new version). I've tried it on XO-1.5 with 201 build, the UI itself works fine on XO-1.5, there is issue with recording video (empty playback video) but my build is not recent, will try with last one. I've added you to Record developers on ASLO (you should see Record in your Dev Hub on http://activities.sugarlabs.org/developers). Also all 7x versions rely on recent gst so these versions on ASLO are experimental. Signed-off-by: anishmangal2002 anishmangal2...@gmail.com --- button.py| 10 ++-- model.py |2 + p5_button.py | 30 +- ui.py| 199 +++--- 4 files changed, 129 insertions(+), 112 deletions(-) diff --git a/button.py b/button.py index 14b9700..2b0e85c 100644 --- a/button.py +++ b/button.py @@ -62,12 +62,12 @@ class RecdButton(TrayButton, gobject.GObject): return img -def setButtClickedId( self, id ): -self.BUTT_CLICKED_ID = id +def setButtonClickedId( self, id ): +self.BUTTON_CLICKED_ID = id -def getButtClickedId( self ): -return self.BUTT_CLICKED_ID +def getButtonClickedId( self ): +return self.BUTTON_CLICKED_ID def setup_rollover_options( self, info ): @@ -105,4 +105,4 @@ class RecdButton(TrayButton, gobject.GObject): def _itemCopyToClipboardCb(self, widget): -self.ui.copyToClipboard( self.recd ) \ No newline at end of file +self.ui.copyToClipboard( self.recd ) diff --git a/model.py b/model.py index b7f592b..e24752e 100644 --- a/model.py +++ b/model.py @@ -323,6 +323,8 @@ class Model: def startTakingPhoto( self ): self.setUpdating( True ) self.ca.glive.takePhoto() +self.ca.ui.FULLSCREEN = False +self.ca.ui.updateVideoComponents() def savePhoto( self, pixbuf ): diff --git a/p5_button.py b/p5_button.py index cf76a34..a8e10c5 100644 --- a/p5_button.py +++ b/p5_button.py @@ -25,7 +25,7 @@ class P5Button(P5): def __init__(self): P5.__init__(self) self.noloop() -self._butts = [] +self._buttons = [] self._buttonPressed = False @@ -34,10 +34,10 @@ class P5Button(P5): #iterate through the buttons to see if you've pressed any down bp = False -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -contains = self._butts[i].contains(event.x, event.y) -self._butts[i]._pressed = contains +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +contains = self._buttons[i].contains(event.x, event.y) +self._buttons[i]._pressed = contains if (contains): bp = True @@ -51,16 +51,16 @@ class P5Button(P5): pressed = [] #iterate through the buttons to see if you've released on any -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -if (self._butts[i]._pressed): -if (self._butts[i].contains(event.x, event.y)): -pressed.append( self._butts[i] ) - -if (self._butts[i]._toggle): -self._butts[i]._pressed = not self._butts[i]._pressed +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +
Re: [Sugar-devel] [PATCH] Fixes to the record UI
El Tue, 08-06-2010 a las 19:45 +, Aleksey Lim escribió: Patch looks good for me, if it doesn't beat Daniel's release plans, I guess we can commit (you are in commiters list) it and bump new Record release (you can also release new version). Fantastic. Anish, can you commit and provide a bundle in time for our alpha2 release (Jun 10)? This was one of the worse regressions. I've added you to Record developers on ASLO (you should see Record in your Dev Hub on http://activities.sugarlabs.org/developers). Also all 7x versions rely on recent gst so these versions on ASLO are experimental. How recent does gst need to be? I can upgrade the gstreamer stack on F11-XO1, with is probably the oldest thing we support. Signed-off-by: anishmangal2002 anishmangal2...@gmail.com --- button.py| 10 ++-- model.py |2 + p5_button.py | 30 +- ui.py| 199 +++--- 4 files changed, 129 insertions(+), 112 deletions(-) diff --git a/button.py b/button.py index 14b9700..2b0e85c 100644 --- a/button.py +++ b/button.py @@ -62,12 +62,12 @@ class RecdButton(TrayButton, gobject.GObject): return img -def setButtClickedId( self, id ): -self.BUTT_CLICKED_ID = id +def setButtonClickedId( self, id ): +self.BUTTON_CLICKED_ID = id -def getButtClickedId( self ): -return self.BUTT_CLICKED_ID +def getButtonClickedId( self ): +return self.BUTTON_CLICKED_ID def setup_rollover_options( self, info ): @@ -105,4 +105,4 @@ class RecdButton(TrayButton, gobject.GObject): def _itemCopyToClipboardCb(self, widget): -self.ui.copyToClipboard( self.recd ) \ No newline at end of file +self.ui.copyToClipboard( self.recd ) diff --git a/model.py b/model.py index b7f592b..e24752e 100644 --- a/model.py +++ b/model.py @@ -323,6 +323,8 @@ class Model: def startTakingPhoto( self ): self.setUpdating( True ) self.ca.glive.takePhoto() +self.ca.ui.FULLSCREEN = False +self.ca.ui.updateVideoComponents() def savePhoto( self, pixbuf ): diff --git a/p5_button.py b/p5_button.py index cf76a34..a8e10c5 100644 --- a/p5_button.py +++ b/p5_button.py @@ -25,7 +25,7 @@ class P5Button(P5): def __init__(self): P5.__init__(self) self.noloop() -self._butts = [] +self._buttons = [] self._buttonPressed = False @@ -34,10 +34,10 @@ class P5Button(P5): #iterate through the buttons to see if you've pressed any down bp = False -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -contains = self._butts[i].contains(event.x, event.y) -self._butts[i]._pressed = contains +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +contains = self._buttons[i].contains(event.x, event.y) +self._buttons[i]._pressed = contains if (contains): bp = True @@ -51,16 +51,16 @@ class P5Button(P5): pressed = [] #iterate through the buttons to see if you've released on any -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -if (self._butts[i]._pressed): -if (self._butts[i].contains(event.x, event.y)): -pressed.append( self._butts[i] ) - -if (self._butts[i]._toggle): -self._butts[i]._pressed = not self._butts[i]._pressed +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +if (self._buttons[i]._pressed): +if (self._buttons[i].contains(event.x, event.y)): +pressed.append( self._buttons[i] ) + +if (self._buttons[i]._toggle): +self._buttons[i]._pressed = not self._buttons[i]._pressed else: -self._butts[i]._pressed = False +self._buttons[i]._pressed = False for i in range( 0, len(pressed) ): pressed[i].doPressed() @@ -170,4 +170,4 @@ class Button: def isImg( self ): -return self._img != None \ No newline at end of file +return self._img != None diff --git a/ui.py b/ui.py index d89b819..e723f66 100644 --- a/ui.py +++ b/ui.py @@ -92,7 +92,7 @@ class UI: self.maxw = 49 self.maxh = 49 self.controlBarHt = 60 -self.recordButtWd = 55 +self.recordButtonWd = 55 self.pipw = self.__class__.dim_PIPW self.piph =
Re: [Sugar-devel] [record] Fixes to the UI
El Tue, 08-06-2010 a las 23:34 +0530, Anish Mangal escribió: I've taken care of all the 'butt's, but virtually all the whole Record UI code is written in camelCase. If its worthwhile, I'll fix it, but it should probably be done in a separate patch. Indeed. A Golden Rule of open source programmer is to never lump two of these together in the same patch: * bugfixes * new features * reindents * coding style fixes The best developers manage to do one atomic change per patch, but I've never reached this level of precision in my work, except for small bugfixes. -- // 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] [PATCH] Fixes to the record UI
On Tue, Jun 08, 2010 at 05:56:22PM -0400, Bernie Innocenti wrote: El Tue, 08-06-2010 a las 19:45 +, Aleksey Lim escribió: Patch looks good for me, if it doesn't beat Daniel's release plans, I guess we can commit (you are in commiters list) it and bump new Record release (you can also release new version). Fantastic. Anish, can you commit and provide a bundle in time for our alpha2 release (Jun 10)? This was one of the worse regressions. I've added you to Record developers on ASLO (you should see Record in your Dev Hub on http://activities.sugarlabs.org/developers). Also all 7x versions rely on recent gst so these versions on ASLO are experimental. How recent does gst need to be? I can upgrade the gstreamer stack on F11-XO1, with is probably the oldest thing we support. Better to ask Daniel but I guess he was targeting to gst that was shipped with f11. Signed-off-by: anishmangal2002 anishmangal2...@gmail.com --- button.py| 10 ++-- model.py |2 + p5_button.py | 30 +- ui.py| 199 +++--- 4 files changed, 129 insertions(+), 112 deletions(-) diff --git a/button.py b/button.py index 14b9700..2b0e85c 100644 --- a/button.py +++ b/button.py @@ -62,12 +62,12 @@ class RecdButton(TrayButton, gobject.GObject): return img -def setButtClickedId( self, id ): -self.BUTT_CLICKED_ID = id +def setButtonClickedId( self, id ): +self.BUTTON_CLICKED_ID = id -def getButtClickedId( self ): -return self.BUTT_CLICKED_ID +def getButtonClickedId( self ): +return self.BUTTON_CLICKED_ID def setup_rollover_options( self, info ): @@ -105,4 +105,4 @@ class RecdButton(TrayButton, gobject.GObject): def _itemCopyToClipboardCb(self, widget): -self.ui.copyToClipboard( self.recd ) \ No newline at end of file +self.ui.copyToClipboard( self.recd ) diff --git a/model.py b/model.py index b7f592b..e24752e 100644 --- a/model.py +++ b/model.py @@ -323,6 +323,8 @@ class Model: def startTakingPhoto( self ): self.setUpdating( True ) self.ca.glive.takePhoto() +self.ca.ui.FULLSCREEN = False +self.ca.ui.updateVideoComponents() def savePhoto( self, pixbuf ): diff --git a/p5_button.py b/p5_button.py index cf76a34..a8e10c5 100644 --- a/p5_button.py +++ b/p5_button.py @@ -25,7 +25,7 @@ class P5Button(P5): def __init__(self): P5.__init__(self) self.noloop() -self._butts = [] +self._buttons = [] self._buttonPressed = False @@ -34,10 +34,10 @@ class P5Button(P5): #iterate through the buttons to see if you've pressed any down bp = False -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -contains = self._butts[i].contains(event.x, event.y) -self._butts[i]._pressed = contains +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +contains = self._buttons[i].contains(event.x, event.y) +self._buttons[i]._pressed = contains if (contains): bp = True @@ -51,16 +51,16 @@ class P5Button(P5): pressed = [] #iterate through the buttons to see if you've released on any -for i in range ( 0, len(self._butts) ): -if (self._butts[i]._enabled): -if (self._butts[i]._pressed): -if (self._butts[i].contains(event.x, event.y)): -pressed.append( self._butts[i] ) - -if (self._butts[i]._toggle): -self._butts[i]._pressed = not self._butts[i]._pressed +for i in range ( 0, len(self._buttons) ): +if (self._buttons[i]._enabled): +if (self._buttons[i]._pressed): +if (self._buttons[i].contains(event.x, event.y)): +pressed.append( self._buttons[i] ) + +if (self._buttons[i]._toggle): +self._buttons[i]._pressed = not self._buttons[i]._pressed else: -self._butts[i]._pressed = False +self._buttons[i]._pressed = False for i in range( 0, len(pressed) ): pressed[i].doPressed() @@ -170,4 +170,4 @@ class Button: def isImg( self ): -return self._img != None \ No newline at end of file +return self._img != None diff --git a/ui.py b/ui.py index d89b819..e723f66
Re: [Sugar-devel] Problems adapting activity
El Tue, 08-06-2010 a las 15:39 -0300, Daniel Castelo escribió: Have you read this tutorial? http://en.flossmanuals.net/ActivitiesGuideSugar Yeah, this is by far the best documentation we have. All Sugar tutorials on wiki.laptop.org are probably obsolete; we should mark them as such and/or point people to the current versions. -- // 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] initial commit to git?
El Mon, 07-06-2010 a las 00:15 -0400, Art Hunkins escribió: Martin, Thanks for the additional information. Regarding the requirement to add master at the end of the first git push for an activity: nowhere in the wiki git docs do I see (or did I see) mention of this fact. All the examples given end with mainline.git. (This is all I was saying; the command just doesn't work if master is omitted.) I presume this is an important omission, and may well have been the same one blocking Victor Lazzarini, as seen in this (seemingly unresolved) thread (as located by Dev): http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg01655.html Ouch, you're right... can you please fix our wiki? If you have no time or don't know how to do it, just let me know and I'll do it. Thanks! -- // 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] [PATCH] Fixes to the record UI
On 8 June 2010 13:52, anishmangal2...@gmail.com wrote:
Fix description:
The patch works by hiding or resizing (to size 1px by 1px) the
widgets not required in a particular view/mode. The updateVideoComponents
method has been modified to hide the widgets not required in a
particular view. Widgets that can't be hidden are resized to
1 x 1 pixel.
Additionally, this patch also fixes the naming of some variables
(s/butt/button/g).
Tested successfully on sugar-emulator-0.88, soas-mirabelle and
xo1-f11-0.88.
Still unanswered questions from my last mail:
There was probably a reason why it moved them off screen instead of hiding them.
Do you have any idea what it is?
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.
Comments for other reviewers: for me, the patch is now harder to
review because it contains a load of unrelated changes renaming
variables. I agree with the name changes, but perhaps best to be
careful with feedback this way.
On IRC you said that there were some issues with your old patch when
it is applied. Are they 100% resolved now?
Signed-off-by: anishmangal2002 anishmangal2...@gmail.com
---
button.py | 10 ++--
model.py | 2 +
p5_button.py | 30 +-
ui.py | 199
+++---
4 files changed, 129 insertions(+), 112 deletions(-)
diff --git a/button.py b/button.py
index 14b9700..2b0e85c 100644
--- a/button.py
+++ b/button.py
@@ -62,12 +62,12 @@ class RecdButton(TrayButton, gobject.GObject):
return img
- def setButtClickedId( self, id ):
- self.BUTT_CLICKED_ID = id
+ def setButtonClickedId( self, id ):
+ self.BUTTON_CLICKED_ID = id
- def getButtClickedId( self ):
- return self.BUTT_CLICKED_ID
+ def getButtonClickedId( self ):
+ return self.BUTTON_CLICKED_ID
def setup_rollover_options( self, info ):
@@ -105,4 +105,4 @@ class RecdButton(TrayButton, gobject.GObject):
def _itemCopyToClipboardCb(self, widget):
- self.ui.copyToClipboard( self.recd )
\ No newline at end of file
+ self.ui.copyToClipboard( self.recd )
diff --git a/model.py b/model.py
index b7f592b..e24752e 100644
--- a/model.py
+++ b/model.py
@@ -323,6 +323,8 @@ class Model:
def startTakingPhoto( self ):
self.setUpdating( True )
self.ca.glive.takePhoto()
+ self.ca.ui.FULLSCREEN = False
+ self.ca.ui.updateVideoComponents()
This needs some explanation.
We can be taking photos in full screen mode.
There are also no changes in the video components when we are taking a photo.
So these 2 lines seem wrong/unnecessary or indicative of a larger problem.
@@ -335,7 +335,7 @@ class UI:
self.tagsBuffer = gtk.TextBuffer()
self.tagsBuffer.connect('changed', self._tagsBufferEditedCb)
self.tagsField = gtk.TextView(self.tagsBuffer)
- self.tagsField.set_size_request( 100, 100 )
+ self.tagsField.set_size_request( 50, 50 )
self.tagsPanel.pack_start(self.tagsField, expand=True)
self.infoBoxTopLeft.pack_start(self.tagsPanel, expand=True)
Why this change?
@@ -369,7 +369,6 @@ class UI:
self.centered = True
self.setUp()
-
def _mapEventCb( self, widget, event ):
#when your parent window is ready, turn on the feed of live video
self.liveVideoWindow.disconnect(self.MAP_EVENT_ID)
@@ -461,9 +460,11 @@ class UI:
self.slowLiveVideoWindow.connect(visibility-notify-event,
self._visibleNotifyCb)
self.recordWindow = RecordWindow(self)
+ self.recordWindow.set_geometry_hints(min_width=1, min_height=1)
self.addToWindowStack( self.recordWindow,
self.windowStack[len(self.windowStack)-1] )
self.progressWindow = ProgressWindow(self)
+ self.progressWindow.set_geometry_hints(min_width=1, min_height=1)
self.addToWindowStack( self.progressWindow,
self.windowStack[len(self.windowStack)-1] )
self.maxWindow = gtk.Window()
@@ -471,9 +472,11 @@ class UI:
self.maxWindow.modify_bg( gtk.STATE_INSENSITIVE,
Constants.colorBlack.gColor )
maxButton = MaxButton(self)
self.maxWindow.add( maxButton )
+ self.maxWindow.set_geometry_hints(min_width=1, min_height=1)
self.addToWindowStack( self.maxWindow,
self.windowStack[len(self.windowStack)-1] )
self.scrubWindow = ScrubberWindow(self)
+ self.scrubWindow.set_geometry_hints(min_width=1, min_height=1)
self.addToWindowStack( self.scrubWindow,
self.windowStack[len(self.windowStack)-1] )
self.infWindow = gtk.Window()
@@ -492,6 +495,7 @@ class UI:
def _visibleNotifyCb( self, widget, event ):
+
Re: [Sugar-devel] [PATCH] Record - Fix for ticket #2011
Hi Anish, Big thanks for all your efforts! Just wanted to double check on this patch though. On 8 Jun 2010, at 21:12, anishmangal2...@gmail.com wrote: From: anishmangal2002 anishmangal2...@gmail.com Ctrl+w now exits the activity Why Ctrl+w? The two standards for quitting an activity in Sugar are Ctrl+q, and Alt+Esc. Regards, --Gary P.S all your patch efforts are putting me to shame, I must get out an update to Physics! Signed-off-by: anishmangal2002 anishmangal2...@gmail.com --- ui.py |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/ui.py b/ui.py index e723f66..c9ab664 100644 --- a/ui.py +++ b/ui.py @@ -741,6 +741,9 @@ class UI: elif (keyname == 'i' and event.state == gtk.gdk.CONTROL_MASK): if (not self.LIVEMODE): self.infoButtonClicked() +elif (keyname == 'w' and event.state == gtk.gdk.CONTROL_MASK): +self.ca.close() + return False -- 1.7.0.4 ___ 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] Fixes to the record UI
There was probably a reason why it moved them off screen instead of hiding them. Do you have any idea what it is? b480c7ed2e4848f33f11f9df27f6cb34e7c76b82 was a move of elements offscreen instead of hiding, committed 2007-08-31 by erikb, there's no explanation given, and the SVN repository does not appear to be available any longer. -- 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] [PATCH] Fixes to the record UI
james wrote: There was probably a reason why it moved them off screen instead of hiding them. Do you have any idea what it is? b480c7ed2e4848f33f11f9df27f6cb34e7c76b82 was a move of elements offscreen instead of hiding, committed 2007-08-31 by erikb, there's no explanation given, and the SVN repository does not appear to be available any longer. i think anish already answered this, earlier today: There was probably a reason why it moved them off screen instead of hiding them. Do you have any idea what it is? This comment in ui.py explains why # we move offscreen to resize or else we get flashes on # screen, and setting hide() doesn't allow resize moves paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Record - Fix for ticket #2011
http://bugs.sugarlabs.org/ticket/2011 The bug description suggests that ctrl+w is the standard shortcut (maybe I got it wrong!) Also, I tried ctrl+w with write activity and it worked. So I figured that ctrl+w might be the standard shortcut. Cheers, Anish On Wed, Jun 9, 2010 at 5:46 AM, James Cameron qu...@laptop.org wrote: On Wed, Jun 09, 2010 at 01:42:11AM +0530, anishmangal2...@gmail.com wrote: From: anishmangal2002 anishmangal2...@gmail.com Ctrl+w now exits the activity Why? Ctrl+q is the Sugar convention and it works fine. -- 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] [PATCH] Fixes to the record UI
El Wed, 09-06-2010 a las 11:39 +1000, James Cameron escribió: There was probably a reason why it moved them off screen instead of hiding them. Do you have any idea what it is? b480c7ed2e4848f33f11f9df27f6cb34e7c76b82 was a move of elements offscreen instead of hiding, committed 2007-08-31 by erikb, there's no explanation given, and the SVN repository does not appear to be available any longer. Especially in activity code, we shouldn't assume that every line of code is there for a good reason. Many of our core activities were written at OLPC by interns, many of which had no previous experience working with Linux, GTK or Python. In that epic era we were using Fedora 6 or 7, sugar-toolkit was still being crafted and GStreamer was just a steaming pile of unstable code (yes some things never get old). -- // 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] [PATCH] Record - Fix for ticket #2011
El Wed, 09-06-2010 a las 07:58 +0530, Anish Mangal escribió: http://bugs.sugarlabs.org/ticket/2011 The bug description suggests that ctrl+w is the standard shortcut (maybe I got it wrong!) Also, I tried ctrl+w with write activity and it worked. So I figured that ctrl+w might be the standard shortcut. Yeah, I was mistaken on this too: http://wiki.laptop.org/go/Keyboard_shortcuts BTW, I think we should migrate this page somewhere into wiki.sl.org... where would be a good place? Perhaps somewhere within the HIG? http://wiki.sugarlabs.org/go/Human_Interface_Guidelines -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Inter-wiki integration example and opportunities
On Tue, Jun 8, 2010 at 11:19 PM, Bernie Innocenti ber...@codewiz.orgwrote: ... http://wiki.laptop.org/go/Keyboard_shortcuts BTW, I think we should migrate this page somewhere into wiki.sl.org... where would be a good place? Perhaps somewhere within the HIG? http://wiki.sugarlabs.org/go/Human_Interface_Guidelines The page is now embedded at http://wiki.sugarlabs.org/go/Keyboard_shortcuts in order to maintain single source and history while putting the title within the search scope of wiki.laptop.org. The HIG link in the first paragraph points to http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Sugar_Interface/Input_Systems#Keyboard_Shortcuts , which points back to the http://wiki.laptop.org/go/Keyboard_shortcuts page. (If we enable inter-wiki transclusions on both wikis, we could avoid the divergence of source and history for pages like the HIG.) (Inter-wiki searching remains as a systems administration feature development opportunity.) --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Fixes to the record UI
Hi,
I did reply to your mail earlier today, I'll paste my comments here ...
Still unanswered questions from my last mail:
There was probably a reason why it moved them off screen instead of hiding
them.
Do you have any idea what it is?
This comment in ui.py explains why
#we move offscreen to resize or else we get flashes on screen,
and setting hide() doesn't allow resize moves
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.
Incorporated in the updated patch. (And it has removed a load of code)
Also, if you are hiding widgets, I don't see any reason to resize them to 1x1.
For some widgets, when I attempt to hide them, the UI doesn't work, so
I have to resize them to 1x1.
(I only resize only those widgets which I can't hide, so there is no redundancy)
Comments for other reviewers: for me, the patch is now harder to
review because it contains a load of unrelated changes renaming
variables. I agree with the name changes, but perhaps best to be
careful with feedback this way.
Sorry, I'll be careful to include separate changes in different
patches the next time.
On IRC you said that there were some issues with your old patch when
it is applied. Are they 100% resolved now?
The issue was concerning the Fullscreen/Maximize icon which gets
hidden. This has been fixed (and tested on soas/xo1/emulator-0.88).
def startTakingPhoto( self ):
self.setUpdating( True )
self.ca.glive.takePhoto()
+self.ca.ui.FULLSCREEN = False
+self.ca.ui.updateVideoComponents()
This needs some explanation.
We can be taking photos in full screen mode.
There are also no changes in the video components when we are taking a photo.
So these 2 lines seem wrong/unnecessary or indicative of a larger problem.
No problem here. This seemed like a minor quirk to me when compared
with recording videos in fullscreen. When we finish recording a video
in fullscreen mode, we are automatically taken out of fullscreen mode.
However in the case of taking photos, when we click the shutter, the
photo is captured but we remain in full screen mode. This small
snippet takes us out of fullscreen after capturing the photo. We can
totally do without this code as well and the UI would work just fine.
@@ -335,7 +335,7 @@ class UI:
self.tagsBuffer = gtk.TextBuffer()
self.tagsBuffer.connect('changed', self._tagsBufferEditedCb)
self.tagsField = gtk.TextView(self.tagsBuffer)
-self.tagsField.set_size_request( 100, 100 )
+self.tagsField.set_size_request( 50, 50 )
self.tagsPanel.pack_start(self.tagsField, expand=True)
self.infoBoxTopLeft.pack_start(self.tagsPanel, expand=True)
Why this change?
When running record on smaller screen resolutions (or perhaps even xo
resolution), in the info view, the preview window slightly overlaps
with the tags and date text fields. This snippet attempts to fix that.
def getLoc( self, pos, full ):
@@ -1316,6 +1304,7 @@ class UI:
else:
#or, if there is no countdown, it might be because we are
recording
self.clickShutter()
+self.progressWindow.updateProgress( 1,
Constants.istrFinishedRecording )
This change is also surprising to see.
Its a coding artifact :-). I removed many of them from the previous
patch but this one sneaked through. Its redundant code and the UI
works just wine without this. I'll remove this before committing.
Cheers,
Anish
On Wed, Jun 9, 2010 at 4:37 AM, Daniel Drake d...@laptop.org wrote:
On 8 June 2010 13:52, anishmangal2...@gmail.com wrote:
Fix description:
The patch works by hiding or resizing (to size 1px by 1px) the
widgets not required in a particular view/mode. The updateVideoComponents
method has been modified to hide the widgets not required in a
particular view. Widgets that can't be hidden are resized to
1 x 1 pixel.
Additionally, this patch also fixes the naming of some variables
(s/butt/button/g).
Tested successfully on sugar-emulator-0.88, soas-mirabelle and
xo1-f11-0.88.
Still unanswered questions from my last mail:
There was probably a reason why it moved them off screen instead of hiding
them.
Do you have any idea what it is?
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.
Comments for other reviewers: for me, the patch is now harder to
review because it contains a load of unrelated changes renaming
variables. I agree with the name changes, but perhaps best to be
careful with feedback this way.
On IRC you said that there were some issues with your old patch when
it is applied. Are they 100% resolved now?
Signed-off-by:
