Re: [sugar] 9.1 Proposal: Printing support

2008-10-23 Thread Martin Langhoff
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 Thread Martin Langhoff
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

2008-10-23 Thread Greg Smith
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

2008-10-23 Thread Greg Smith
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

2008-10-23 Thread 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?

Thanks,

Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [sugar] 9.1 proposal: View source key everywhere

2008-10-23 Thread Walter Bender
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

2008-10-23 Thread pgf
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

2008-10-23 Thread Bert Freudenberg

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

2008-10-23 Thread pgf
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

2008-10-23 Thread Bert Freudenberg

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

2008-10-23 Thread Greg Smith
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.

2008-10-23 Thread Eben Eliason
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

2008-10-23 Thread pgf
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

2008-10-23 Thread Greg Smith
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

2008-10-23 Thread Greg Smith
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: MD5 Sum for 767 images

2008-10-23 Thread C. Scott Ananian
On Thu, Oct 23, 2008 at 11:34 AM, Greg Smith [EMAIL PROTECTED] wrote:
 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

Sums are alongside each file at
http://download.laptop.org/xo-1/custom/g1g1/gg-767-4/
  --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [sugar] 9.1 proposal: View source key everywhere

2008-10-23 Thread C. Scott Ananian
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

2008-10-23 Thread C. Scott Ananian
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-23 Thread C. Scott Ananian
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.

2008-10-23 Thread Jim Gettys
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.

2008-10-23 Thread Ian Daniher
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

2008-10-23 Thread Marco Pesenti Gritti
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.

2008-10-23 Thread Nate Ridderman
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

2008-10-23 Thread Marco Pesenti Gritti
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


9.1 Proposal: Web based activities

2008-10-23 Thread Marco Pesenti Gritti
Several activities needs a web view and currently duplicate a  lot of
Browse code to implement one. This is a maintenance nigthmare. I would
like to provide a trivial way to create such activities using
sugar-toolkit. I'm looking for feedback about the required
functionalities of such API and ideas on how it could be used.
Combining gtk, html and python/javascript could get pretty powerful.

Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Top five performance problems

2008-10-23 Thread Marco Pesenti Gritti
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

2008-10-23 Thread C. Scott Ananian
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

2008-10-23 Thread Henry Vélez Molina

 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