Re: [sugar] 9.1 Proposal: Printing support
On Thu, Oct 23, 2008 at 4:31 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Oct 21, 2008 at 8:57 AM, [EMAIL PROTECTED] wrote: can's mdns/avahi help with discovery? it'd be a shame to have to manually configure a server address or name. DNS-SD is the Right Answer (which is not exactly the same thing as mdns). But getting a standard one school server, and a classroom of XOs solution in place for 9.1 using a standard name (printer, say) would be a good first step; we can handle autodiscovery (via CUPs or something else) for 9.2. For the 9.1 timeframe we have several services that we'll want to coordinate XS and XO so we need a reasonably good answer at least. I hadn't heard of DNS-SD so I'll make sure we check it out. ... We should not ignore the fact that OLPCs are deployed in places like Birmingham and Montevideo, which have abundant access to paper and printers. Ah, yes. On this thread people are arguing quite strongly for their personal (and opposed) views, I can't quite figure out why. We'll add a tool, and people will be smart and use it where appropriate. And whether they print or not, the world won't end. One thing I do want to mention -- an overly simplisting printing tool will land us in hot water. If we do printing, we better pay attention to the standard dialogs and provide most of the options in there, lest we replay the Torvals-vs-gnome flamefest. (Now, flag this point for _later_ discussion. What optiosn to provide and not provide is a big flamefest of its own, but let's have it a bit later. ) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] XS server
2008/10/23 Henry Vélez Molina [EMAIL PROTECTED]: Verifying from the Terminal activity, we note that doing the ping schoolserver , he print ous: uknown host. We believe that the problem is the Access Point. I agree! That sounds like the AP is acting like a gateway (and that's not what you want). Configure it to be a plain AP - it should set to _no_ routing, no NAT, no DHCP, no DNS. As for the Activity Server and Server Activation Is it possible to deploy at the moment? If you cna wait a few days for the final release of 0.5, then yes. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Proposals for XO Mini-conference Due by Monday October 27
Hi All, We are planning a mini-conference at OLPC headquarters November 17 - 21. For more information, see the conference wiki page at: http://wiki.laptop.org/go/XOcamp_2 Please post any proposals for talks directly on the wiki page at: http://wiki.laptop.org/go/XOcamp_2#Proposals Starting at the end of the day US ET, Monday October 27th we will review all proposals and begin setting the agenda for the conference. Create a new section as needed and make sure your proposed subjects for mini conference are on the wiki by Monday, October 27! Discussion on the lists is useful but its not enough to get a proposal on the agenda. You must also, create a section in the wiki. I will review all e-mails to the [EMAIL PROTECTED] e-mail address. I will forward any that weren't copied to the devel list and I will extract the ones that look like proposals for inclusion in the wiki. In contrast to proposals for the mini-conference, well motivated feature suggestions go on our Feature Roadmap at: http://wiki.laptop.org/go/Feature_roadmap#Requirements_and_Feature_Suggestions In short, proposals for talks at the conference go on the XOcamp wiki page and specific feature and coding work go on our Feature Roadmap page. This is the idea gathering phase (similar to brainstorming). Not everything on the wiki will get built but it must be on the wiki to get considered. Its up to you to add features for the roadmap and proposals for the conference! Please have at it and let me know if you have any questions. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Proposals for XO Mini-conference Due by Monday October 27
Hi All, We are planning a mini-conference at OLPC headquarters November 17 - 21. For more information, see the conference wiki page at: http://wiki.laptop.org/go/XOcamp_2 Please post any proposals for talks directly on the wiki page at: http://wiki.laptop.org/go/XOcamp_2#Proposals Starting at the end of the day US ET, Monday October 27th we will review all proposals and begin setting the agenda for the conference. Create a new section as needed and make sure your proposed subjects for the mini-conference are on the wiki by Monday, October 27! Discussion on the lists is useful but its not enough to get a proposal on the agenda. You must also, create a section in the wiki. I will review all e-mails to the [EMAIL PROTECTED] e-mail address. I will forward any that weren't copied to the devel list and I will extract the ones that look like proposals for inclusion in the wiki. In contrast to proposals for the mini-conference, well motivated feature suggestions go on our Feature Roadmap at: http://wiki.laptop.org/go/Feature_roadmap#Requirements_and_Feature_Suggestions In short, proposals for talks at the conference go on the XOcamp_2 wiki page and specific feature and coding work go on our Feature Roadmap page. This is the idea gathering phase (similar to brainstorming). Not everything on the wiki will get built but it must be on the wiki to get considered. Its up to you to add features for the Roadmap and proposals for the conference! Please have at it and let me know if you have any questions. Thanks, Greg S ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
9.1 proposal: View source key everywhere
Hi, I think that with a small effort, we could implement something much better than what we have today. We have glorious plans for the view source key, but as no resources have been devoted to them, perhaps we should scale back and make sure that we provide the best we can today. And let the future deal with the dreams. Have hacked a quick way of displaying the contents of the currently active activity bundle, along with displaying the source code if the activity ships its source inside the bundle. Screenshot of Implode's source: http://dev.laptop.org/~tomeu/viewsource.png The approach I have followed is installing a global keybinding that is handled in the shell. If you want to try it, it's a matter of dropping the file in the url below into ~/sugar-jhbuild/install/share/sugar/extensions/globalkey, if you have a recent enough sugar-jhbuild. http://dev.laptop.org/~tomeu/viewsource.py This approach has a good thing that is that works everywhere, but has a major problem: doesn't let activities override it and handle themselves the view source key event. This is very bad for activities like Etoys, the ones produced by Pippy or activities that would prefer to display the source code for the _content_ loaded in that moment (Browse). Alternative 1: Move it to sugar-toolkit, would be available to all python activities, and activities would be able to override it easily. Inconvenient: non-python activities wouldn't benefit from it. Alternative 2: Add a mechanism for the shell to know if an activity wishes to provide its own view source window. It could be done by adding one more D-Bus method or by adding one more property to activity.info. Inconvenient: adds complexity to activity development. Opinions? Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] 9.1 proposal: View source key everywhere
I think that any activity that goes to the trouble of building their own view source mechanism can handle the added overhead of adding a line to the activity.info file. Seems like that is the easiest path. Doesn't it have any negative repercussions in the long term? -walter On Thu, Oct 23, 2008 at 8:53 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi, I think that with a small effort, we could implement something much better than what we have today. We have glorious plans for the view source key, but as no resources have been devoted to them, perhaps we should scale back and make sure that we provide the best we can today. And let the future deal with the dreams. Have hacked a quick way of displaying the contents of the currently active activity bundle, along with displaying the source code if the activity ships its source inside the bundle. Screenshot of Implode's source: http://dev.laptop.org/~tomeu/viewsource.png The approach I have followed is installing a global keybinding that is handled in the shell. If you want to try it, it's a matter of dropping the file in the url below into ~/sugar-jhbuild/install/share/sugar/extensions/globalkey, if you have a recent enough sugar-jhbuild. http://dev.laptop.org/~tomeu/viewsource.py This approach has a good thing that is that works everywhere, but has a major problem: doesn't let activities override it and handle themselves the view source key event. This is very bad for activities like Etoys, the ones produced by Pippy or activities that would prefer to display the source code for the _content_ loaded in that moment (Browse). Alternative 1: Move it to sugar-toolkit, would be available to all python activities, and activities would be able to override it easily. Inconvenient: non-python activities wouldn't benefit from it. Alternative 2: Add a mechanism for the shell to know if an activity wishes to provide its own view source window. It could be done by adding one more D-Bus method or by adding one more property to activity.info. Inconvenient: adds complexity to activity development. Opinions? Thanks, Tomeu ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] 9.1 proposal: View source key everywhere
tomeu -- excellent! thanks for helping make progress on this. tomeu wrote: http://dev.laptop.org/~tomeu/viewsource.py This approach has a good thing that is that works everywhere, but has a major problem: doesn't let activities override it and handle themselves the view source key event. This is very bad for activities like Etoys, the ones produced by Pippy or activities that would prefer to display the source code for the _content_ loaded in that moment (Browse). the ultimate fallback would simply be a URL, with which Browse could take you to a (hopefully friendly) source browser on the web somewhere -- to browse CVS or git, for instance, or even just to an upstream program-specific website where more information is available. as you implied, flexibility is the key. Alternative 1: Move it to sugar-toolkit, would be available to all python activities, and activities would be able to override it easily. Inconvenient: non-python activities wouldn't benefit from it. Alternative 2: Add a mechanism for the shell to know if an activity wishes to provide its own view source window. It could be done by adding one more D-Bus method or by adding one more property to activity.info. Inconvenient: adds complexity to activity development. an addition to activity.info, with sensible defaults, would be the best bet, i think. default behaviors could include going to bundled source, as you've implemented, and/or using the activity_source URL that many activities provide on the download page on the wiki. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 proposal: View source key everywhere
Am 23.10.2008 um 14:53 schrieb Tomeu Vizoso: Hi, I think that with a small effort, we could implement something much better than what we have today. We have glorious plans for the view source key, but as no resources have been devoted to them, perhaps we should scale back and make sure that we provide the best we can today. And let the future deal with the dreams. Have hacked a quick way of displaying the contents of the currently active activity bundle, along with displaying the source code if the activity ships its source inside the bundle. Screenshot of Implode's source: http://dev.laptop.org/~tomeu/viewsource.png The approach I have followed is installing a global keybinding that is handled in the shell. If you want to try it, it's a matter of dropping the file in the url below into ~/sugar-jhbuild/install/share/sugar/extensions/globalkey, if you have a recent enough sugar-jhbuild. http://dev.laptop.org/~tomeu/viewsource.py This approach has a good thing that is that works everywhere, but has a major problem: doesn't let activities override it and handle themselves the view source key event. This is very bad for activities like Etoys, the ones produced by Pippy or activities that would prefer to display the source code for the _content_ loaded in that moment (Browse). Alternative 1: Move it to sugar-toolkit, would be available to all python activities, and activities would be able to override it easily. Inconvenient: non-python activities wouldn't benefit from it. Alternative 2: Add a mechanism for the shell to know if an activity wishes to provide its own view source window. It could be done by adding one more D-Bus method or by adding one more property to activity.info. Inconvenient: adds complexity to activity development. Opinions? This would definitely be an improvement :) I'd add a DBus method to the activity protocol answering a boolean. If the activity answers False (or does not implement the method) the system would do its best to show the source. If it answers True, the activity handled the request on its own. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] 9.1 proposal: View source key everywhere
bert wrote: Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: an addition to activity.info, with sensible defaults, would be the best bet, i think. This would mean that sometimes the shell and sometimes the activity would have to handle that key, which is fragile. I'd opt for the shell always handling the key, then trying to invoke the activity's view source function, and if that fails, handle it itself. That not handled by activity case could of course be customized by entries in activity.info. sure, that's fine. but i think we need to keep thinking about how to support of non-, or not-fully-sugarized applications with every new feature we do (as well as with every revision of old features). paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] 9.1 proposal: View source key everywhere
Am 23.10.2008 um 15:33 schrieb [EMAIL PROTECTED]: bert wrote: Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: an addition to activity.info, with sensible defaults, would be the best bet, i think. This would mean that sometimes the shell and sometimes the activity would have to handle that key, which is fragile. I'd opt for the shell always handling the key, then trying to invoke the activity's view source function, and if that fails, handle it itself. That not handled by activity case could of course be customized by entries in activity.info. sure, that's fine. but i think we need to keep thinking about how to support of non-, or not-fully-sugarized applications with every new feature we do (as well as with every revision of old features). Right. Hence the fallback to the default viewer if the activity does not implement that (or any) DBus method. Or did I misunderstand you? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Feature Roadmap and Miniconference Meeting Notes
Hi All, I need to move the weekly future feature planning meeting next week. The next meeting will be Wed. October 29 in IRC, freenode.net #olpc-meeting channel at 1PM US ET (not 2PM as previously communicated). I have a hard stop at the end of one hour so we will try to stay on agenda. I apologize for the change. A conflict came up that I couldn't move. We will go back to the regular 2PM US ET time after next week. Thanks, Greg S Greg Smith wrote: Hi All, We met on IRC on Wed. October 22 to talk about the XO feature roadmap and plans for the mini-conference November 17 - 21. Brief minutes: Talked about getting more feature requests in feature roadmap page. Talked about getting sugar list on feature roadmap page. Debated 1-1 and onto, and set theory re: sugar list and XO list. Decided for Greg and Eben to make sure that all sugar for XO items have a place on XO feature roadmap. Decided to set deadline for submission of conference proposals of Monday October, 27. Asked everyone to review of all submissions at: http://wiki.laptop.org/go/XOcamp_2#Proposals and to prepare to pick the target set next Wed. Asked everyone to add feature ideas t http://wiki.laptop.org/go/Feature_roadmap Closed action items: AI : Greg will send an e-mail asking for call for proposals for November meeting (called XOcamp). GS - Closed. Sent e-mail last week. AI : Ed and Kim will talk together about support and deployment input and ensure that it gets included. GS - Closed. Kim and Ed working on it and will ensure relevant proposals and presentations are booked. Open and new action items: AI: Greg to resend request for proposals and include deadline of Monday October 27. Will send to devel, sugar, techteam and server lists. AI: Everybody: Read and update wiki. Add any major feature request to: http://wiki.laptop.org/go/Feature_roadmap#Requirements_and_Feature_Suggestions link to relevant threads on lists as needed. AI: Greg to add submission to xocamp e-mail address to xocamp2 wiki proposals section: http://wiki.laptop.org/go/XOcamp_2 AI: Eben to transfer or transclude or link XO related sugar features on feature roadmap page. Next meeting: Wed. 10/29 2PM US ET freenode.net #olpc-meeting. Agenda for next week: Review/discuss/vote on proposals in the meeting, set owners for organizing into an agenda Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
I could be talking nonsense, and perhaps this would consume more power than it saves, but if you were able to slowly dim the backlight over the course of a minute or so, instead of waiting a minute and then dropping it suddenly, we could prevent the sudden change which causes a break in concentration. (As long as the screen is bright enough to be usable when dim, of course.) - Eben On Wed, Oct 22, 2008 at 4:21 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi, When running on battery with Energy Saver set to Better Battery Life (which sets Automatically reduce the brightness of the display before display sleep) the backlight dims after 30 seconds. On AC with the equivalent setting it's 2 minutes, 30 seconds. In each case the dimming time seems to be 50% of the time until the screen is turned off. 1 minute is the minimum time before display sleep. Thanks! I was hoping someone would have numbers. Our backlight dim currently happens fifty seconds after idleness starts, so we're definitely less aggressive than OS X already.. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] 9.1 proposal: View source key everywhere
bert wrote: Am 23.10.2008 um 15:33 schrieb [EMAIL PROTECTED]: bert wrote: Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: an addition to activity.info, with sensible defaults, would be the best bet, i think. This would mean that sometimes the shell and sometimes the activity would have to handle that key, which is fragile. I'd opt for the shell always handling the key, then trying to invoke the activity's view source function, and if that fails, handle it itself. That not handled by activity case could of course be customized by entries in activity.info. sure, that's fine. but i think we need to keep thinking about how to support of non-, or not-fully-sugarized applications with every new feature we do (as well as with every revision of old features). Right. Hence the fallback to the default viewer if the activity does not implement that (or any) DBus method. Or did I misunderstand you? sorry i wasn't more clear -- we're in complete agreement. (it was when you said add a method to the dbus activity protocol that you pushed my Must Defend Traditional Apps button. :-) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
MD5 Sum for 767 images
Hi All, Can someone post the MD5 Sum details for the 8.2 images linked from the release notes? See the request at: http://wiki.laptop.org/go/Talk:Release_notes/8.2.0 Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Thread on a new model for collaboration
Hi All, Below is a thread I had with Juliano (learning team member with lots of experience in Brazil and more recently Rwanda) on collaboration. I wanted to share it with everyone, mostly verbatim. I haven't had time to edit this for the list but I wanted to share it before waiting any longer. The main idea is that there is another asynchronous concept of collaboration which we may be able to implement with less complexity than what we now call collaboration (e.g. http://wiki.laptop.org/go/9.1.0_Collaboration_Requirements). Comments and input welcome. Thanks, Greg S Hi Greg, Thanks for the answer. I will read your message more carefully since it has many ideas, so I can think and bring new ideas. But two points I can comment right now are that you can cite me in public messages. I just send it in private so I don't expose nobody and everybody are aware of the history of the idea. The other is that I know the edublog since the beginning, actually even before it start. Uruguay was interested in Using AMADIS, but I hold it since the tool, yet interesting, was very unstable. They became interested because, Léa Fagundes, my former boss, is very famous is Uruguay in the education area and made a lot of propaganda about amadis. After that, Pablo flores and others start thinking abou EduBlog. But I think we need something different than just a blog, however using some blog interface ideas. You can thing some information about amadis in: http://wiki.laptop.org/go/AMADIS And in Portuguese in: http://amadis.lec.ufrgs.br Maybe google translator can give you some help. Write more soon. Thanks again, Juliano On 24/09/2008, at 21:15, Greg Smith wrote: Hi Juliano, Thanks a lot for reviewing the 9.1 page and for offering these suggestions on where we should focus our development. We all get bogged down in the daily challenge of deploying these computers, but this kind of feedback is super valuable. I think everyone is very receptive to the Learning team members taking the lead in setting the direction of future development. On the 9.1 page in general, its mostly a catch all place right now. I haven't had time to add more structure and categorization yet. I hope to focus on that starting late next week. BTW If someone wants to take a stab at an overall pedagogical strategy, that would be great! I have a section reserved for that at: http://wiki.laptop.org/go/9.1.0#Pedagogical_Strategy I did get some related input from David when we had a brief chat in August. I haven't fleshed that out but it resulted in two points in the Collaboration Strategy section at bullets 2 and 3: http://wiki.laptop.org/go/9.1.0#Collaboration It doesn't really cover the workflow of collaborative building of projects so I added bullet #4 to cover your comments. Edit and update that to fit your conception. Just keep it short and we can add detail in the collaboration section below. On your main idea, I like the way you break it in to synchronous and asynchronous. I think that will resonate well with the engineers. Starting with the synchronous, I have a thread with the lead GUI engineer about how best to build an interface that let's kids take a project home, do some work then integrate it in write when they are all online. See: http://lists.laptop.org/pipermail/devel/2008-September/018874.html The baseline idea right now is for each kid to write their stuff at home, then in class the next day they open two instances of write. One has their personal work and the other the shared write instance. Then they can copy and paste from their personal one to the shared one. I think we can do better than that. So far, the best idea is to have a button add to share that just takes whatever is selected and copies it to the shared instance. That saves the intermediate clipboard step. Cleaner but still kuldgy as you have to look at two activities and switch between them. Any comments appreciated. One thing you could especially help with is to explain exactly how kids collaborate on a common project together. If you can describe it in terms of who sits where, who types what and how they decide what goes in to the shared/final project, that will help a lot. I've been asking my kids but I could use some more explanation from people who have spent time in class. e.g. does one kid type and other kids look over their shoulder and make suggestions? Do they pass the shared project around and take turns? A take home then come together example using paper and pencil examples is a good place to start. On the asynchronous case which is I think your main point, I completely agree this is central to successful education. Do you have a link or any more info on AMADIS? As it happens, I have been involved in a related project (started when I was a volunteer) called EduBlog. You can see an
Re: [sugar] 9.1 proposal: View source key everywhere
On Thu, Oct 23, 2008 at 9:33 AM, [EMAIL PROTECTED] wrote: sure, that's fine. but i think we need to keep thinking about how to support of non-, or not-fully-sugarized applications with every new feature we do (as well as with every revision of old features). I've got a half-baked idea about support 'view source' in unmodified applications using a similar mechanism to the one I'd considering for Translate. This might give a better 'default' behavior for some activities written in python, but I like Tomeu's approach for the rest. And the general idea of having a standard mechanism to register your own 'view source' handler is great. Maybe I'll get some time to hack that up before Nov 17. In any case, I look forward to Tomeu's talk! --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Proposals for XO Mini-conference Due by Monday October 27
On Thu, Oct 23, 2008 at 7:43 AM, Greg Smith [EMAIL PROTECTED] wrote: We are planning a mini-conference at OLPC headquarters November 17 - 21. Starting at the end of the day US ET, Monday October 27th we will review all proposals and begin setting the agenda for the conference. It would probably be worthwhile to save a few 'lightning talk' slots of, say, 5 minutes each, spread throughout the week. Last minute ideas, or ideas generated by discussion during the week, can get slotted into a lightning talk slot on the fly. I've also found 'lightning talks' to be very useful for filling time if a speaker is late, has technical problems, or etc. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DISPLAY variable in 767?
2008/10/22 Ian Daniher [EMAIL PROTECTED]: I'm curious what the DISPLAY variable is in os767 as I used to be able to set it to 0:0 and launch gui apps(mplayer) from the command line. I'm working on the mother-of-all media center scripts and could use some help. I'll share this script upon completion, until then ping me for info and feel free to send me advise. I think we handled this on IRC. DISPLAY=:0 works, as before, but I think the Ian's XAUTHORITY was confused. 'xhost +' worked around his problems. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
How well we can do that isn't clear. We have 16 brightness levels, but we didn't think about making them logarithmic in response to correspond to the eye's behavior, so there are really fewer than that that are useful. Please experiment and see if it is helpful, of course... - Jim On Thu, 2008-10-23 at 10:14 -0400, Eben Eliason wrote: I could be talking nonsense, and perhaps this would consume more power than it saves, but if you were able to slowly dim the backlight over the course of a minute or so, instead of waiting a minute and then dropping it suddenly, we could prevent the sudden change which causes a break in concentration. (As long as the screen is bright enough to be usable when dim, of course.) - Eben On Wed, Oct 22, 2008 at 4:21 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi, When running on battery with Energy Saver set to Better Battery Life (which sets Automatically reduce the brightness of the display before display sleep) the backlight dims after 30 seconds. On AC with the equivalent setting it's 2 minutes, 30 seconds. In each case the dimming time seems to be 50% of the time until the screen is turned off. 1 minute is the minimum time before display sleep. Thanks! I was hoping someone would have numbers. Our backlight dim currently happens fifty seconds after idleness starts, so we're definitely less aggressive than OS X already.. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
Hello all, This is somewhat on-topic, as this code can be used to test the smoothness of diming the backlight by editing SLP in the included code. I originally wrote this as I'm planning on using an XO motherboard/screen as an alarm clock, and will have the brightness set via some fancy HR=$(date +%H) magic. Questions and comments are appreciated. CODE FILE=/sys/class/backlight/dcon-bl/brightness VAL=0 SLP=.1 while [ $VAL -lt 15 ] do echo $VAL $FILE echo $VAL VAL=`expr $VAL + 1` sleep $SLP done while [ $VAL -gt 0 ] do echo $VAL $FILE echo $VAL VAL=`expr $VAL - 1` sleep $SLP done echo done CODE / Best, -- Ian Daniher -- OLPC Support Volunteer OLPCinci Repair Center Coordinator On Thu, Oct 23, 2008 at 4:45 PM, Jim Gettys [EMAIL PROTECTED] wrote: How well we can do that isn't clear. We have 16 brightness levels, but we didn't think about making them logarithmic in response to correspond to the eye's behavior, so there are really fewer than that that are useful. Please experiment and see if it is helpful, of course... - Jim On Thu, 2008-10-23 at 10:14 -0400, Eben Eliason wrote: I could be talking nonsense, and perhaps this would consume more power than it saves, but if you were able to slowly dim the backlight over the course of a minute or so, instead of waiting a minute and then dropping it suddenly, we could prevent the sudden change which causes a break in concentration. (As long as the screen is bright enough to be usable when dim, of course.) - Eben On Wed, Oct 22, 2008 at 4:21 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi, When running on battery with Energy Saver set to Better Battery Life (which sets Automatically reduce the brightness of the display before display sleep) the backlight dims after 30 seconds. On AC with the equivalent setting it's 2 minutes, 30 seconds. In each case the dimming time seems to be 50% of the time until the screen is turned off. 1 minute is the minimum time before display sleep. Thanks! I was hoping someone would have numbers. Our backlight dim currently happens fifty seconds after idleness starts, so we're definitely less aggressive than OS X already.. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
9.1 Proposal: Compatibility with desktop applications
Two high level goals: * Make desktop applications run without modifications in the Sugar shell and integrate as much as possible with it. * Make activities run on a standard desktop, as long as the required services are installed. Problems we need to solve to make this possible: * Our icon classes should be extended to better support non-svg icons. * Support the startup notification spec. * Respect the WM_ICON hint. * Obsolete the BUNDLE_ID X property, make the ACTIVITY_ID one optional. * Support system installed desktop files, display them in the home view and allow to launch them. * Replace matchbox with a fully compliant window manager (which?) Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
Do we have the ability to pulse width modulate the backlight LEDs? What is the resolution on the PWM? It's hard to know if this is feasible without a hardware schematic and specs on the backlight driver. The CL1 spec mentions a PWM signal, but maybe it only has four bits of resolution? In the cell phone world, PWM is used pretty regularly as an approach to dim backlights. It's much cheaper than having a bunch of analog current sensing circuitry. I believe 100 Hz or greater is required to reduce flickering, but this might be higher on a larger screen. Sometimes using PWM on LEDs can create spectral noise, especially if there is no soft start mechanism in the LED driver, so the antenna desensitivity would probably need to be tested against this approach. Thanks, Nate On Thu, Oct 23, 2008 at 4:45 PM, Jim Gettys [EMAIL PROTECTED] wrote: How well we can do that isn't clear. We have 16 brightness levels, but we didn't think about making them logarithmic in response to correspond to the eye's behavior, so there are really fewer than that that are useful. Please experiment and see if it is helpful, of course... - Jim On Thu, 2008-10-23 at 10:14 -0400, Eben Eliason wrote: I could be talking nonsense, and perhaps this would consume more power than it saves, but if you were able to slowly dim the backlight over the course of a minute or so, instead of waiting a minute and then dropping it suddenly, we could prevent the sudden change which causes a break in concentration. (As long as the screen is bright enough to be usable when dim, of course.) - Eben On Wed, Oct 22, 2008 at 4:21 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi, When running on battery with Energy Saver set to Better Battery Life (which sets Automatically reduce the brightness of the display before display sleep) the backlight dims after 30 seconds. On AC with the equivalent setting it's 2 minutes, 30 seconds. In each case the dimming time seems to be 50% of the time until the screen is turned off. 1 minute is the minimum time before display sleep. Thanks! I was hoping someone would have numbers. Our backlight dim currently happens fifty seconds after idleness starts, so we're definitely less aggressive than OS X already.. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
9.1 Proposal: Top five performance problems
Problems and ideas in no particular order. * Sugar shell startup is too slow. Reduce dependencies, single process shell, modularize and delay initialization of components which are not immediately necessary, measure constantly to avoid regressions and monitor progress. * Icons rendering is slow and uses too much memory. Cache svg icon on disk pre-rendered and mmap them, render colored icons using a mask per color, user server side pixmaps to speed up rendering of some of the icons. * Activity startup is ridiculously slow. Design an API incompatible Activity class. Start from a very basic window and add functionalities on the top of it, trying to not regress startup time. Make sure that launcher feedback does not slow down startup. * Browse performance and memory usage. Investigation to do here. I'm hoping to have more concrete data by the 17 Nov. * The frame is too slow to appear and disappear. Experiment with pixmap caching. Is an empty frame fast enough? Composite the active window and the frame. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 1:56 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: * Activity startup is ridiculously slow. Design an API incompatible Activity class. Start from a very basic window and add functionalities on the top of it, trying to not regress startup time. Make sure that launcher feedback does not slow down startup. A discussion about preloading and lazy loading approaches to the slow module imports problems would also be interesting. pylauncher VS gobject-introspection? both? Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Babbage Net School (Chicago Tutoring Center) Laptop Deployment
On Wed, Oct 22, 2008 at 8:02 PM, Victoria Blackaby [EMAIL PROTECTED] wrote: We've spoken a few times on the IRC chat line. I'm Victoria from Chicago, trying to deploy XO's for a tutoring center. I've spoken with you and Mitch about using a fedora base with fvwm to handle our tutoring section, and then giving the students a chance to switch between xfce and sugar, which was, as I was lead to understand, in the works. ;) So... now.. we have 300 XO's, and they are sitting in my office, and I am attempting to follow your instructions of packaging everything I need in an RPM and installing them on the machines. This was to prevent the developer-key issue, the unlocking the machines issue, the signed image issue, and like four other issues I don't remember. The only thing is, there laptops are build 656, so if I understand right, I will need to upgrade them to a later build in order for the switcher and other programs to work, then install my RPM that adds the functionality I need. This then becomes a multi-step procedure for me, flashing the new images, installing my deployment changes, and then, installing the individual student's curriculum on the machines. In talking to Lfaraone in chat, he suggested that I just get a signed build. However, when I first asked about a signed build in April I was told there weren't enough time or resources to sign a build for me,and that I should go the RPM route. Can you please advise me on how to proceed? Reflashing the machines to 8.2 would probably be the best way to start. That takes time; there are multicast mechanisms which can be used but they tend to be very tricky to set up. Maybe someone on devel@ can give you better guidance on that. Otherwise, making 10 or so USB keys and flashing in parallel is not *too* painful. Instead of XFCE, I'd recommend using the Fedora build for the XO. You will need developer keys. You should probably begin by creating a collection key using the instructions at http://wiki.laptop.org/go/Activation_and_developer_keys and collecting serial numbers and UUIDs from all 300 machines and submitting that to [EMAIL PROTECTED] to get a developer key file for all 300 machines. XFCE was a experiment, it's not officially supported. The Fedora community is going to support the Fedora/XO port; they should be able to help you customize it for you use. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XS server
If you cna wait a few days for the final release of 0.5, then yes. ok Thanks ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
