Re: [Sugar-devel] Stepping down
El 19/11/11 16:52, Bernie Innocenti escribió: On Fri, 2011-11-18 at 17:59 +0100, Simon Schampijer wrote: Can we change the owner of the git repository (to me)? Or if that is not an easy thing to do can you grant me admin rights? Done! (with the help of aleksey, who is sitting next to me) Wonderful, works great - thanks! Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release ClassRoomBroadcast-1
out of curiosity: What is the advantage of using this activity over VNCLauncher (http://activities.sugarlabs.org/de/sugar/addon/4311)? Out of curiosity, i tried VNCLauncher on OS880 Firstly, I was able to install the client - TigerVNC (though you need root to do it) and run it sudo yum install vnc vncviewer When I ran VNCLauncher, the server, it complained of a missing library /home/olpc/Activities/VncLauncher.activity/x11vnc: error while loading shared libraries: libvncserver.so.0: cannot open shared object file: No such file or directory Am I doing something wrong or is there more to install? Install how? If I understood the discussion correctly, VNCLauncher was thought to be better because it included x11vnc which otherwise you would need to be root to install but does this matter if you need to be root to install the client? If I can get the server and client running I will do a page on the wiki. Tony ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURES] Write to Journal anytime (finally in 0.96?)
Hi, this Feature has a long history and I would like to see it being finished. Replacement for the Naming Alert that lets you write to the Journal at any time while working on an activity. [1] I think this needs another final round of design discussion, the last proposal at (with the same modal alert when you reveal the details in the Journal or from the activity) [2] was partially implemented already. Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime [2] http://wiki.sugarlabs.org/images/e/e2/Detailview_20110313.pdf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Today deadline for proposing features for 0.96
Hi, just a quick reminder that today is the deadline for proposing Features for the 0.96 development cycle [1]. The currently proposed and accepted Features can be seen here [2]. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.96/Roadmap [2] http://wiki.sugarlabs.org/go/0.96/Feature_List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES] Display Device
On Mon, Nov 21, 2011 at 11:02 AM, Simon Schampijer si...@schampijer.dewrote: Hi, I would like to propose the following Feature to enhance the Sugar learning environment: Add a frame device to control the display. The idea is to add their an option to change the brightness and to take a screenshot. Both actions are only available via the keyboard as of today. [1] Regards, Simon [1] http://wiki.sugarlabs.org/go/**Features/Display_Devicehttp://wiki.sugarlabs.org/go/Features/Display_Device Hey Simon, I really like the idea of adding the brightness controls to the frame, especially since that makes it consistent with the volume controls. I'm less convinced about the value of adding the screenshot capability to the frame device. Functionality-wise it is of course related to the display but IMHO it still doesn't quite fit in with the rest of the frame device features. Also I think that today the screenshot functionality is mainly used as a defacto replacement for the lacking print capabilities. Reading through Walter's latest Sugar-Digest it seems like the move to GTK3 will enable much better export / printing capabilities in Activities. As such I feel that adding the screenshot capability to the frame now is more of a short term fix which introduces an inconsistency whereas it should be possible to have a significantly better overall solution soon (e.g. for Sugar 0.98?). Cheers, Christoph -- Christoph Derndorfer editor, OLPC News [www.olpcnews.com] volunteer, OLPC (Austria) [www.olpc.at] e-mail: christ...@derndorfer.eu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Today deadline for proposing features for 0.96
On Mon, Nov 21, 2011 at 5:45 AM, Simon Schampijer si...@schampijer.de wrote: Hi, just a quick reminder that today is the deadline for proposing Features for the 0.96 development cycle [1]. The currently proposed and accepted Features can be seen here [2]. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.96/Roadmap [2] http://wiki.sugarlabs.org/go/0.96/Feature_List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Simon, Maybe I have misunderstood the process or made a mistake along the line, but I had many other features proposed for 0.96 than showed up in your list [2 above]. [3] http://wiki.sugarlabs.org/go/Features/Activity_specific_metadata_in_Journal [4] http://wiki.sugarlabs.org/go/Features/Journal_Volume_Toolbar_enhancement [5] http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view [6] http://wiki.sugarlabs.org/go/Features/Multiple_home_views and dusted off from the past: [7] http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime (this is the only one that made your list) [8] http://wiki.sugarlabs.org/go/Features/Thumbs_View_in_Journal How do I get these proposals considered? regards. -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] [FEATURES] Display Device
Screenshot is a used feature by teachers anyway. Another requested feature is the ability to take a screenshot with the canvas only (probably with a modifier like alt-shift-1). But the problem with a feature only accessed by a hot key is the discoverability. I don't like using the camera icon to this feature... Gonzalo Hey Simon, I really like the idea of adding the brightness controls to the frame, especially since that makes it consistent with the volume controls. I'm less convinced about the value of adding the screenshot capability to the frame device. Functionality-wise it is of course related to the display but IMHO it still doesn't quite fit in with the rest of the frame device features. Also I think that today the screenshot functionality is mainly used as a defacto replacement for the lacking print capabilities. Reading through Walter's latest Sugar-Digest it seems like the move to GTK3 will enable much better export / printing capabilities in Activities. As such I feel that adding the screenshot capability to the frame now is more of a short term fix which introduces an inconsistency whereas it should be possible to have a significantly better overall solution soon (e.g. for Sugar 0.98?). Cheers, Christoph -- Christoph Derndorfer editor, OLPC News [www.olpcnews.com] volunteer, OLPC (Austria) [www.olpc.at] e-mail: christ...@derndorfer.eu ___ 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] [FEATURES] Display Device
On Mon, Nov 21, 2011 at 1:54 PM, Simon Schampijer si...@schampijer.dewrote: El 21/11/11 13:17, Christoph Derndorfer escribió: On Mon, Nov 21, 2011 at 11:02 AM, Simon Schampijersi...@schampijer.de** wrote: Hi, I would like to propose the following Feature to enhance the Sugar learning environment: Add a frame device to control the display. The idea is to add their an option to change the brightness and to take a screenshot. Both actions are only available via the keyboard as of today. [1] Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Display_Devicehttp://wiki.sugarlabs.org/go/**Features/Display_Device http:**//wiki.sugarlabs.org/go/**Features/Display_Devicehttp://wiki.sugarlabs.org/go/Features/Display_Device Hey Simon, I really like the idea of adding the brightness controls to the frame, especially since that makes it consistent with the volume controls. I'm less convinced about the value of adding the screenshot capability to the frame device. Functionality-wise it is of course related to the display but IMHO it still doesn't quite fit in with the rest of the frame device features. Also I think that today the screenshot functionality is mainly used as a defacto replacement for the lacking print capabilities. Reading through Walter's latest Sugar-Digest it seems like the move to GTK3 will enable much better export / printing capabilities in Activities. As such I feel that adding the screenshot capability to the frame now is more of a short term fix which introduces an inconsistency whereas it should be possible to have a significantly better overall solution soon (e.g. for Sugar 0.98?). Cheers, Christoph Hmm, I disagree here. The screenshot functionality is an important tool, used by teachers. I don't think it is only used as an replacement for printing. Which other uses have you seen? Currently it is only accessible by a shortcut, not available in the UI. That it's why the goal is to preset it here. I could not come up with a better place to expose such a functionality, suggestions welcome. How about using one of the unmapped buttons on the XO's keyboard? e.g. the bulletin board button looks similar enough to the copy of a display (with some creativity that is;-) Christoph Regards, Simon -- Christoph Derndorfer editor, OLPC News [www.olpcnews.com] volunteer, OLPC (Austria) [www.olpc.at] e-mail: christ...@derndorfer.eu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES] Display Device
On Mon, Nov 21, 2011 at 7:54 AM, Simon Schampijer si...@schampijer.de wrote: El 21/11/11 13:17, Christoph Derndorfer escribió: On Mon, Nov 21, 2011 at 11:02 AM, Simon Schampijersi...@schampijer.dewrote: Hi, I would like to propose the following Feature to enhance the Sugar learning environment: Add a frame device to control the display. The idea is to add their an option to change the brightness and to take a screenshot. Both actions are only available via the keyboard as of today. [1] Regards, Simon [1] http://wiki.sugarlabs.org/go/**Features/Display_Devicehttp://wiki.sugarlabs.org/go/Features/Display_Device Hey Simon, I really like the idea of adding the brightness controls to the frame, especially since that makes it consistent with the volume controls. I'm less convinced about the value of adding the screenshot capability to the frame device. Functionality-wise it is of course related to the display but IMHO it still doesn't quite fit in with the rest of the frame device features. Also I think that today the screenshot functionality is mainly used as a defacto replacement for the lacking print capabilities. Reading through Walter's latest Sugar-Digest it seems like the move to GTK3 will enable much better export / printing capabilities in Activities. As such I feel that adding the screenshot capability to the frame now is more of a short term fix which introduces an inconsistency whereas it should be possible to have a significantly better overall solution soon (e.g. for Sugar 0.98?). Cheers, Christoph Hmm, I disagree here. The screenshot functionality is an important tool, used by teachers. I don't think it is only used as an replacement for printing. Screen capture is an essential tool for creating documentation, something we'd like to encourage our end users to do. -walter Currently it is only accessible by a shortcut, not available in the UI. That it's why the goal is to preset it here. I could not come up with a better place to expose such a functionality, suggestions welcome. Regards, Simon ___ 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] Hardware Requirements
I want to add a paragraph to the wiki on hardware requirements for SoaS. From http://fedoraproject.org/en/get-fedora For Fedora 16 I see: A 400MHz or faster processor At least 768 MB memory (RAM), 1 GB recommended for best performance. Is it relevant to quote this for SoaS? I found SoaS would fit on a 1GB stick but I quickly wasted the free space. I would recommend a 2GB stick as a good working minimum for a newcomer, any comments? Is the best advice to a newcomer to install the latest version of SoaS? I am thinking, is there any benefit in any older version, on an older machine? My work in progress is here http://wiki.sugarlabs.org/go/User:Inkyfingers/Getting_Started(0) My only qualification for undertaking this is that I am getting started myself, so if anyone has anything to add or correct I would appreciate it. Thanks, Iain aka inkyfingers ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Today deadline for proposing features for 0.96
El 21/11/11 13:29, Walter Bender escribió: On Mon, Nov 21, 2011 at 5:45 AM, Simon Schampijersi...@schampijer.de wrote: Hi, just a quick reminder that today is the deadline for proposing Features for the 0.96 development cycle [1]. The currently proposed and accepted Features can be seen here [2]. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.96/Roadmap [2] http://wiki.sugarlabs.org/go/0.96/Feature_List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Simon, Maybe I have misunderstood the process or made a mistake along the line, but I had many other features proposed for 0.96 than showed up in your list [2 above]. There is a difference between proposing a Feature (mainly creating the page) [1] and proposing it for the release cycle [2]. I did create my list from skimming through the mails that had the '[FEATURE]' tag in it. [3] http://wiki.sugarlabs.org/go/Features/Activity_specific_metadata_in_Journal [4] http://wiki.sugarlabs.org/go/Features/Journal_Volume_Toolbar_enhancement [5] http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view [6] http://wiki.sugarlabs.org/go/Features/Multiple_home_views and dusted off from the past: [7] http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime (this is the only one that made your list) [8] http://wiki.sugarlabs.org/go/Features/Thumbs_View_in_Journal How do I get these proposals considered? regards. -walter Wow, those are quite a few, the list will get long quickly. Of course I will not discourage someone from working on something and as long as a Feature follows the Policy [3] it is considered for the development cycle, but I am a bit skeptical if we can achieve all those features in the next cycle, for the following reasons: * besides writing the code a Feature might have impacts on the workflow and needs design discussions * the code has to be reviewed * we need to test it as well etc * we have the gtk3 work ahead of us So I would propose to talk a bit about what is doable in the development team meeting tomorrow. And if we find agreement that we maybe focus on some items. And yes, it is great to have a pool of items we can choose from, schedule wise we are still in that phase. Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature [2] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle [3] http://wiki.sugarlabs.org/go/Features/Policy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Today deadline for proposing features for 0.96
On Mon, Nov 21, 2011 at 8:10 AM, Simon Schampijer si...@schampijer.de wrote: El 21/11/11 13:29, Walter Bender escribió: On Mon, Nov 21, 2011 at 5:45 AM, Simon Schampijersi...@schampijer.de wrote: Hi, just a quick reminder that today is the deadline for proposing Features for the 0.96 development cycle [1]. The currently proposed and accepted Features can be seen here [2]. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.96/Roadmap [2] http://wiki.sugarlabs.org/go/0.96/Feature_List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Simon, Maybe I have misunderstood the process or made a mistake along the line, but I had many other features proposed for 0.96 than showed up in your list [2 above]. There is a difference between proposing a Feature (mainly creating the page) [1] and proposing it for the release cycle [2]. I did create my list from skimming through the mails that had the '[FEATURE]' tag in it. Could we please make the latter requirement (posting email with a [FEATURE] tag more prominent? I still cannot find it in the documentation. I'll post my proposals to the list. Thanks. (Gonzalo: You have a few unacknowledged proposals as well.) -walter [3] http://wiki.sugarlabs.org/go/Features/Activity_specific_metadata_in_Journal [4] http://wiki.sugarlabs.org/go/Features/Journal_Volume_Toolbar_enhancement [5] http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view [6] http://wiki.sugarlabs.org/go/Features/Multiple_home_views and dusted off from the past: [7] http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime (this is the only one that made your list) [8] http://wiki.sugarlabs.org/go/Features/Thumbs_View_in_Journal How do I get these proposals considered? regards. -walter Wow, those are quite a few, the list will get long quickly. Of course I will not discourage someone from working on something and as long as a Feature follows the Policy [3] it is considered for the development cycle, but I am a bit skeptical if we can achieve all those features in the next cycle, for the following reasons: * besides writing the code a Feature might have impacts on the workflow and needs design discussions * the code has to be reviewed * we need to test it as well etc * we have the gtk3 work ahead of us So I would propose to talk a bit about what is doable in the development team meeting tomorrow. And if we find agreement that we maybe focus on some items. And yes, it is great to have a pool of items we can choose from, schedule wise we are still in that phase. Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature [2] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle [3] http://wiki.sugarlabs.org/go/Features/Policy -- 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] [IAEP] Sugar Digest 2011-11-19
More strings will be coming soon. Our Quechua team also included some remote contributors from Boliviia. As I explained to our teams, localization sprints are great start, but now we start running the ultra-marathon. :-) SugarCamp Lima was incredibly productive (in more ways than just translations, although those are obviously near to my heart). The efforts will continue well beyond this time and they will be so much more successful because of the wonderful shared experiences at EscueLab. We have been so busy working together that we have not communicated enough with the broader community all that has been accomplished. We will fix that in the days to come as the seeds planted grow and bear fruit. cjl On Sun, Nov 20, 2011 at 1:11 PM, Walter Bender walter.ben...@gmail.com wrote: On Sat, Nov 19, 2011 at 11:05 PM, Sebastian Silva sebast...@somosazucar.org wrote: Also today, We'd like to share with the Sugar community our feeling of rejoice since the objectives of the Sugar Camp Lima 2011 have been accomplished: http://sugarcamp.somosazucar.org/ We're very grateful for the contribution of such a select team and very proud to have contributed work to upstream projects. Glad to hear that things have gone well. I know from IRC that Bernie and Chris have been giving their all. I have no doubt that other Sugaristas are working hard as well. Nice to see some .que and .aym strings landing. -walter -walter Hopefully we'll make it to your next digest :P Sebastian somosAZUCAR Sugar Labs Peru El 20/11/11 00:04, Walter Bender escribió: == Sugar Digest == 1. The Learning Team held a discussion about the Portfolio activity this week, which prompted me to make some enhancements. One request was the ability to export your portfolio to a PDF file. It turns out that Cairo supports a PDF surface, making it really easy to export PDF. So one nice by product of moving Sugar activities to Cairo graphics -- which is a necessary step in our migration to GTK3 -- is that it will be much easier to enable activities to export files to the Journal for printing. The other feature I added was the ability to make voice annotations on each page in your portfolio. These voice notes are played back when the portfolio is viewed. They are also saved went the contents are exported to HTML. Alas, PDF does not support audio, as far as I know. Please try Portfolio [1] and give me feedback as to how I can improve it. 2. Monday is the deadline for new feature proposals for Sugar 0.96. There are a number of proposals that have already been submitted (See [2]). Gonzalo Godiard and I have aggregated a number of proposals concerning the Journal in a collector page [3]. These proposed features are a result of the past month of discussion with the Learning Team. Additional feedback on these and all of the new-feature proposal is most welcome. Please add to the discussion on the Talk page of each individual proposal. 3. I mentioned last week that I wrote a plugin for Turtle Blocks that adds a palette for creating models for the Physics activity. (Physics uses a 2D engine called Box2D [4].) I've made a few additions this week, including a block that creates a gear. Building a simple machine should be a bit easier than trying to use the tools exposed by Physics. Of course, there are limits to what one can do with a simple. Working directly with sensors may be a more productive approach. But I have to say, it is really fun to create Box2D models in Turtle Blocks. (See [5] for more details on how to load the plugin and run it.) It is difficult to strike a balance between giving the student a tool and giving the student the skills to make tools. I've wrestled with this quite a bit in Turtle Art over the years. Lately, I am leaning more towards exposing more functionality in the form of predefined blocks than asking that these blocks be built by the user. For example, I recently added blocks for getting mouse x,y coordinates, whereas before, I shipped Python code that could be loaded by the user to accomplish the same thing. Of course, View Source is still available. But where to draw the line is not obvious, at least to me. 4. Cherry Withers pointed out Mr Steve's Exploratorium Blog earlier this week, but I thought it merited mentioning it again (See [6]). === Sugar Labs === Gary Martin has generated SOMs from the past few weeks of discussion on the IAEP mailing list. 2011 Nov 5th - Nov 11 (80 emails) [7] Visit our planet [8] for more updates about Sugar and Sugar deployments. [1] http://wiki.sugarlabs.org/go/Activities/Portfolio [2] http://wiki.sugarlabs.org/go/Features [3] http://wiki.sugarlabs.org/go/Features/Journal_features_for_0.96 [4] [http://box2d.org/ [5] http://wiki.sugarlabs.org/go/Activities/TurtleArt#Plugins [6] http://mrstevesscience.blogspot.com/2011_06_01_archive.html [7] http://wiki.sugarlabs.org/go/File:2011-Nov-5-11.jpg [8]
Re: [Sugar-devel] [DESIGN] meeting proposal to discuss Journal features for 0.96
Hi, 2011/11/21 Gonzalo Odiard gonz...@laptop.org: Hello designers! Can we organize a meeting to talk about these topics, next monday at the usual 15 UTC time? We have a lot of work to do, if we want include these features in 0.96, but first we need define a few design issues. +1 for me! Very interesting topics indeed. I hope Gary can make it. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] meeting proposal to discuss Journal features for 0.96
2011/11/21 Manuel Quiñones ma...@laptop.org: Hi, 2011/11/21 Gonzalo Odiard gonz...@laptop.org: Hello designers! Can we organize a meeting to talk about these topics, next monday at the usual 15 UTC time? We have a lot of work to do, if we want include these features in 0.96, but first we need define a few design issues. +1 for me! Very interesting topics indeed. I hope Gary can make it. +1 for me as well. -- .. manuq .. -- 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] Hardware Requirements
On Mon, Nov 21, 2011 at 1:09 PM, Iain Brown Douglas i...@browndouglas.plus.com wrote: I want to add a paragraph to the wiki on hardware requirements for SoaS. SoaS queries should go to the SoaS mailing list. From http://fedoraproject.org/en/get-fedora For Fedora 16 I see: A 400MHz or faster processor At least 768 MB memory (RAM), 1 GB recommended for best performance. Is it relevant to quote this for SoaS? Mostly, it cam actually use less than that as the requirements for a live usb key is less but I think its reasonable for these days. I found SoaS would fit on a 1GB stick but I quickly wasted the free space. I would recommend a 2GB stick as a good working minimum for a newcomer, any comments? The live image is designed for 2Gb, nasty things can happen if you use less so it should be documented as 2Gb. Is the best advice to a newcomer to install the latest version of SoaS? I am thinking, is there any benefit in any older version, on an older machine? Note sure what you mean by this. My work in progress is here http://wiki.sugarlabs.org/go/User:Inkyfingers/Getting_Started(0) My only qualification for undertaking this is that I am getting started myself, so if anyone has anything to add or correct I would appreciate it. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Activity-specific metadata in Journal
I would like to propose the following Feature to enhance the Sugar learning environment: Record metadata related to the use of an activity and display it in the detail view of the Journal. [1] [1] http://wiki.sugarlabs.org/go/Features/Activity_specific_metadata_in_Journal regards. -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] [FEATURES] Display Device
simon wrote: Hi, I would like to propose the following Feature to enhance the Sugar learning environment: Add a frame device to control the display. The idea is to add their an option to change the brightness and to take a screenshot. Both actions are only available via the keyboard as of today. [1] oh, good idea. in fact, i have another job for it to do. :-) it would be great if it could switch the display from color to monochrome, as well. see my email on automatic backlight control, which i've composed but haven't sent yet. i'll do so right now. paul Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Display_Device ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Journal Volume Toolbar enhancement
I would like to propose the following Feature to enhance the Sugar learning environment: The VolumesToolbar class in volumetoolbar.py should be extended so that Sugar activities can mount directories containing example projects, e.g., the samples subdirectory in Turtle Art. Thus samples will be available through the Sugar Chooser rather than having to use the GNOME file chooser. [1] [1] http://wiki.sugarlabs.org/go/Features/Journal_Volume_Toolbar_enhancement -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
[Sugar-devel] [FEATURE]
I would like to propose the following Feature to enhance the Sugar learning environment: Add the ability to set a background image to the Home View. [1] [1] http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view regards. -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
[Sugar-devel] [FEATURE]
I would like to propose the following Feature to enhance the Sugar learning environment: Option to have different collections of activities on the Home View for formal (classroom) and informal (home) use. [1] [1] http://wiki.sugarlabs.org/go/Features/Multiple_home_views regards. -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
[Sugar-devel] automatic backlight control
this note is kind of long for what seems like a simple feature, but there are some complications i'd like feedback on. i've implemented one of the more amusing features of the 1.75 laptop, which is using its ability to monitor ambient light levels in order to turn off the backlight automatically when you're in bright enough light where you really don't need it -- i.e., mostly when outside in full sun. support for this feature is in the os11, but it's buggy -- os12 will be quite a bit better. this isn't an auto-dim feature -- in bright sunlight, the backlight is turned off, and when the environment isn't bright enough, the backlight is returned to its previous level. it's on or off -- nothing in between. (the _very_ inexpensive light sensor isn't really sensitive enough to allow for finer-grained control than this.) in working on this, i was reminded that currently, when we manually dim the backlight level to 0 (i.e., turn it off) with the keyboard keys, we also change the display's mode from color to monochrome. switching to mono mode effectively raises the screen resolution, giving crisper characters and lines. [1] to my knowledge, this is the only way in which monochrome mode can be invoked. my auto-backlight code did this too, at first, but once backlight control starts happening without user input, this auto-monochrome feature is a bit annoying. it looks much better if turning off the backlight (which happens in full sunlight) doesn't remove the residual color which was there moments before, when, say, a cloud was in front of the sun. (you can see this effect on your XO: take it into full sunlight, and reduce the brightness all the way. then alternately bump it to '1', then back to 0, and you'll see the bit of color that gets gained and lost.) so -- when automatically turning off the backlight, i don't switch the display to monochrome. it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. but monochrome mode has it's advantages, and in the past i've had requests that it should be more available, rather than less. to that end, i've added the ability to force the screen into monochrome hi-res mode manually -- when enabled, it remains monochrome no matter what the brightness is set to. this essentially makes the higher display crispness available indoors as well. this toggle is available with Ctrl-Brightness-Down (for mono) and Ctrl-Brightness-Up (for color). it's also available on the commandline, by usingolpc-brightness [mono|color]. finally: because i think the user experience needs to be uniform across the laptops, these changes will affect XO-1 and XO-1.5 too, even though they have no auto-backlight control. i've already had some guarded negative feedback on both of these new behaviors, so i'm looking for more of that, as well as positive feedback to balance it out. :-) the criticisms were that roughly that: 1) getting rid of monochrome when dimmed to 0 is a major UI change. for my part, i'm not sure i agree that it's so major a change. plus, i'm not sure the feature was well implemented in the first place. (i.e., why no mono mode with the backlight on?) 2) the replacement color/mono control is completely undiscoverable. i guess i'd have to agree with this. there should probably be a UI control for the toggle as well, but i'm not sure it's an important enough feature to warrant frame real estate, for example. please discuss. i realize it's hard to talk about this in the abstract, since most of you don't have 1.75 machines to play with. if you do have one, please try it when os12 comes out. paul [1] http://wiki.laptop.org/go/Display#The_theory =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Thumbnail view in Journal
I would like to repropose the following Feature to enhance the Sugar learning environment (originally proposed by alsroot some time ago): Thumbs view plugin for Journal. [1] [1] http://wiki.sugarlabs.org/go/Features/Thumbs_View_in_Journal regards. -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] automatic backlight control
On Mon, Nov 21, 2011 at 9:22 AM, Paul Fox p...@laptop.org wrote: this note is kind of long for what seems like a simple feature, but there are some complications i'd like feedback on. i've implemented one of the more amusing features of the 1.75 laptop, which is using its ability to monitor ambient light levels in order to turn off the backlight automatically when you're in bright enough light where you really don't need it -- i.e., mostly when outside in full sun. support for this feature is in the os11, but it's buggy -- os12 will be quite a bit better. this isn't an auto-dim feature -- in bright sunlight, the backlight is turned off, and when the environment isn't bright enough, the backlight is returned to its previous level. it's on or off -- nothing in between. (the _very_ inexpensive light sensor isn't really sensitive enough to allow for finer-grained control than this.) in working on this, i was reminded that currently, when we manually dim the backlight level to 0 (i.e., turn it off) with the keyboard keys, we also change the display's mode from color to monochrome. switching to mono mode effectively raises the screen resolution, giving crisper characters and lines. [1] to my knowledge, this is the only way in which monochrome mode can be invoked. my auto-backlight code did this too, at first, but once backlight control starts happening without user input, this auto-monochrome feature is a bit annoying. it looks much better if turning off the backlight (which happens in full sunlight) doesn't remove the residual color which was there moments before, when, say, a cloud was in front of the sun. (you can see this effect on your XO: take it into full sunlight, and reduce the brightness all the way. then alternately bump it to '1', then back to 0, and you'll see the bit of color that gets gained and lost.) so -- when automatically turning off the backlight, i don't switch the display to monochrome. it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. but monochrome mode has it's advantages, and in the past i've had requests that it should be more available, rather than less. to that end, i've added the ability to force the screen into monochrome hi-res mode manually -- when enabled, it remains monochrome no matter what the brightness is set to. this essentially makes the higher display crispness available indoors as well. this toggle is available with Ctrl-Brightness-Down (for mono) and Ctrl-Brightness-Up (for color). it's also available on the commandline, by usingolpc-brightness [mono|color]. finally: because i think the user experience needs to be uniform across the laptops, these changes will affect XO-1 and XO-1.5 too, even though they have no auto-backlight control. i've already had some guarded negative feedback on both of these new behaviors, so i'm looking for more of that, as well as positive feedback to balance it out. :-) the criticisms were that roughly that: 1) getting rid of monochrome when dimmed to 0 is a major UI change. for my part, i'm not sure i agree that it's so major a change. plus, i'm not sure the feature was well implemented in the first place. (i.e., why no mono mode with the backlight on?) 2) the replacement color/mono control is completely undiscoverable. i guess i'd have to agree with this. there should probably be a UI control for the toggle as well, but i'm not sure it's an important enough feature to warrant frame real estate, for example. please discuss. i realize it's hard to talk about this in the abstract, since most of you don't have 1.75 machines to play with. if you do have one, please try it when os12 comes out. paul [1] http://wiki.laptop.org/go/Display#The_theory =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Paul, Unless the display design is different than it was in 2007, then there is no way to decouple turning off the backlight and going into monochrome. Also, turning on the backlight adds color back (although the amount of color vs monochrome in the mix is a function of the backlight vs ambient-light levels. So I am not sure we could implement your proposal with the current hardware. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___
[Sugar-devel] FEATURE: Journal data tagged private or public
I want propose the following feature: Modes private / public: A problem raised by some teachers, is that Journals of his students (and on school servers) are filled with music or games. With this proposal, Sugar would offer you to work in public when working at school or doing homework, or, if you are using Sugar for personal interests, then put your work in private category. This tag would be recorded in the Journal, and could also be changed in the detail view. This mode also works as a filter, so at school all the games and songs are not listed in the Journal. Furthermore, the school server would backup only those items recorded as public. This solves server space problems and helps preserve the privacy of students. More information: http://wiki.sugarlabs.org/go/Features/Journal_data_tagged_private_or_public Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] FEATURE: Multiple selection in the Journal
I want propose Enable operation on multiple selected entries in the Journal. http://wiki.sugarlabs.org/go/Features/Multi_selection ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
On 21.11.2011, at 15:29, Walter Bender wrote: Paul, Unless the display design is different than it was in 2007, then there is no way to decouple turning off the backlight and going into monochrome. Also, turning on the backlight adds color back (although the amount of color vs monochrome in the mix is a function of the backlight vs ambient-light levels. So I am not sure we could implement your proposal with the current hardware. -walter This is about switching the DCON's hardware anti-aliasing. OLPC has started to refer to that as color vs monochrome mode (presumably because it's hard to explain to others why you would or would not want AA). Here's how it works: http://www.squeakland.org/showcase/project.jsp?id=7050 - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
On 21.11.2011, at 15:48, Bert Freudenberg wrote: On 21.11.2011, at 15:29, Walter Bender wrote: Paul, Unless the display design is different than it was in 2007, then there is no way to decouple turning off the backlight and going into monochrome. Also, turning on the backlight adds color back (although the amount of color vs monochrome in the mix is a function of the backlight vs ambient-light levels. So I am not sure we could implement your proposal with the current hardware. -walter This is about switching the DCON's hardware anti-aliasing. OLPC has started to refer to that as color vs monochrome mode (presumably because it's hard to explain to others why you would or would not want AA). Here's how it works: http://www.squeakland.org/showcase/project.jsp?id=7050 - Bert - Err, and the color-averaging I always tend to forget about. The DCON selects either just a single color component for a pixel (color mode) or combines red, green, and blue into a per-pixel value (monochrome mode). In early hw versions this could be toggled separately from the anti-aliasing, while in MP hardware those two were combined IIUC. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
On Mon, Nov 21, 2011 at 9:22 AM, Paul Fox p...@laptop.org wrote: this note is kind of long for what seems like a simple feature, but there are some complications i'd like feedback on. i've implemented one of the more amusing features of the 1.75 laptop, which is using its ability to monitor ambient light levels in order to turn off the backlight automatically when you're in bright enough light where you really don't need it -- i.e., mostly when outside in full sun. support for this feature is in the os11, but it's buggy -- os12 will be quite a bit better. this isn't an auto-dim feature -- in bright sunlight, the backlight is turned off, and when the environment isn't bright enough, the backlight is returned to its previous level. it's on or off -- nothing in between. (the _very_ inexpensive light sensor isn't really sensitive enough to allow for finer-grained control than this.) in working on this, i was reminded that currently, when we manually dim the backlight level to 0 (i.e., turn it off) with the keyboard keys, we also change the display's mode from color to monochrome. switching to mono mode effectively raises the screen resolution, giving crisper characters and lines. [1] to my knowledge, this is the only way in which monochrome mode can be invoked. my auto-backlight code did this too, at first, but once backlight control starts happening without user input, this auto-monochrome feature is a bit annoying. it looks much better if turning off the backlight (which happens in full sunlight) doesn't remove the residual color which was there moments before, when, say, a cloud was in front of the sun. (you can see this effect on your XO: take it into full sunlight, and reduce the brightness all the way. then alternately bump it to '1', then back to 0, and you'll see the bit of color that gets gained and lost.) so -- when automatically turning off the backlight, i don't switch the display to monochrome. it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. but monochrome mode has it's advantages, and in the past i've had requests that it should be more available, rather than less. to that end, i've added the ability to force the screen into monochrome hi-res mode manually -- when enabled, it remains monochrome no matter what the brightness is set to. this essentially makes the higher display crispness available indoors as well. this toggle is available with Ctrl-Brightness-Down (for mono) and Ctrl-Brightness-Up (for color). it's also available on the commandline, by usingolpc-brightness [mono|color]. finally: because i think the user experience needs to be uniform across the laptops, these changes will affect XO-1 and XO-1.5 too, even though they have no auto-backlight control. i've already had some guarded negative feedback on both of these new behaviors, so i'm looking for more of that, as well as positive feedback to balance it out. :-) the criticisms were that roughly that: 1) getting rid of monochrome when dimmed to 0 is a major UI change. for my part, i'm not sure i agree that it's so major a change. plus, i'm not sure the feature was well implemented in the first place. (i.e., why no mono mode with the backlight on?) 2) the replacement color/mono control is completely undiscoverable. i guess i'd have to agree with this. there should probably be a UI control for the toggle as well, but i'm not sure it's an important enough feature to warrant frame real estate, for example. please discuss. i realize it's hard to talk about this in the abstract, since most of you don't have 1.75 machines to play with. if you do have one, please try it when os12 comes out. Not sure if I have gleaned all of what is desired here, but I will share my experience. I have a Samsung N130, a Lenovo S10-2, and an Adam Notion Ink all with Pixel Qi screens. Turning the backlight off and automatically being in monochrome is a desired feature and matches the usage pattern. Initiating the change to brightness by keystroke, instead of via ambient light, is also a feature. . Letting the transreflective aspect of the screen in mono do it's thing, is also a feature to me. Of course, turning off the backlight is accomplished by using an fn-f2 on one box, an fn-f4, on another and a special feature key on the last; but, who's looking for standards? :-) I also have a another three of all the same devices with their factory standard LCD
Re: [Sugar-devel] automatic backlight control
On 21.11.2011, at 15:22, Paul Fox wrote: it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. IMHO (and not having tried it yet) the current behavior (switching to mono when manually reducing brightness) is fine, and the best compromise we found so far. When you add the auto-turnoff, it should only toggle the backlight, not the mono-color setting. I don't think that would be too confusing, from a user's POV it just means when it's bright outside, the backlight's power gets cut. I can see how it would lead to confusion if you map this desired behavior onto the existing olpc-brightness command. What's needed I think is an additional override independent of the brightness setting that just turns the backlight off. Everything else would stay the same. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES] Display Device
On Mon, Nov 21, 2011 at 3:33 PM, Simon Schampijer si...@schampijer.de wrote: El 21/11/11 15:18, Paul Fox escribió: simon wrote: Hi, I would like to propose the following Feature to enhance the Sugar learning environment: Add a frame device to control the display. The idea is to add their an option to change the brightness and to take a screenshot. Both actions are only available via the keyboard as of today. [1] oh, good idea. in fact, i have another job for it to do. :-) it would be great if it could switch the display from color to monochrome, as well. see my email on automatic backlight control, which i've composed but haven't sent yet. i'll do so right now. paul Hi Paul, I just looked at olpc-kbdshim the olpc-brightness for how we adjust the brightness on the XO. Looks like we simply echo the values to the files like '/sys/class/backlight/dcon-bl/brightness'. I wonder what the generic solution is for that (Sugar on other devices). From a quick test, I have the following files on my T61: /sys/class/backlight/intel_backlight/max_brightness and /sys/class/backlight/intel_backlight/actual_brightness which change accordingly when adjusting the brightness. But I guess there is a generic tool for doing that...? /me should probably have a look what GNOME is doing... There's recently been introduced a generic backlight class so I think its all being converted over to that. Its like the IBM one in /sys/class/backlight but I'm not sure the full details for manipulating it programaticly but I'm sure its documented somewhere. Some details are: https://lwn.net/Articles/423170/ https://wiki.kubuntu.org/Kernel/Debugging/Backlight Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES] Display Device
peter wrote: On Mon, Nov 21, 2011 at 3:33 PM, Simon Schampijer si...@schampijer.de wrote: El 21/11/11 15:18, Paul Fox escribió: simon wrote: Hi, I would like to propose the following Feature to enhance the Sugar learning environment: Add a frame device to control the display. The idea is to add their an option to change the brightness and to take a screenshot. Both actions are only available via the keyboard as of today. [1] oh, good idea. in fact, i have another job for it to do. :-) it would be great if it could switch the display from color to monochrome, as well. see my email on automatic backlight control, which i've composed but haven't sent yet. i'll do so right now. paul Hi Paul, I just looked at olpc-kbdshim the olpc-brightness for how we adjust the brightness on the XO. Looks like we simply echo the values to the files like '/sys/class/backlight/dcon-bl/brightness'. I wonder what the generic solution is for that (Sugar on other devices). From a quick test, I have the following files on my T61: /sys/class/backlight/intel_backlight/max_brightness and /sys/class/backlight/intel_backlight/actual_brightness which change accordingly when adjusting the brightness. But I guess there is a generic tool for doing that...? /me should probably have a look what GNOME is doing... There's recently been introduced a generic backlight class so I think its all being converted over to that. Its like the IBM one in /sys/class/backlight but I'm not sure the full details for manipulating it programaticly but I'm sure its documented somewhere. Some details are: https://lwn.net/Articles/423170/ https://wiki.kubuntu.org/Kernel/Debugging/Backlight we seem to implement anything mentioned in those two links. i wouldn't be surprised if there was a more recent higher level interface that might be useful. 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] automatic backlight control
Just to reinforce a few points which maybe might not be clear to people who haven't played with the new hardware: 1) the switch point is set that *you cannot tell when we turn the backlight off*. Ie, the threshold is so high that by the time we turn it off, you couldn't never have told whether the backlight was on or not. This is very different from the auto dim feature in Macs, for example. (And it's the primary reason why the switch to monochrome was so visible -- you couldn't tell that we were turning the backlight on and off, you could only tell that the images on the display were shifting greyscale values intermittently for no obvious reason.) 2) this is a very important power-saving feature for young kids, who generally aren't savvy enough to manually do all these measures which prolong battery life. So, even if power tweakers might want a little more control, it's important to make the default behavior as power-friendly as possible (especially as we move further into deployments where access to power is a big big deal). We should keep in mind the trade-offs here. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FEATURE: Journal data tagged private or public
On Mon, Nov 21, 2011 at 3:35 PM, Gonzalo Odiard gonz...@laptop.org wrote: I want propose the following feature: Modes private / public: A problem raised by some teachers, is that Journals of his students (and on school servers) are filled with music or games. With this proposal, Sugar would offer you to work in public when working at school or doing homework, or, if you are using Sugar for personal interests, then put your work in private category. This tag would be recorded in the Journal, and could also be changed in the detail view. This mode also works as a filter, so at school all the games and songs are not listed in the Journal. Furthermore, the school server would backup only those items recorded as public. This solves server space problems and helps preserve the privacy of students. More information: http://wiki.sugarlabs.org/go/Features/Journal_data_tagged_private_or_public Do you imagine this feature could be tied in with Walter's suggestion for having multiple home views ( http://wiki.sugarlabs.org/go/Features/Multiple_home_views)? e.g. An Activity launched from the school desktop being automatically tagged as public. Or do you think that would leave too many cases which aren't fully and therefore confusingly covered? Christoph -- Christoph Derndorfer editor, OLPC News [www.olpcnews.com] volunteer, OLPC (Austria) [www.olpc.at] e-mail: christ...@derndorfer.eu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
walter wrote: Paul, Unless the display design is different than it was in 2007, then there is no way to decouple turning off the backlight and going into monochrome. Also, turning on the backlight adds color back (although the amount of color vs monochrome in the mix is a function of the backlight vs ambient-light levels. So I am not sure we could implement your proposal with the current hardware. i guess it's changed since 2007 -- at least, it's been this way since 2008. try the following, at any brightness level: while sleep 1 do echo $(( i = ! i )) /sys/devices/platform/dcon/monochrome don =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
kevin wrote: Not sure if I have gleaned all of what is desired here, but I will share my experience. I have a Samsung N130, a Lenovo S10-2, and an Adam Notion Ink all with Pixel Qi screens. Turning the backlight off and automatically being in monochrome is a desired feature and matches the usage pattern. Initiating the change to brightness by keystroke, instead of via ambient light, is also a feature. . Letting the transreflective aspect of the screen in mono do it's thing, is also a feature to me. Of course, turning if i read this right, you're saying that you wouldn't want the display to stay colored with the backlight off? what's your reasoning? the screen is transflective whether in mono mode or not. off the backlight is accomplished by using an fn-f2 on one box, an fn-f4, on another and a special feature key on the last; but, who's looking for standards? :-) I also have a another three of all the same devices with their factory standard LCD screent. Brightness down to 0 on a colour LCD screen, or turning the backlight off, (without the transreflective screen in monochrome) gives me unreadable screens in any light conditions. Down to 1 and staying in colour is fine enough, imo. Backlight off direct to mono on the PQ is fine with me too, imo. Again, just from my point of view, auto-dim was one of the most disturbing UI changes to Lion on the Mac, and one which most of our Mac users have elected to defeat. One person's user experience feature can become another's defect. (Tap-to-click anyone? ) So, if there becomes an ambient light control that in turn auto-dims or changes mode handling or the screen, I would like there to be an easily configurable UI to disable that feature. My 2 cents. bear in mind that this really only kicks in when the surrounding light is bright enough that you literally can't tell whether the backlight is on or not. currently there's no way to disable it. that will change, but i'm not sure what form the UI might take. paul Cheers, KG paul [1] http://wiki.laptop.org/go/Display#The_theory =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
bert wrote: On 21.11.2011, at 15:22, Paul Fox wrote: it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. IMHO (and not having tried it yet) the current behavior (switching to mono when manually reducing brightness) is fine, and the best compromise we found so far. have we actually tried anything else? the coupling of monochrome to brightness has been this way forever, as far as i know. honestly, i'm surprised people consider this coupling to be so important. given how subtle the difference between color and mono modes with the backlight off, i really doubt most users would even notice the change. When you add the auto-turnoff, it should only toggle the backlight, not the mono-color setting. I don't think that would be too confusing, from a user's POV it just means when it's bright outside, the backlight's power gets cut. I can see how it would lead to confusion if you map this desired behavior onto the existing olpc-brightness command. What's needed I think is an additional override independent of the brightness setting that just turns the backlight off. Everything else would stay the same. it's not that easy. unless neither brightness mechanism messes with the mono setting, then they need to be coupled somehow. otherwise if the backlight is auto-offed (still color), then the user uses the dim key (no brightness change, but now mono), and then the backlight auto-ons, it will now be in mono. there's perhaps a way around that, but you can see that it gets tricky to cover all cases. do you also object to the new color/mono toggle, via the control key (or via the UI)? please try os12, when available, and see how it feels. paul - Bert - =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
[ resending to cc: the lists ] dj wrote: Can the keyboard backlight control have an extra step at the end, going trom bright to dim to off/color to off/mono ? Then the auto-backlight would be allowed to bring it down to off/color, and the user could go the extra step to off/mono. (assuming, based on my scant knowledge of the technology, that backlight+mono doesn't make sense here). perhaps. in practice, i suspect most users simply hold the dim key and let it auto-repeat until the backlight is off. backlight + mono actually does make sense, and has been requested in the past. because there's no color averaging going on, you get the full 1200x900 resolution, instead of something effectively less. so reading an ebook, for instance, you might prefer it. paul Alternately, have the system remember when the user manually switches from off/color to off/mono, and use that as the new auto target (i.e. remember both the off user preference (off/color or off/mono) as well as the on user preference (bright..dim)). Think of it (perhaps document it) as switching between indoor and outdoor modes automatically, with the user able to adjust the settings on a per-mode basis. On the older XOs, it could at least remember the color/mono preference for each state, for consistency. Might be amusing to see if the sensor is good enough to at least tell the difference between indoor lighting (i.e. a classroom) vs night reading (i.e. nighttime without any lights) and offer a third remembered setting for that. As for the undiscoverable control, make it a Sugar science activity. Give the user the actual sensor readings, sliders to control the thresholds and hysteresis, etc, and let them play with it. Teaches them about the sensor, the circuitry behind it, the concept of hysteresis, energy conservation (tie in the battery power meter), contrast, and industrial controls. =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES] Display Device
El 21/11/11 17:16, Paul Fox escribió: peter wrote: On Mon, Nov 21, 2011 at 3:33 PM, Simon Schampijersi...@schampijer.de wrote: El 21/11/11 15:18, Paul Fox escribió: simon wrote: Hi, I would like to propose the following Feature to enhance the Sugar learning environment: Add a frame device to control the display. The idea is to add their an option to change the brightness and to take a screenshot. Both actions are only available via the keyboard as of today. [1] oh, good idea. in fact, i have another job for it to do. :-) it would be great if it could switch the display from color to monochrome, as well. see my email on automatic backlight control, which i've composed but haven't sent yet. i'll do so right now. paul Hi Paul, I just looked at olpc-kbdshim the olpc-brightness for how we adjust the brightness on the XO. Looks like we simply echo the values to the files like '/sys/class/backlight/dcon-bl/brightness'. I wonder what the generic solution is for that (Sugar on other devices). From a quick test, I have the following files on my T61: /sys/class/backlight/intel_backlight/max_brightness and /sys/class/backlight/intel_backlight/actual_brightness which change accordingly when adjusting the brightness. But I guess there is a generic tool for doing that...? /me should probably have a look what GNOME is doing... There's recently been introduced a generic backlight class so I think its all being converted over to that. Its like the IBM one in /sys/class/backlight but I'm not sure the full details for manipulating it programaticly but I'm sure its documented somewhere. Some details are: https://lwn.net/Articles/423170/ https://wiki.kubuntu.org/Kernel/Debugging/Backlight we seem to implement anything mentioned in those two links. i wouldn't be surprised if there was a more recent higher level interface that might be useful. paul =- paul fox, p...@laptop.org I have been checking what gnome is doing (gnome-settings-daemon (the functionality was in gnome-power-manager before)): - they use xbacklight [1] if possible to get/set the brightness [2], doing this through the gnome-desktop library [3] - there is fallback code to deal with hardware where xbacklight is not available [4] using the content of /sys/class/backlight Regards, Simon [1] http://linux.die.net/man/1/xbacklight [2] http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-manager.c#n2405 [3] http://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-rr.c#n1682 [4] http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-backlight-helper.c ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
On 21.11.2011, at 18:06, Paul Fox wrote: bert wrote: On 21.11.2011, at 15:22, Paul Fox wrote: it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. IMHO (and not having tried it yet) the current behavior (switching to mono when manually reducing brightness) is fine, and the best compromise we found so far. have we actually tried anything else? the coupling of monochrome to brightness has been this way forever, as far as i know. I remember the command line interface, and some GUI tool with checkboxes. Admittedly that's from before the XO-1 was even mass-produced. But I do remember discussing how the keyboard control should work. honestly, i'm surprised people consider this coupling to be so important. I personally would like to have a way to toggle it on and off all the time, independent of backlight brightness. I'm just saying coupling it to the brightness control is a brilliantly simple way to make it work for users who aren't even aware of the details. given how subtle the difference between color and mono modes with the backlight off, i really doubt most users would even notice the change. To me it's striking how much sharper the image gets all of a sudden. But then I do have a graphics background and am a hobby-typophile. Most users wouldn't consciously notice the change, agreed. But that's not the same as saying it doesn't matter. When you add the auto-turnoff, it should only toggle the backlight, not the mono-color setting. I don't think that would be too confusing, from a user's POV it just means when it's bright outside, the backlight's power gets cut. I can see how it would lead to confusion if you map this desired behavior onto the existing olpc-brightness command. What's needed I think is an additional override independent of the brightness setting that just turns the backlight off. Everything else would stay the same. it's not that easy. unless neither brightness mechanism messes with the mono setting, then they need to be coupled somehow. otherwise if the backlight is auto-offed (still color), then the user uses the dim key (no brightness change, but now mono), and then the backlight auto-ons, it will now be in mono. That's not what I had in mind. Taking your example, the display would not auto-on since the user explicitly set it to off. Auto-off should be completely independent of the user adjusting the brightness. E.g.: Brightness is set to 10. User goes outside, ambient sensor overrides, turning backlight off. User presses brightness-down, level is set to 9. Backlight is still overridden due to ambient light. User goes inside, ambient override stops, backlight comes back on at level 9. See what I mean? The user shouldn't have to care about the ambient light sensor turning off the display. All the controls would still work the same. Just like on older XOs. do you also object to the new color/mono toggle, via the control key (or via the UI)? Not at all. please try os12, when available, and see how it feels. paul Will do. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FEATURE: Journal data tagged private or public
I am not sure. We need think it- Gonzalo Do you imagine this feature could be tied in with Walter's suggestion for having multiple home views ( http://wiki.sugarlabs.org/go/Features/Multiple_home_views)? e.g. An Activity launched from the school desktop being automatically tagged as public. Or do you think that would leave too many cases which aren't fully and therefore confusingly covered? Christoph -- Christoph Derndorfer editor, OLPC News [www.olpcnews.com] volunteer, OLPC (Austria) [www.olpc.at] e-mail: christ...@derndorfer.eu ___ 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] [REMINDER] Development team meeting --- 22. Nov 2011 (15:00 UTC)
Hi, tomorrow we will have our weekly development team meeting: This week topics are: * status of the GTK3 port * current status of the development cycle [1] * proposed Features for the 0.96 cycle [2] * activity team status Time: 15. Nov 2011 (15:00 UTC) Place: #sugar-meeting (freenode) Regards, Simon [1] http://wiki.sugarlabs.org/go/0.96/Roadmap [2] http://wiki.sugarlabs.org/go/0.96/Feature_List#Proposed_Features_for_0.96 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Adding another path for lookup of mfg-data directory
The mfg-data directory is located in another path for some builds, so
the activity has to check in both places for existence. This fixes
Log for olpc #6.
Signed-off-by: Manuel Quiñones ma...@laptop.org
---
logcollect.py | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/logcollect.py b/logcollect.py
index a1251a4..142b140 100644
--- a/logcollect.py
+++ b/logcollect.py
@@ -51,6 +51,9 @@ import httplib
import mimetypes
import urlparse
+MFG_DATA_PATHS = ['/ofw/mfg-data/', '/proc/device-tre/mfg-data/']
+
+
class MachineProperties:
Various machine properties in easy to access chunks.
@@ -111,12 +114,17 @@ class MachineProperties:
return line[8:].strip()
def _mfg_data(self, item):
-Return mfg data item from /ofw/mfg-data/
-
-if not os.path.exists('/ofw/mfg-data/'+item):
+Return mfg data item from mfg-data directory
+
+mfg_path = None
+for test_path in MFG_DATA_PATHS:
+if os.path.exists(test_path + item):
+mfg_path = test_path + item
+break
+if mfg_path == None:
return ''
-
-v = self.__read_file('/ofw/mfg-data/'+item)
+
+v = self.__read_file(mfg_path)
# Remove trailing 0 character, if any:
if v != '' and ord(v[len(v)-1]) == 0:
v = v[:len(v)-1]
--
1.7.7.3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to propose Network proxy configuration in Sugar http://wiki.sugarlabs.org/go/Features/Proxy_configuration - -- Anish Mangal Dextrose Project Manager Activity Central -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOyrQwAAoJEBoxUdDHDZVpV7EH/1qfF3EuGvK70mB2PK5IgQVo OAZXcqtY6bfFBtxWSJmGeHfKvwxIQLnAPD0CaqeZxamV/GfrKZrynpA15lanSJ1o 5RKAjKDnrOO3b+EvYyjCg/hvOb4rxgGQXFENhr6FnITTizxljEha+lcRoDRSCpGT 2ODwXSPEIFDjS7UDYqfh+YkW7LnCVyMHzn557oU9ZoK5Itea4nJUsiOAKMCg5mMN 7fFbcms/Etk1Z/MWkX2FW40WstMnkakAsL8eXJvx+UXMmHQuv/kmRvbtctixwVZH 2wsNaDSU+lJ1kUGtGfSol2sj2BMBhmX3UAUSscKwRXkm0Z6PAzRnO42dOFhjwrY= =PgUo -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES] Display Device
simon wrote: I have been checking what gnome is doing (gnome-settings-daemon (the functionality was in gnome-power-manager before)): - they use xbacklight [1] if possible to get/set the brightness [2], doing this through the gnome-desktop library [3] - there is fallback code to deal with hardware where xbacklight is not available [4] using the content of /sys/class/backlight if you're planning on using standard facilities for backlight control, that might be another argument for not switching mono/color when changing brightness. otherwise either the sugar UI will behave differently than the brightness keys, or sugar will continue needing an XO-specific codepath, in which case you might as well just call olpc-brightness. (but maybe that's what you were planning on doing anyway, and are only exploring standards for non-XO platforms.) paul Regards, Simon [1] http://linux.die.net/man/1/xbacklight [2] http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-m anager.c#n2405 [3] http://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-rr.c#n1682 [4] http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-backlig ht-helper.c ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] automatic backlight control
The shift from colour to monochrome is noticable and would be annoying if it happened a lot, for example as clouds pass, trees and people move. If the hysterisis, the difference between cutin and cutout brightness is large, the change in mode will happen a lot less frequently and not be annoying. I would like to try it switching automatically to monochrome but with large hysterisis. I'll wait to try OS12 Tony ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Sugar Devel][FEATURE][DESIGN] Show thumb drives and SD cards as hierarchical file systems in the Journal UI.
http://wiki.sugarlabs.org/go/Features/Show_Thumb_Drives_As_Hierarchical#Benefit_to_Sugar This is my first attempt to formally propose a feature, so the page is not as complete as it could be. I am not interested in actually implenting the feature, however I have written a fair amount of code that does what I am suggesting which could be useful to the ones who do the work. James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
Yes, Sugar definitely needs this. There are probably many schools that use proxy servers to control what the kids can browse, etc. and there needs to be a simple way to set these up. James Simmons On Mon, Nov 21, 2011 at 2:27 PM, Anish Mangal an...@activitycentral.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to propose Network proxy configuration in Sugar http://wiki.sugarlabs.org/go/Features/Proxy_configuration - -- Anish Mangal Dextrose Project Manager Activity Central -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOyrQwAAoJEBoxUdDHDZVpV7EH/1qfF3EuGvK70mB2PK5IgQVo OAZXcqtY6bfFBtxWSJmGeHfKvwxIQLnAPD0CaqeZxamV/GfrKZrynpA15lanSJ1o 5RKAjKDnrOO3b+EvYyjCg/hvOb4rxgGQXFENhr6FnITTizxljEha+lcRoDRSCpGT 2ODwXSPEIFDjS7UDYqfh+YkW7LnCVyMHzn557oU9ZoK5Itea4nJUsiOAKMCg5mMN 7fFbcms/Etk1Z/MWkX2FW40WstMnkakAsL8eXJvx+UXMmHQuv/kmRvbtctixwVZH 2wsNaDSU+lJ1kUGtGfSol2sj2BMBhmX3UAUSscKwRXkm0Z6PAzRnO42dOFhjwrY= =PgUo -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
On Mon, Nov 21, 2011 at 9:22 AM, Paul Fox p...@laptop.org wrote: i've already had some guarded negative feedback on both of these new behaviors, so i'm looking for more of that, as well as positive feedback to balance it out. :-) Hi folks -- I was one of the early commenters on this. And Paul gave me a, ahem, strong recommendation. All caps. Neon lights, blinking: TRY IT OUT ON AN XO-1.75 None of what Paul says seems to make sense until you try it out on an XO-1.75. Outdoors, in the sun. You can yum update now, or you can get os12 in a couple hours. You can mimic it on earlier hw -- take it to the bright sunlight. Dim it to the lowest backlight. Now hit the 'dimmer' key for greyscale. hth, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
Hi, On Mon, Nov 21 2011, Martin Langhoff wrote: Hi folks -- I was one of the early commenters on this. And Paul gave me a, ahem, strong recommendation. All caps. Neon lights, blinking: TRY IT OUT ON AN XO-1.75 And when *pgf* types in all caps, you *know* it's serious. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] NZ Testing - Letters 23
On 31 October 2011 13:08, Peter Hewitt p...@mulawa.net wrote: This activity requires the player to make the longest English word from 8 random letters. Just wanted to comment on the idea of supplying a list of the missed words. This is most undesirable - many of the words in the computer's dictionary will be completely unknown to the student. The list would really need to take into account the Grade Level of the student as well. Thanks for the feedback ... Peter I think it changes what opportunities for learning are presented to the learner. How about instead of a list of words, a suggested word. e.g. Did you know you could have written ...? The meaning of this word is Here is how it can be used in a sentence ... Perhaps this is an entirely different game. The random letters can make the task of writing a word really hard and sometimes even impossible, particularly if there are no rules around vowels and consonants in the assignment of random letters. Happy to test as well as bounce ideas around, Tabitha ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
But don't forget that many deployments have solved this in build customisation, so check that what you do doesn't break what they do. -- 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] automatic backlight control
On Mon, Nov 21, 2011 at 4:16 PM, Chris Ball c...@laptop.org wrote: And when *pgf* types in all caps, you *know* it's serious. :-) -- actually, he didn't go that far. But I lack his subtlety so I went for it guns ablazing. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] automatic backlight control
i wrote: please try os12, when available, and see how it feels. i'm afraid the necessary firmware didn't make the deadline for os12, so you'll need to either wait for os13, or q4c05 firmware, whichever comes first. 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] [Sugar Devel][FEATURE][DESIGN] Show thumb drives and SD cards as hierarchical file systems in the Journal UI.
On Mon, Nov 21, 2011 at 3:46 PM, James Simmons nices...@gmail.com wrote: http://wiki.sugarlabs.org/go/Features/Show_Thumb_Drives_As_Hierarchical#Benefit_to_Sugar This is my first attempt to formally propose a feature, so the page is not as complete as it could be. I am not interested in actually implenting the feature, however I have written a fair amount of code that does what I am suggesting which could be useful to the ones who do the work. James Simmons ++1, thanks for proposing this James. ___ 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] [ASLO] Release Turtle Blocks-128
Activity Homepage: http://activities.sugarlabs.org/addon/4027 Sugar Platform: 0.82 - 0.96 Download Now: http://activities.sugarlabs.org/downloads/file/27753/turtle_art-128.xo Release notes: 128 BUG FIXES: * Fixed logic error preventing camera capture of multiple frames * Fixed problem with camera autogain (#2651) * Don't zoom text in alert blocks (#3175) Note: Still working on #2624, repeated show camera fails after awhile 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] [FEATURE] Global Text to Speech
Attached is a first try of implementation, to discuss.
Is using gstreamer-plugins-espeak, already included in the last images,
and used in all the activities using text-to-speech. Do not add any new
dependency.
A device is added in the frame to configure pitch and velocity,
and the hotkey alt-shift-s is used to say the selected text.
The SpeechManager provide a simple say_text method to be used by activities
if needed.
A pending functionality is add a list of languages, to translate it and
have a single list,
and do not need translate this list in every activity. There are code in
Speak activity to do this,
I need look at this.
Gonzalo
On Tue, Nov 15, 2011 at 8:16 PM, Samuel Klein meta...@gmail.com wrote:
+1 This would be amazing. This would also encourage more people to
contribute to the speech engine for their language or dialect.
On Tue, Nov 15, 2011 at 9:15 AM, Gonzalo Odiard gonz...@laptop.orgwrote:
I want propose the feature Global Text to Speech [1]
In fact, the functionality was already designed, and part implemented,
but is not working in Sugar.
We have code in Speak, Read and Memorize activities implementing the call
to the backend,
the only missing part is a icon device to configure pitch and velocity.
Gonzalo
[1] http://wiki.sugarlabs.org/go/Features/GlobalTextToSpeech
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Samuel Klein identi.ca:sj w:user:sj +1 617
529 4266
From 8126ce7de174e4b440d93f8987d43ed987c6d823 Mon Sep 17 00:00:00 2001
From: Gonzalo Odiard godi...@gmail.com
Date: Fri, 18 Nov 2011 18:02:40 -0300
Subject: [PATCH] Implement text to speech in Sugar
A device is added to the frame, to configure rate and speech,
the voice is selected based on the LANG variable.
This patch is a initial implementation of the feature
http://wiki.sugarlabs.org/go/Features/Global_Text_To_Speech
Signed-of-by: Gonzalo Odiard gonz...@laptop.org
---
extensions/deviceicon/Makefile.am |1 +
extensions/deviceicon/speech.py | 137
extensions/globalkey/Makefile.am |1 +
extensions/globalkey/speech.py| 24
src/jarabe/model/Makefile.am |1 +
src/jarabe/model/speech.py| 250 +
src/jarabe/view/keyhandler.py | 29 +
7 files changed, 415 insertions(+), 28 deletions(-)
create mode 100644 extensions/deviceicon/speech.py
create mode 100644 extensions/globalkey/speech.py
create mode 100644 src/jarabe/model/speech.py
diff --git a/extensions/deviceicon/Makefile.am b/extensions/deviceicon/Makefile.am
index 118d866..7ed1f77 100644
--- a/extensions/deviceicon/Makefile.am
+++ b/extensions/deviceicon/Makefile.am
@@ -5,5 +5,6 @@ sugar_PYTHON = \
battery.py \
network.py \
speaker.py \
+ speech.py \
touchpad.py \
volume.py
diff --git a/extensions/deviceicon/speech.py b/extensions/deviceicon/speech.py
new file mode 100644
index 000..acf96e1
--- /dev/null
+++ b/extensions/deviceicon/speech.py
@@ -0,0 +1,137 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+from gettext import gettext as _
+import gconf
+
+import glib
+import gtk
+
+from sugar.graphics.icon import Icon
+from sugar.graphics.menuitem import MenuItem
+from sugar.graphics.tray import TrayIcon
+from sugar.graphics.palette import Palette
+from sugar.graphics.xocolor import XoColor
+
+from jarabe.frame.frameinvoker import FrameWidgetInvoker
+from jarabe.model import speech
+
+_ICON_NAME = 'microphone'
+
+
+class SpeechDeviceView(TrayIcon):
+
+FRAME_POSITION_RELATIVE = 105
+
+def __init__(self):
+client = gconf.client_get_default()
+self._color = XoColor(client.get_string('/desktop/sugar/user/color'))
+
+TrayIcon.__init__(self, icon_name=_ICON_NAME, xo_color=self._color)
+
+self.set_palette_invoker(FrameWidgetInvoker(self))
+
+self._manager = speech.get_speech_manager()
+
+self.connect('expose-event', self.__expose_event_cb)
+
+self._icon_widget.connect('button-release-event',
+ self.__button_release_event_cb)
+
+def create_palette(self):
+label =
Re: [Sugar-devel] [Dextrose] [PATCH 50/54] updater: Only pre-select already installed activities (fixes SL#2822, AU#383)
On Mon, Nov 21, 2011 at 8:10 PM, Bernie Innocenti ber...@sugarlabs.org wrote: On Mon, 2011-11-21 at 17:42 -0600, Jerry Vonau wrote: On Tue, 2011-11-08 at 23:17 +0530, Anish Mangal wrote: From: Ajay Garg ajaygargn...@gmail.com OLPC AU uses the software updater to offer easy installing of optional activities. For this to work properly new activities must not be selected by default. Signed-off-by: Ajay Garg a...@sugarlabs.org [adjusted description, split off unrelated bug fixes, set default value] Signed-off-by: Sascha Silbe si...@activitycentral.com Signed-off-by: Anish Mangal an...@sugarlabs.org --- Think this should become a feature for sugar 0.96. Very good. Puno (Peru) also needs the ability to install activities from USB stick because most schools have no connectivity and no school servers. I think it could be hacked together quickly with the current updater. Do we already have some standard for distributing activities on USB sticks? If not, I propose a directory Activities containing the xo bundles. PS: the engineer from Puno sitting next to me says: it's urgent! :) -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Dextrose mailing list dextr...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/dextrose We have had the customization mechanism available for about 3 years now. And single click install from USB also works. But I suppose you want something that runs from the CP update mechanism? No reason why not, I suppose. But why put the .xo bundles in a subdirectory? -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
[Sugar-devel] [FEATURE] Usage statistics gathering
Hi Sugar Community, /* En castellano más abajo */ I would like to propose this feature for inclusion in the next Sugar release: / To gather usage statistics in separate logs from error logs (up to a storage limit). The software improvement process requires usage statistics data to learn from our users./ http://wiki.sugarlabs.org/go/Features/Statistics_gathering /* Castellano */ Me gustaría proponer la siguiente característica para inclusión en la próxima versión de Sugar: /La recolección de estadísticas de uso en registros separados de los registros de error (hasta un límite de almacenamiento). El proceso de mejoramiento de software require de estadísticas de uso para aprender de nuestros usuarios. / http://wiki.sugarlabs.org/go/Features/Statistics_gathering Regards, Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH 50/54] updater: Only pre-select already installed activities (fixes SL#2822, AU#383)
On Mon, 2011-11-21 at 21:58 -0500, Walter Bender wrote: On Mon, Nov 21, 2011 at 8:10 PM, Bernie Innocenti ber...@sugarlabs.org wrote: On Mon, 2011-11-21 at 17:42 -0600, Jerry Vonau wrote: On Tue, 2011-11-08 at 23:17 +0530, Anish Mangal wrote: From: Ajay Garg ajaygargn...@gmail.com OLPC AU uses the software updater to offer easy installing of optional activities. For this to work properly new activities must not be selected by default. Signed-off-by: Ajay Garg a...@sugarlabs.org [adjusted description, split off unrelated bug fixes, set default value] Signed-off-by: Sascha Silbe si...@activitycentral.com Signed-off-by: Anish Mangal an...@sugarlabs.org --- Think this should become a feature for sugar 0.96. Very good. Puno (Peru) also needs the ability to install activities from USB stick because most schools have no connectivity and no school servers. I think it could be hacked together quickly with the current updater. Do we already have some standard for distributing activities on USB sticks? If not, I propose a directory Activities containing the xo bundles. PS: the engineer from Puno sitting next to me says: it's urgent! :) -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Dextrose mailing list dextr...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/dextrose We have had the customization mechanism available for about 3 years now. And single click install from USB also works. But I suppose you want something that runs from the CP update mechanism? No reason why not, I suppose. But why put the .xo bundles in a subdirectory? -walter Where you referring to the customization_stick?[1]. If so that is broken, the MIME types don't get set properly with just an unzip. That is why os-builder move to using sugar-install-bundle in place of unzipping. This is more for the online updater. If you remove an activity, lets say WikipediaES that is listed on the wiki page[2] from the XO, it will be selected to be installed by default when you run software updater. The updater should not tick off the box for something that is not already installed, but leave the box un-ticked. Jerry 1. http://wiki.laptop.org/go/Customization_stick 2. http://wiki.laptop.org/go/Activities/G1G1/11.2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Adding another path for lookup of mfg-data directory
2011/11/21 James Cameron qu...@laptop.org: On Mon, Nov 21, 2011 at 04:25:57PM -0300, Manuel Qui??ones wrote: The mfg-data directory is located in another path for some builds, so the activity has to check in both places for existence. This fixes Log for olpc #6. [...] @@ -51,6 +51,9 @@ import httplib import mimetypes import urlparse +MFG_DATA_PATHS = ['/ofw/mfg-data/', '/proc/device-tre/mfg-data/'] Nak. Typo. device-tree. Make sure you test your patch on an XO-1.75. ;-) Thanks for catching it James. I deleted the character somehow after testing, ouch. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] [FEATURE] Usage statistics gathering
Can you be more specific about type of information collected? Also, filling the disk with statistics does not look like a good idea Interested in reading more Gonzalo On Tue, Nov 22, 2011 at 12:23 AM, Sebastian Silva sebast...@somosazucar.org wrote: Hi Sugar Community, /* En castellano más abajo */ I would like to propose this feature for inclusion in the next Sugar release: * To gather usage statistics in separate logs from error logs (up to a storage limit). The software improvement process requires usage statistics data to learn from our users.* http://wiki.sugarlabs.org/go/Features/Statistics_gathering /* Castellano */ Me gustaría proponer la siguiente característica para inclusión en la próxima versión de Sugar: *La recolección de estadísticas de uso en registros separados de los registros de error (hasta un límite de almacenamiento). El proceso de mejoramiento de software require de estadísticas de uso para aprender de nuestros usuarios. * http://wiki.sugarlabs.org/go/Features/Statistics_gathering Regards, Sebastian ___ Lista olpc-Sur olpc-...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-sur ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] [FEATURE] Usage statistics gathering
I would find it a great start with activity x started / stopped / got focus / lost focus. The spec mentions a storage limit should be taken into consideration. In the 2010 approach taken in Peru, I rotated a log consisting of four 256K files for a total of 1MB maximum. Regards, Sebastian El 22/11/11 09:43, Gonzalo Odiard escribió: Can you be more specific about type of information collected? Also, filling the disk with statistics does not look like a good idea Interested in reading more Gonzalo On Tue, Nov 22, 2011 at 12:23 AM, Sebastian Silva sebast...@somosazucar.org mailto:sebast...@somosazucar.org wrote: Hi Sugar Community, /* En castellano más abajo */ I would like to propose this feature for inclusion in the next Sugar release: / To gather usage statistics in separate logs from error logs (up to a storage limit). The software improvement process requires usage statistics data to learn from our users./ http://wiki.sugarlabs.org/go/Features/Statistics_gathering /* Castellano */ Me gustaría proponer la siguiente característica para inclusión en la próxima versión de Sugar: /La recolección de estadísticas de uso en registros separados de los registros de error (hasta un límite de almacenamiento). El proceso de mejoramiento de software require de estadísticas de uso para aprender de nuestros usuarios. / http://wiki.sugarlabs.org/go/Features/Statistics_gathering Regards, Sebastian ___ Lista olpc-Sur olpc-...@lists.laptop.org mailto:olpc-...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-sur ___ Lista olpc-Sur olpc-...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-sur ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] [FEATURE] Usage statistics gathering
On Tue, Nov 22, 2011 at 2:00 AM, Sebastian Silva sebast...@somosazucar.orgwrote: I would find it a great start with activity x started / stopped / got focus / lost focus. Ok. May be we can ask to the Learning Team what other statistic can be useful? The spec mentions a storage limit should be taken into consideration. Sorry, I misunderstood *up to a storage limit* with *up to the storage limit* :) Gonzalo In the 2010 approach taken in Peru, I rotated a log consisting of four 256K files for a total of 1MB maximum. Regards, Sebastian El 22/11/11 09:43, Gonzalo Odiard escribió: Can you be more specific about type of information collected? Also, filling the disk with statistics does not look like a good idea Interested in reading more Gonzalo On Tue, Nov 22, 2011 at 12:23 AM, Sebastian Silva sebast...@somosazucar.org wrote: Hi Sugar Community, /* En castellano más abajo */ I would like to propose this feature for inclusion in the next Sugar release: * To gather usage statistics in separate logs from error logs (up to a storage limit). The software improvement process requires usage statistics data to learn from our users.* http://wiki.sugarlabs.org/go/Features/Statistics_gathering /* Castellano */ Me gustaría proponer la siguiente característica para inclusión en la próxima versión de Sugar: *La recolección de estadísticas de uso en registros separados de los registros de error (hasta un límite de almacenamiento). El proceso de mejoramiento de software require de estadísticas de uso para aprender de nuestros usuarios. * http://wiki.sugarlabs.org/go/Features/Statistics_gathering Regards, Sebastian ___ Lista olpc-Sur olpc-...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-sur ___ Lista olpc-Surolpc-Sur@lists.laptop.orghttp://lists.laptop.org/listinfo/olpc-sur ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
