Re: [Sugar-devel] [RELEASE] Moon-10

[Gary C Martin]

On 14 Mar 2009, at 02:19, Ton van Overbeek wrote:

> Gary,
>
> When running on small screens (800x600) the text on the left hand
> side does not fit, but there is no scroll bar.
> The moon image scales fine.
>
> I get the 800x600 screen when running a SoaS2 snapshot iso in VMware  
> Player
> on Windows.

Thanks for the report Ton, yea I know, here's my own feature request  
to myself :-)

http://dev.sugarlabs.org/ticket/506

Having to suddenly run on multiple hardware configurations with  
multiple resolutions, multiple fonts, and multiple dpi; has really put  
the cat among the Activity pigeons :-)

Regards,
--Gary

> Ton van Overbeek

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Moon-10

[Ton van Overbeek]

Gary,

When running on small screens (800x600) the text on the left hand
side does not fit, but there is no scroll bar.
The moon image scales fine.

I get the 800x600 screen when running a SoaS2 snapshot iso in VMware Player
on Windows.

Ton van Overbeek
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] Moon-10

[Gary C Martin]

== .XO Bundle ==

http://activities.sugarlabs.org/en-US/sugar/addon/4034
http://wiki.laptop.org/images/0/0e/Moon-10.xo
...or use the Software Update panel.

== Source ==

http://download.sugarlabs.org/sources/honey/Moon/Moon-10.tar.bz2

== Git ==

http://git.sugarlabs.org/projects/moon

== Features ==

- Future proof use of json to stop keep error in F11 distros (thanks  
again to alsroot)
- Updated localizations

== Documentation ==

http://wiki.laptop.org/go/Moon

Regards,
--Gary

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS-2] Another Snapshot!

[Bert Freudenberg]

On 14.03.2009, at 00:07, Gary C Martin wrote:

> On 13 Mar 2009, at 20:10, Caroline Meeks wrote:
>
>> I am getting a grey screen on the two computers I've tried it on.
>
> FWIW: It's booting fine here on a Mac using Sun's VirtualBox, haven't
> done much more than boot it and run a few Activities yet.
>
> Regards,
> --Gary

Hangs for me in VMWare Fusion right after loading initrd, does not  
continue to boot nor start X. Previous image worked fine.

- Bert -


>> On Fri, Mar 13, 2009 at 2:17 PM, Sebastian Dziallas >> wrote:
>> Hi folks,
>>
>> there's another new - though, completely untested - snapshot of  
>> soas-2
>> ready and waiting for you here:
>>
>> http://download.sugarlabs.org/soas/snapshots/2/Soas2-200903131725.iso
>>
>> A log file from the build process has been posted, too:
>>
>> http://shell.sugarlabs.org/sdz/soas2-20090313.log
>>
>> So what is new?
>>
>> * most activities have been updated to their latest version
>> * sugar-update-control is now included - thanks to SMParrish
>> * etoys, speak and read activity should now really be on it ;)
>> * keyboard layout changes should be possible via system-config-
>> keyboard
>> * the soas version information has been incorporated correctly
>>
>> Concerning the last point: When booting the image, you should see a
>> screen with the Fedora wallpaper for one second - press escape here
>> and
>> you should get to the boot menu, where you'll see the image's name.
>>
>> By the way, Fedora 11 (on which SoaS-2 is based) has entered beta
>> freeze: So quite some packages won't be changing for now, but with  
>> the
>> upcoming snapshots - as Rawhide progresses - it should stabilize  
>> more.
>>
>> Well, that's it so far. As always, please report any issues you
>> encounter. Thanks and happy testing!
>>
>>   --Your SoaS Team
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>>
>> -- 
>> Caroline Meeks
>> Solution Grove
>> carol...@solutiongrove.com
>>
>> 617-500-3488 - Office
>> 505-213-3268 - Fax
>> ___
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS-2] Another Snapshot!

[Gary C Martin]

On 13 Mar 2009, at 20:10, Caroline Meeks wrote:

> I am getting a grey screen on the two computers I've tried it on.

FWIW: It's booting fine here on a Mac using Sun's VirtualBox, haven't  
done much more than boot it and run a few Activities yet.

Regards,
--Gary

> On Fri, Mar 13, 2009 at 2:17 PM, Sebastian Dziallas  > wrote:
> Hi folks,
>
> there's another new - though, completely untested - snapshot of soas-2
> ready and waiting for you here:
>
> http://download.sugarlabs.org/soas/snapshots/2/Soas2-200903131725.iso
>
> A log file from the build process has been posted, too:
>
> http://shell.sugarlabs.org/sdz/soas2-20090313.log
>
> So what is new?
>
> * most activities have been updated to their latest version
> * sugar-update-control is now included - thanks to SMParrish
> * etoys, speak and read activity should now really be on it ;)
> * keyboard layout changes should be possible via system-config- 
> keyboard
> * the soas version information has been incorporated correctly
>
> Concerning the last point: When booting the image, you should see a
> screen with the Fedora wallpaper for one second - press escape here  
> and
> you should get to the boot menu, where you'll see the image's name.
>
> By the way, Fedora 11 (on which SoaS-2 is based) has entered beta
> freeze: So quite some packages won't be changing for now, but with the
> upcoming snapshots - as Rawhide progresses - it should stabilize more.
>
> Well, that's it so far. As always, please report any issues you
> encounter. Thanks and happy testing!
>
>--Your SoaS Team
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> -- 
> Caroline Meeks
> Solution Grove
> carol...@solutiongrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
> ___
> 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] announce: alternate power management

[pgf]

david wrote:
 > Very cool!
 > 
 > How well will this integrate with the power management systems other
 > distros are using?  Can it become a 'Value Added' for other netbook
 > manufacturers?

while i'd love to say i did a lot of research and prep in order
to make sure my little project was api compliant and future
compatible with other power management systems, i can't say that.

my goal's were small:  to produce a lighter weight skeleton on
which to hang XO power management, in order to reduce the effort
needed to add some small features (that i wanted) to the current
functionality, and to make sure it was distro, desktop, and UI
independent.  (i also wanted to prove to myself that it could
really be done the way i was picturing it).

paul


 > 
 > david
 > 
 > On Fri, Mar 13, 2009 at 4:33 PM,   wrote:
 > > hi --
 > >
 > > i had an itch that needed scratching, and the result is a
 > > reimplementation of much (but not all) of what ohmd does
 > > currently.
 > >
 > > i've thought for some time (and i believe cjb agrees) that ohmd
 > > is needlessly difficult to maintain and modify for our purposes
 > > on the XO.  small improvements are difficult to implement
 > > quickly.
 > >
 > > since my heart is with more quasi-embedded systems than the XO's
 > > current incarnation, part of my goal was to do a rewrite which
 > > was not dependent on hald, dbus, or X11 -- power management
 > > should work well from a console screen, and be available even if
 > > none of those services is running.
 > >
 > > i call the service i wrote "powerd".  it gets user idle/active
 > > reports from the olpc-kbdshim daemon (which is watching all
 > > user keypress and touchpad activity in any case), and it gets
 > > reports regarding the hardware inputs (power button, lid and
 > > ebook switches, ac adapter status, battery level, etc) either
 > > from another small daemon that monitors /dev/input/event{0,1,2},
 > > or from /sys nodes directly.
 > >
 > > it basically recreates ohmd's "dim after a bit, then sleep"
 > > behavior, with some additions:
 > >
 > >  - a power button splash screen:  a second press of the power
 > >     button invokes shutdown, simply waiting for a brief timeout
 > >     invokes suspend, and any user activity cancels.  (i even
 > >     managed to kinda sorta convey all that with graphics.  i'm
 > >     sure every UI person that sees it will roll their eyes.)
 > >
 > >  - configurable timeouts for screen dim and sleep.  the dim
 > >    level is configurable.
 > >
 > >  - different power management behavior when on wall power vs.
 > >    battery -- many laptop owners don't need to be miserly with
 > >    power when running from an external source.  powerd makes
 > >    this behavior selectable.
 > >
 > >  - different power behavior when in ebook mode (though detection
 > >    may be unreliable -- i think the ebook switch suffers from
 > >    some issues we previously noticed with the lid switch).  this
 > >    should let you configure things like a very short timeout until
 > >    idle-suspend, and/or no screen dimming, when in ebook mode.  (i
 > >    find the frequent on/off nature of the backlight when reading
 > >    in ebook mode to be a distraction.)
 > >
 > >  - clean shutdown on critically low battery.  (currently set at
 > >    a reported 5%, at which point my laptop would only run for
 > >    another couple of minutes.)
 > >
 > >  - the ability to run arbitrary scripts after a resume.  (perhaps
 > >    to reinit usb devices that don't suspend/resume properly?  haven't
 > >    used this much yet.)
 > >
 > >  - ease of customization, given that it's written in everyone's
 > >    favorite interpreted language.
 > >
 > >  unimplemented:
 > >
 > >  - inhibiting idle suspend based on system or network load.
 > >    i.e., the system will dim or suspend when watching a video.
 > >    (there are hooks in place where these features should be
 > >    implemented -- they're just not coded at all.)  there's
 > >    no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
 > >    instead.
 > >
 > >  - no special support for the wireless mesh, whatsoever.  i
 > >    couldn't remember how it was supposed to work, and i recall
 > >    cjb saying it's hard to figure out whether the mesh is active
 > >    or not.
 > >
 > >  - there's some support for wake-on-wlan, but it's not well tested.
 > >
 > >  finally a big one:
 > >  - proper support for USB keyboards and mice.  i recently
 > >    realized that since olpc-kbdshim only monitors the built-in
 > >    keyboard and touchpad, powerd will think the user is idle
 > >    while they type on a USB keyboard, and cheerfully suspend
 > >    regardless.  (in my case, most of the time i want to
 > >    auto-suspend is when i'm running on battery, and not using
 > >    external devices, so i sort of forgot about this case.)
 > >
 > > anyway, code is available here:
 > >   Â

Re: [Sugar-devel] Priorities and Ideas (for GSoC)

[Jameson Quinn]

>
> My fourth priority is other educational activities. There are 
> hundreds
> of  
> good
> ideas  out there.


Just to clarify: this is not to denigrate activities. In the end, Sugar will
stand or fall on its activities. But my attitude here is "if you build it,
they will come"; we have to take care of the other priorities, so that
people are motivated to make/bring more activities.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Priorities and Ideas (for GSoC)

[David Farning]

Hey Jameson, Mel

Thanks for _proving_ me wrong.  I had originally thought that Sugar
Labs would only have the resources to handle two mentors/students this
summers with out getting bogged down.

It now looks like you have got a great handle on the project.

david

On Fri, Mar 13, 2009 at 4:49 PM, Jameson Quinn  wrote:
> I will link to this thread (in IAEP) on the GSoC project ideas page. This
> page is the primary location where prospective GSoC students will come to
> learn about out project, and so I want them to get a feel for our community
> discussion of priorities. So please, in this thread, try to be a little bit
> more explicit and foot-noted than you would be otherwise, so they can
> understand what we're talking about.
>
> The primary purpose of GSoC, as others have pointed out, is NOT to do the
> things we're too busy to get around to. It is primarily a community-building
> exercise: to get students engaged in helping Sugar, and get mentors engaged
> in passing on knowledge to new community members. If somebody develops an
> educational game that only blind 3-year-olds use, but FINISHES it, has a
> great time doing it, and becomes a long-term contributing community member,
> then that would be a total GSoC success. However, that being said, we'd
> still prefer projects that help acheive our highest priorities for Sugar.
>
> There is no absolute ordering of Sugarlabs' priorities. Different members
> will not agree perfectly on what steps will do more to help our educational
> mission. So the list below is just my version. Community: Please respond
> with your thoughts. Students: I'll link what I can in the list, but I can't
> find good links, or even any links, for everything. If one of these ideas
> intrigues you, please, come ask in IRC (#sugar on freenode) - we'd love to
> try to point you in the right direction, and help you cut your ideas down to
> a reasonable GSoC size.
>
> My first priority is things that will have a strong effect on the long-term
> rate of development of Sugar. I'd put just 2 things in that category: easier
> sugarizing (primarily from AJAX, Flash, and legacy Linux); and a structure
> for sugar unit tests (IMO we will never get good enough software quality for
> wide adoption, running on multiple distribution without automated testing).
>
> My second priority is things that will improve on sugar's key promises. An
> easier and better way to handle files: versioned datastore, improvements in
> creating and using tags for the journal, file picker dialogs, and home view.
> A simpler and safer security model: getting Rainbow into the Sugar platform
> and improving it's coverage of the Bitfrost ideals. A simple and
> discoverable, yet powerful, UI overall: improved accessibility, discoverable
> keyboard shortcuts. Ubiquitous connectivity and collaboration: multi-pointer
> sharing, auto-collaborating data structures, viral/peer-to-peer activity
> distribution, shared journals. Useful in the classroom: a one-click workflow
> for getting AND turning in homework.
>
> My third priority is activities to better cover the core functions. Reading:
> an improved Read, which handles true ebook formats. (PDF is made for
> printing, and deployments have asked for this.) Writing: Write is pretty
> good. Communication: an email activity. Math: a good spreadsheet/graphing
> utility (spreadsheets are not the best back-end for graphs, but they are
> very very flexible).
>
> My fourth priority is other educational activities. There are hundreds of
> good ideas out there.
>
> Let me repeat, the best project is the one that gets done. The highest
> priorities on my list are also the hardest. An achievable idea for an
> educational activity is better than pie in the sky. And if you want to take
> on a bigger task, ask us in IRC - we will help guide you.
>
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Priorities and Ideas (for GSoC)

[Sayamindu Dasgupta]

On Sat, Mar 14, 2009 at 3:19 AM, Jameson Quinn  wrote:
> I will link to this thread (in IAEP) on the GSoC project ideas page. This
> page is the primary location where prospective GSoC students will come to
> learn about out project, and so I want them to get a feel for our community
> discussion of priorities. So please, in this thread, try to be a little bit
> more explicit and foot-noted than you would be otherwise, so they can
> understand what we're talking about.
>
> The primary purpose of GSoC, as others have pointed out, is NOT to do the
> things we're too busy to get around to. It is primarily a community-building
> exercise: to get students engaged in helping Sugar, and get mentors engaged
> in passing on knowledge to new community members. If somebody develops an
> educational game that only blind 3-year-olds use, but FINISHES it, has a
> great time doing it, and becomes a long-term contributing community member,
> then that would be a total GSoC success. However, that being said, we'd
> still prefer projects that help acheive our highest priorities for Sugar.
>
> There is no absolute ordering of Sugarlabs' priorities. Different members
> will not agree perfectly on what steps will do more to help our educational
> mission. So the list below is just my version. Community: Please respond
> with your thoughts. Students: I'll link what I can in the list, but I can't
> find good links, or even any links, for everything. If one of these ideas
> intrigues you, please, come ask in IRC (#sugar on freenode) - we'd love to
> try to point you in the right direction, and help you cut your ideas down to
> a reasonable GSoC size.
>
> My first priority is things that will have a strong effect on the long-term
> rate of development of Sugar. I'd put just 2 things in that category: easier
> sugarizing (primarily from AJAX, Flash, and legacy Linux); and a structure
> for sugar unit tests (IMO we will never get good enough software quality for
> wide adoption, running on multiple distribution without automated testing).
>
> My second priority is things that will improve on sugar's key promises. An
> easier and better way to handle files: versioned datastore, improvements in
> creating and using tags for the journal, file picker dialogs, and home view.
> A simpler and safer security model: getting Rainbow into the Sugar platform
> and improving it's coverage of the Bitfrost ideals. A simple and
> discoverable, yet powerful, UI overall: improved accessibility, discoverable
> keyboard shortcuts. Ubiquitous connectivity and collaboration: multi-pointer
> sharing, auto-collaborating data structures, viral/peer-to-peer activity
> distribution, shared journals. Useful in the classroom: a one-click workflow
> for getting AND turning in homework.
>
> My third priority is activities to better cover the core functions. Reading:
> an improved Read, which handles true ebook formats. (PDF is made for
> printing, and deployments have asked for this.)

Regarding support for more Ebook formats, in case it is relevant, I am
working on a sugarized FBReader[1] activity at the moment. I should be
able to do a preliminary release by tomorrow. (I was planning a
release tonight, but my main workstation seems to be incredibly messed
up, and won't boot, so I need to fix that first)

Screenshot at http://dev.laptop.org/~sayamindu/fbreader_sugar_v2.png
Thanks,
Sayamindu

[1] http://www.fbreader.org/
-- 
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Priorities and Ideas (for GSoC)

[Jameson Quinn]

I will link to this thread (in IAEP) on the GSoC project
ideaspage. This
page is the primary location where prospective GSoC students will
come to learn about out project, and so I want them to get a feel for our
community discussion of priorities. So please, in this thread, try to be a
little bit more explicit and foot-noted than you would be otherwise, so they
can understand what we're talking about.

The primary purpose of GSoC, as others have pointed out, is NOT to do the
things we're too busy to get around to. It is primarily a community-building
exercise: to get students engaged in helping Sugar, and get mentors engaged
in passing on knowledge to new community members. If somebody develops an
educational game that only blind 3-year-olds use, but FINISHES it, has a
great time doing it, and becomes a long-term contributing community member,
then that would be a total GSoC success. However, that being said, we'd
still prefer projects that help acheive our highest priorities for Sugar.

There is no absolute ordering of Sugarlabs' priorities. Different members
will not agree perfectly on what steps will do more to help our educational
mission. So the list below is just my version. Community: Please respond
with your thoughts. Students: I'll link what I can in the list, but I can't
find good links, or even any links, for everything. If one of these ideas
intrigues you, please, come ask in IRC (#sugar on freenode) - we'd love to
try to point you in the right direction, and help you cut your ideas down to
a reasonable GSoC size.

My first priority is things that will have a strong effect on the long-term
rate of development of Sugar. I'd put just 2 things in that category: easier
sugarizing (primarily from
AJAX,
Flash , and
legacy Linux); and a structure for sugar unit tests (IMO we will never get
good enough software quality for wide adoption, running on multiple
distribution without automated
testing
).

My second priority is things that will improve on sugar's key promises. An
easier and better way to handle files: versioned
datastore,
improvements in creating and
usingtags for the
journal, file picker dialogs, and home
view . A
simpler and safer security model: getting Rainbow into the Sugar
platformand
improving
it's coverage of the Bitfrost
ideals.
A simple and discoverable, yet powerful, UI overall: improved accessibility,
discoverable keyboard shortcuts. Ubiquitous connectivity and collaboration:
multi-pointer sharing, auto-collaborating data
structures,
viral/peer-to-peer activity
distribution,
shared journals. Useful in the classroom: a one-click workflow for getting
AND turning in 
homework
.

My third priority is activities to better cover the core functions. Reading:
an improved 
Read,
which handles true ebook formats. (PDF is made for printing, and deployments
have asked for this.) Writing: Write is pretty good. Communication: an email
activity. Math: a good spreadsheet/graphing utility (spreadsheets are not
the best back-end for graphs, but they are very very flexible).

My fourth priority is other educational activities. There are
hundreds
of 
good
ideas  out there.

Let me repeat, the best project is the one that gets done. The highest
priorities on my list are also the hardest. An achievable idea for an
educational activity is better than pie in the sky. And if you want to take
on a bigger task, ask us in IRC - we will help guide you.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] announce: alternate power management

[David Farning]

Very cool!

How well will this integrate with the power management systems other
distros are using?  Can it become a 'Value Added' for other netbook
manufacturers?

david

On Fri, Mar 13, 2009 at 4:33 PM,   wrote:
> hi --
>
> i had an itch that needed scratching, and the result is a
> reimplementation of much (but not all) of what ohmd does
> currently.
>
> i've thought for some time (and i believe cjb agrees) that ohmd
> is needlessly difficult to maintain and modify for our purposes
> on the XO.  small improvements are difficult to implement
> quickly.
>
> since my heart is with more quasi-embedded systems than the XO's
> current incarnation, part of my goal was to do a rewrite which
> was not dependent on hald, dbus, or X11 -- power management
> should work well from a console screen, and be available even if
> none of those services is running.
>
> i call the service i wrote "powerd".  it gets user idle/active
> reports from the olpc-kbdshim daemon (which is watching all
> user keypress and touchpad activity in any case), and it gets
> reports regarding the hardware inputs (power button, lid and
> ebook switches, ac adapter status, battery level, etc) either
> from another small daemon that monitors /dev/input/event{0,1,2},
> or from /sys nodes directly.
>
> it basically recreates ohmd's "dim after a bit, then sleep"
> behavior, with some additions:
>
>  - a power button splash screen:  a second press of the power
>     button invokes shutdown, simply waiting for a brief timeout
>     invokes suspend, and any user activity cancels.  (i even
>     managed to kinda sorta convey all that with graphics.  i'm
>     sure every UI person that sees it will roll their eyes.)
>
>  - configurable timeouts for screen dim and sleep.  the dim
>    level is configurable.
>
>  - different power management behavior when on wall power vs.
>    battery -- many laptop owners don't need to be miserly with
>    power when running from an external source.  powerd makes
>    this behavior selectable.
>
>  - different power behavior when in ebook mode (though detection
>    may be unreliable -- i think the ebook switch suffers from
>    some issues we previously noticed with the lid switch).  this
>    should let you configure things like a very short timeout until
>    idle-suspend, and/or no screen dimming, when in ebook mode.  (i
>    find the frequent on/off nature of the backlight when reading
>    in ebook mode to be a distraction.)
>
>  - clean shutdown on critically low battery.  (currently set at
>    a reported 5%, at which point my laptop would only run for
>    another couple of minutes.)
>
>  - the ability to run arbitrary scripts after a resume.  (perhaps
>    to reinit usb devices that don't suspend/resume properly?  haven't
>    used this much yet.)
>
>  - ease of customization, given that it's written in everyone's
>    favorite interpreted language.
>
>  unimplemented:
>
>  - inhibiting idle suspend based on system or network load.
>    i.e., the system will dim or suspend when watching a video.
>    (there are hooks in place where these features should be
>    implemented -- they're just not coded at all.)  there's
>    no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
>    instead.
>
>  - no special support for the wireless mesh, whatsoever.  i
>    couldn't remember how it was supposed to work, and i recall
>    cjb saying it's hard to figure out whether the mesh is active
>    or not.
>
>  - there's some support for wake-on-wlan, but it's not well tested.
>
>  finally a big one:
>  - proper support for USB keyboards and mice.  i recently
>    realized that since olpc-kbdshim only monitors the built-in
>    keyboard and touchpad, powerd will think the user is idle
>    while they type on a USB keyboard, and cheerfully suspend
>    regardless.  (in my case, most of the time i want to
>    auto-suspend is when i'm running on battery, and not using
>    external devices, so i sort of forgot about this case.)
>
> anyway, code is available here:
>    http://dev.laptop.org/git/users/pgf/powerd/
> and rpms are here:
>    http://dev.laptop.org/~pgf/rpms/
>
> you'll need to install both olpc-kbdshim and olpc-powerd (in that
> order).  when installed, olpc-powerd disables ohmd, and reenables
> it when uninstalled.  (so it's relatively safe to try.)
>
> there's no gui or other convenience for configuration --
> see/etc/powerd/powerd.conf.  the installed defaults should be
> reasonable.  and you'll need to run:
>    echo reconfig >/var/run/powerevents
> after making changes to the config file.
>
> paul
> =-
>  paul fox, p...@laptop.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] soc ideas

[Eben Eliason]

I think that might be referring to the new toolbar designs.  See
http://sugarlabs.org/go/DesignTeam/Designs/Toolbars for some
screenshots.  You can also get some more background about the pros and
cons, and logic for the design by listening to my short talk on it:
http://download.laptop.org/content/conf/20080403-olpc-mini-conf/Toolbars/

Feel free to ask questions, if you have any.

- Eben


On Fri, Mar 13, 2009 at 4:36 PM, vishak baby  wrote:
> I saw this thing in the project ideas for soc, Sugar Toolbar submenu support
> ,could anyone elaborate on this thing?
>
> ___
> 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] announce: alternate power management

[pgf]

hi --

i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.

i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO.  small improvements are difficult to implement
quickly.

since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.

i call the service i wrote "powerd".  it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.

it basically recreates ohmd's "dim after a bit, then sleep"
behavior, with some additions:

  - a power button splash screen:  a second press of the power
 button invokes shutdown, simply waiting for a brief timeout
 invokes suspend, and any user activity cancels.  (i even
 managed to kinda sorta convey all that with graphics.  i'm
 sure every UI person that sees it will roll their eyes.)

  - configurable timeouts for screen dim and sleep.  the dim
level is configurable.

  - different power management behavior when on wall power vs. 
battery -- many laptop owners don't need to be miserly with
power when running from an external source.  powerd makes
this behavior selectable.

  - different power behavior when in ebook mode (though detection
may be unreliable -- i think the ebook switch suffers from
some issues we previously noticed with the lid switch).  this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode.  (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)

  - clean shutdown on critically low battery.  (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)

  - the ability to run arbitrary scripts after a resume.  (perhaps
to reinit usb devices that don't suspend/resume properly?  haven't
used this much yet.)

  - ease of customization, given that it's written in everyone's
favorite interpreted language.

 unimplemented:

  - inhibiting idle suspend based on system or network load. 
i.e., the system will dim or suspend when watching a video. 
(there are hooks in place where these features should be
implemented -- they're just not coded at all.)  there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.

  - no special support for the wireless mesh, whatsoever.  i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out whether the mesh is active
or not.

  - there's some support for wake-on-wlan, but it's not well tested.

  finally a big one:
  - proper support for USB keyboards and mice.  i recently
realized that since olpc-kbdshim only monitors the built-in
keyboard and touchpad, powerd will think the user is idle
while they type on a USB keyboard, and cheerfully suspend
regardless.  (in my case, most of the time i want to
auto-suspend is when i'm running on battery, and not using
external devices, so i sort of forgot about this case.)

anyway, code is available here:
http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
http://dev.laptop.org/~pgf/rpms/

you'll need to install both olpc-kbdshim and olpc-powerd (in that
order).  when installed, olpc-powerd disables ohmd, and reenables
it when uninstalled.  (so it's relatively safe to try.)

there's no gui or other convenience for configuration --
see/etc/powerd/powerd.conf.  the installed defaults should be
reasonable.  and you'll need to run:
echo reconfig >/var/run/powerevents
after making changes to the config file.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] soc ideas

[vishak baby]

I saw this thing in the project ideas for soc, Sugar Toolbar submenu support
,could anyone elaborate on this thing?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS-2] Another Snapshot!

[Caroline Meeks]

I am getting a grey screen on the two computers I've tried it on.

On Fri, Mar 13, 2009 at 2:17 PM, Sebastian Dziallas wrote:

> Hi folks,
>
> there's another new - though, completely untested - snapshot of soas-2
> ready and waiting for you here:
>
> http://download.sugarlabs.org/soas/snapshots/2/Soas2-200903131725.iso
>
> A log file from the build process has been posted, too:
>
> http://shell.sugarlabs.org/sdz/soas2-20090313.log
>
> So what is new?
>
> * most activities have been updated to their latest version
> * sugar-update-control is now included - thanks to SMParrish
> * etoys, speak and read activity should now really be on it ;)
> * keyboard layout changes should be possible via system-config-keyboard
> * the soas version information has been incorporated correctly
>
> Concerning the last point: When booting the image, you should see a
> screen with the Fedora wallpaper for one second - press escape here and
> you should get to the boot menu, where you'll see the image's name.
>
> By the way, Fedora 11 (on which SoaS-2 is based) has entered beta
> freeze: So quite some packages won't be changing for now, but with the
> upcoming snapshots - as Rawhide progresses - it should stabilize more.
>
> Well, that's it so far. As always, please report any issues you
> encounter. Thanks and happy testing!
>
>--Your SoaS Team
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Olpc-open] justin.tv on the XO

[Sameer Verma]

On Fri, Mar 13, 2009 at 7:19 PM, Sameer Verma  wrote:
> On Wed, Feb 4, 2009 at 4:58 PM, Sameer Verma  wrote:
>> On Wed, Feb 4, 2009 at 8:12 AM, Luke Faraone  wrote:
>>> On Wed, Feb 4, 2009 at 10:59 AM, Brian Jordan  wrote:

 > Curious before I try it out...not sure if Browse will be allowed to
 > take over the camera and the mic.

 Whether this is even possible is another good question.
>>>
>>> It's worked for me in the past with older build versions, but I haven't
>>> tested it recently.
>>>
>>> --
>>> Luke Faraone
>>> http://luke.faraone.cc
>>>
>>
>> Was this in Browse, or the Firefox package? I'm assuming you had Adobe
>> Flash on it as well.
>>
>> Sameer
>>
>
>
>
> --
> Dr. Sameer Verma, Ph.D.
> Associate Professor of Information Systems
> San Francisco State University
> San Francisco CA 94132 USA
> http://verma.sfsu.edu/
> http://opensource.sfsu.edu/
>

So, I've managed to get justin.tv to work on DebXO (which by the way
is really well done!). I get to the broadcast page, click on allow in
the Flash widget (I've got flash from Adobe on it).

The broadcast works, video, and audio. The video has a pink hue
though, and it would be ok for Valentine's day, but not otherwise :-)

Justin.tv does pick up the video device as v4l2

Any ideas?

Of course, this would rock if we could do this via Browse and Gnash.

cheers,
Sameer
-- 
Dr. Sameer Verma, Ph.D.
Associate Professor of Information Systems
San Francisco State University
San Francisco CA 94132 USA
http://verma.sfsu.edu/
http://opensource.sfsu.edu/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Olpc-open] justin.tv on the XO

[Sameer Verma]

On Wed, Feb 4, 2009 at 4:58 PM, Sameer Verma  wrote:
> On Wed, Feb 4, 2009 at 8:12 AM, Luke Faraone  wrote:
>> On Wed, Feb 4, 2009 at 10:59 AM, Brian Jordan  wrote:
>>>
>>> > Curious before I try it out...not sure if Browse will be allowed to
>>> > take over the camera and the mic.
>>>
>>> Whether this is even possible is another good question.
>>
>> It's worked for me in the past with older build versions, but I haven't
>> tested it recently.
>>
>> --
>> Luke Faraone
>> http://luke.faraone.cc
>>
>
> Was this in Browse, or the Firefox package? I'm assuming you had Adobe
> Flash on it as well.
>
> Sameer
>



-- 
Dr. Sameer Verma, Ph.D.
Associate Professor of Information Systems
San Francisco State University
San Francisco CA 94132 USA
http://verma.sfsu.edu/
http://opensource.sfsu.edu/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)

[David Farning]

One project to look for on how to handle activity versions is eclipse.
 The notion of the eclipse plug-in ecosystem is virtually the same as
it is in Sugar Labs.

Eclipse has a few years of struggling with this issue under their belt.

http://www.eclipse.org/equinox/documents/plugin-versioning.html
http://wiki.eclipse.org/index.php/Version_Numbering

david

On Wed, Mar 11, 2009 at 12:34 PM, Wade Brainerd  wrote:
> On Wed, Mar 11, 2009 at 1:17 PM, Eben Eliason  wrote:
>> On Wed, Mar 11, 2009 at 1:05 PM, Wade Brainerd  wrote:
>>> On Wed, Mar 11, 2009 at 12:05 PM, Tomeu Vizoso  wrote:
 On Wed, Mar 11, 2009 at 17:00, Eben Eliason  wrote:
> Here is some (OK, a lot) of background reading on the subject.  I
> still cast my vote for a major/minor distinction, as mentioned in my
> response on the second thread below.
>
> http://www.mail-archive.com/de...@lists.laptop.org/msg11149.html
> http://www.mail-archive.com/su...@lists.laptop.org/msg03283.html

 That's also my favorite right now.
>>>
>>> I actually have the exact opposite instinct, coming at it from the
>>> user's perspective.  The best choice for *users* is to keep the
>>> linearly incrementing version, and document which activity versions
>>> work with which Sugar versions.  The activities.sugarlabs.org system
>>> already has an easy way to see what application versions an activity
>>> version works with.
>>>
>>> We should strive to ensure that newer versions of activities will work
>>> with older versions of Sugar or else fail gracefully.  Eben's idea to
>>
>> I think this might be a big assumption to make.  Sugar could include
>> new libraries at some point.  We could add additional classes and
>> controls to the toolkit.  There could be a fundamental change in the
>> protocol for some activity or service.  Obviously we'd prefer to keep
>> backward compatibility, but can we promise it always and indefinitely?
>>
>>> show activity startup failure information on the launcher screen would
>>> help a lot with the "fail gracefully" part.
>>
>> If we wait until activity launch to inform the user a particular
>> activity won't work for them, we'd better be quite certain that it's
>> easy to revert the update.
>>
>>> Being able to "branch" activities would perhaps help the Sugar
>>> development team.  But for the users, in this situation it would be
>>> best to make a new Terminal 25 that works with 0.86 and 0.84, and then
>>> update 0.84 to reference that.
>>>
>>> Think about it this way- someone with 0.84 can go *right now* and
>>> download Terminal v24 or later.  So why can't we just update 0.84 to
>>> reference Terminal v24+ if a bug is found in v23?
>>
>> This could be ideal if every newer version will always work with older
>> versions of Sugar. Consider, though, that some bugs might only exist
>> on older versions of Sugar.  Would we want to push an update to
>> everyone for this?
>>
>> Also, it still seems clearest to me to be able to make statements like
>> "versions 21–23 of Terminal work on 0.84 and version 24 works on 0.86"
>> (where versions have one or more implicit .x minor versions). With the
>> major-version-only approach (and assuming we don't have full backward
>> compatibility), we have to resort to statements like "versions 21–23
>> and also 25 work on 0.84, and versions 24 and 26 work on 0.86."
>>
>> - Eben
>>
>>
>>> Regards,
>>> Wade
>>>
>>
>
> Ultimately I think this all comes down to putting the responsibility
> for stability and compatibility on the developer instead of the user.
> As soon as we add those minor numbers, people's eyes will glaze over
> and the support emails will start rolling in :)
>
> If the Sugar developers are responsible about keeping the API
> compatible, and if Activity developers are responsible about
> responding to bug reports and maintaining compatibility, the situation
> you are describing will not happen.  Generally speaking we are talking
> about theoretical exceptions here anyway - I can't think of a
> situation where it's actually happened, except perhaps with Browse
> whose code I argue should be part of the Sugar toolkit anyway.
>
> Consider that some stupid DOS program I wrote back in 1995 still works
> just fine on the Windows 7 Beta - that's some impressive binary
> compatibility.  We don't have to go that far, we just have to maintain
> the DBus protocol for C (and eventually other) activities and the
> Sugar toolkit API for Python activities.
>
> -Wade
> ___
> 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] [SoaS-2] Another Snapshot!

[Sebastian Dziallas]

Hi folks,

there's another new - though, completely untested - snapshot of soas-2 
ready and waiting for you here:

http://download.sugarlabs.org/soas/snapshots/2/Soas2-200903131725.iso

A log file from the build process has been posted, too:

http://shell.sugarlabs.org/sdz/soas2-20090313.log

So what is new?

* most activities have been updated to their latest version
* sugar-update-control is now included - thanks to SMParrish
* etoys, speak and read activity should now really be on it ;)
* keyboard layout changes should be possible via system-config-keyboard
* the soas version information has been incorporated correctly

Concerning the last point: When booting the image, you should see a 
screen with the Fedora wallpaper for one second - press escape here and 
you should get to the boot menu, where you'll see the image's name.

By the way, Fedora 11 (on which SoaS-2 is based) has entered beta 
freeze: So quite some packages won't be changing for now, but with the 
upcoming snapshots - as Rawhide progresses - it should stabilize more.

Well, that's it so far. As always, please report any issues you 
encounter. Thanks and happy testing!

--Your SoaS Team
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] source code

[Simon Schampijer]

vishak baby wrote:
> Hi everyone,from where can I download the complete source code of sugar and
> all the sugar activities?

Either use git: http://git.sugarlabs.org or the tarballs: 
http://download.sugarlabs.org/sources/sucrose/

Regards,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] source code

[vishak baby]

Hi everyone,from where can I download the complete source code of sugar and
all the sugar activities?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Running sugar at almost-native speeds in Windows

[Ton van Overbeek]

On Thu, Mar 12, 2009 at 9:55 PM, S Page  wrote:
> On Thu, Mar 12, 2009 at 4:04 PM, Dave Bauer  wrote:
>>  I haven't found an easy way to get QEMU working with acceleration on OS X.
>
> QEMU on Windows is also confused, or I am.
>
> http://sugarlabs.org/go/Supported_systems/Windows still points to
> Wade's fine bundle and detailed steps from Ton van Overbeek  but both
> are to run OLPC 8.2.0 images which is old Sucrose.
>
> Meanwhile http://wiki.laptop.org/go/Emulating_the_XO/Quick_Start/Windows
> and its parent have lots of information about QEMU, but mostly
> out-of-date.
>
> I put today's SoaS2 ISO in my dusty old qemu 0.9.0 directory on
> Windows XP.  I think you use "-cdrom Soas2-200903121944.iso" to make
> it work.
>
> C:\Qemu> net start kqemu
>
> The KQEMU virtualisation module for QEMU service was started successfully.
>
> C:\Qemu>qemu.exe -L . -m 256 -kernel-kqemu -soundhw es1370 -net user
> -net nic,model=rtl8139 -cdrom Soas2-200903121944.iso
>
> Version mismatch between kqemu module and qemu (00010400 00010300) -
> disabling kqemu use
>
> Maybe that's why it's mind-blowingly slow to boot.
>

Note there is a break between qemu 0.9.1 and later w.r.t which kqemu
module to use.
See http://www.nongnu.org/qemu/download.html.
kqemu 1.3.0pre11 for qemu <= 0.9.1
kqemu 1.4.0pre1 for later (i.e. my private version and for 0.10.1)

>
> QEMU 0.10 is out, but the two Japanese URLs don't have Windows
> binaries.  Some random person at
> http://qemu-forum.ipi.fi/viewtopic.php?f=5&p=14435 has a Windows
> build, while a compatible kqemu accelerator is nowhere to be found.

I always had problem with -kernel-kqemu. Usually things work with only user
mode acceleration. I did try the 0.10 version you referenced with
Soas2-200903061846.iso,
but the boot only worked up to the start of X, then it crashed.
Have not tried the 20090312 version yet.

> There is a QEMU 0.9.1 Windows binary, I don't know if available kqemu
> works for it.
>
> Emulating OLPC OS Images with QEMU has been difficult on any platform
> ever since the 3DNow! extensions problem arose, I think that's why
> Wade and Ton van Overbeek made special binaries.  But maybe old
> versions of qemu/kqemu are fine for SoaS images.
>
>
>> I think we are working towards a solution, just not as quickly as we would
>> like.
> The story of the life since the Industrial Revolution ;-)
>
> Regards,
> --
> =S Page

I will be off-line till April 10 (holidays down-under), but then I should have a
shining new 17 inch MacBook Pro with VMWare Fusion, so I should be able
to try out both Windows and Mac versions.

Ton van Overbeek
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Google summer of Code?

[Jameson Quinn]

On Fri, Mar 13, 2009 at 7:24 AM, Benjamin M. Schwartz <
bmsch...@fas.harvard.edu> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jameson Quinn wrote:
> > Honestly, this is news to me. (and I am the co-administrator of the
> > Sugarlabs program). If I had to articulate my view of our priorities, it
> > would be something like the following:
> >
> > 7-10 points: Key sugar core improvements. Long-standing, important gaps
> like
> > versioning or unit-tests at the high end of this.
>
> As others have pointed out many times, the SoC projects that are least
> likely to produce useful results are the ones that are the most ambitious.
>  In particular, it is difficult to find SoC applicants who are ready to
> make deep modifications to an existing codebase, or will be able to
> architect complex software.  Remember, SoC applicants are mostly current
> undergrads, so most have never participated in multi-person development
> effort, or written anything larger than 1000 lines.


Agreed. However, I think that a relatively-skilled GSoC student could take
on one of the tasks I mentioned. Versioning could build on CScott's OLPCFS2,
which AFAIK works remarkably well; it really only needs an interface and
maybe a converter. Unit tests require a harness (and Sugarbot already
exists) and a couple of demo self-tests of the harness; the tests themselves
would be a separate story. Yet it is true, both of these would still be
ambitious, and would probably be scored down because of it.


>
>
> > 0-8 points: Proposal quality.
>
> Maybe this problem is wrapped up in "Proposal quality".  If I were
> designing a system to reflect my own internal judgment structure, I would
> probably add another /multiplying/ factor, the estimated probability of
> success (although I hope we can do selection without resorting to
> numerical scores.)


I agree. The numbers are only a way of communicating, not a proposed system
for choosing.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Google summer of Code?

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jameson Quinn wrote:
> Honestly, this is news to me. (and I am the co-administrator of the
> Sugarlabs program). If I had to articulate my view of our priorities, it
> would be something like the following:
> 
> 7-10 points: Key sugar core improvements. Long-standing, important gaps like
> versioning or unit-tests at the high end of this.

As others have pointed out many times, the SoC projects that are least
likely to produce useful results are the ones that are the most ambitious.
 In particular, it is difficult to find SoC applicants who are ready to
make deep modifications to an existing codebase, or will be able to
architect complex software.  Remember, SoC applicants are mostly current
undergrads, so most have never participated in multi-person development
effort, or written anything larger than 1000 lines.

> 0-8 points: Proposal quality.

Maybe this problem is wrapped up in "Proposal quality".  If I were
designing a system to reflect my own internal judgment structure, I would
probably add another /multiplying/ factor, the estimated probability of
success (although I hope we can do selection without resorting to
numerical scores.)

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkm6XnQACgkQUJT6e6HFtqSlrACgjuswY+/aYXWkfaTY3DZcls/l
gLcAnRP4Rn7tGfuQoiipzFtXQfEHP1g4
=Z92W
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Running sugar at almost-native speeds in Windows

[Bert Freudenberg]

On 12.03.2009, at 21:12, Dave Bauer wrote:

> Ok, I was able to take the Virtualbox VM and conver it to run in  
> Parallels, but its not easy and you definitely need to install the  
> Parallels Tools. I also have created a new Parallels native VM based  
> on SoaS slightly modifying the instructions to build the VM on  
> Virtualbox.


Great that you got it to work in Parallels!

I switched to VMWare Fusion a while ago, it has much better support  
for "not officially supported" Linux distributions. Like, whenever a  
new X server comes out, Parallels needs a year to get their display  
driver updated (and if you are unlucky like me you would have to pay  
again for an upgrade to get it). With VMware I just recompiled the  
driver and was done.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SugarBot in 2009

[Walter Bender]

On Thu, Mar 12, 2009 at 6:03 PM, Zach Riggle  wrote:
> Since XP was selected over Sugar as the standard environment for OLPC, I
> have not picked up development of SugarBot to integrate it with the
> sugar-jhbuild process.

AFAIK, not a single XP machine has been shipped by OLPC. They continue
to ship Fedora/Sugar. Maybe that will change sometime in the future,
but for now, hey are still shipping GNU/Linux.

Meanwhile, Sugar is branching out to many more environments. It has
not been exclusively an OLPC effort for almost 1 year now.

> If somebody else has interest in taking over the project, I would be glad to
> help :-)
>

thanks for offering to help.

-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] Google summer of Code?

[Jameson Quinn]

On Fri, Mar 13, 2009 at 1:56 AM, Mel Chua  wrote:

>
> 2009/3/8 Jameson Quinn :
>> > No definite agreement has been made, but in preliminary chats, it seems
>> > that both organizations agree that anything for XS or specific to XO
>> hardware
>> > should go in OLPC, and everything else (general Sugar improvements,
>> > frameworks, or activities) should go in Sugarlabs.
>>
>> We discussed this at XO camp, and people from Sugar Labs were
>> considering not supporting activity development and focusing on core
>> sugar development.
>
>
> This is correct.
>
>
>> Has this changed? In general, do you expect that
>> priorities for toolchain and activity development will be the same?
>
>
> In general, sugar-core and toolchain development is a higher priority than
> generative Activity development (Activities that lower the barrier to
> Activity development). It's highly unlikely that non-generative Activity
> development will be supported.
>

Honestly, this is news to me. (and I am the co-administrator of the
Sugarlabs program). If I had to articulate my view of our priorities, it
would be something like the following:

7-10 points: Key sugar core improvements. Long-standing, important gaps like
versioning or unit-tests at the high end of this.
6-9 points: Activity frameworks to open new forms of activity development
(in descending priority: javascript/AJAX, swf, improved PyGTK tools such as
Develop activity, mono or java)
4-8 points: Core activities: For instance, Nepal has expressed the need for
an improved Read.
3-6 points: Quality non-core educational activities: a physics sim or other
creative idea.
0-8 points: Proposal quality.

In other words, an excellent proposal from a highly-qualified student could
very well make the cut, even if it were a non-core activity.

Jameson (whose daughter likes colors)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SugarBot in 2009

[Zach Riggle]

Since XP was selected over Sugar as the standard environment for OLPC, I
have not picked up development of SugarBot to integrate it with the
sugar-jhbuild process.

If somebody else has interest in taking over the project, I would be glad to
help :-)

On Thu, Mar 12, 2009 at 1:18 PM, Simon Schampijer wrote:

> Hi,
>
> we lost somehow track in integrating SugarBot [1] the last time. It looks
> quite promising and ready though:
>
> http://code.google.com/p/sugarbot/wiki/RunningSugar
>
> Is there someone interested in taking this on?
>
> Zach, anything you see that would block these efforts?
>
> Regards,
>   Simon
>
> [1] sugarbot is a GUI automation utility for the OLPC Project's Sugar GUI.
> It provides functionality for developers to write tests for their
> Activities, and monitor those tests in a similar manner to unit-tests.
> sugarbot supports buildbot, so that multiple platforms and host
> configurations may be tested seamlessly.
>



-- 
Zach Riggle
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Google summer of Code?

[Mel Chua]

> 2009/3/8 Jameson Quinn :
> > No definite agreement has been made, but in preliminary chats, it seems
> > that both organizations agree that anything for XS or specific to XO
> hardware
> > should go in OLPC, and everything else (general Sugar improvements,
> > frameworks, or activities) should go in Sugarlabs.
>
> We discussed this at XO camp, and people from Sugar Labs were
> considering not supporting activity development and focusing on core
> sugar development.


This is correct.


> Has this changed? In general, do you expect that
> priorities for toolchain and activity development will be the same?


In general, sugar-core and toolchain development is a higher priority than
generative Activity development (Activities that lower the barrier to
Activity development). It's highly unlikely that non-generative Activity
development will be supported.


> I expect that many activity development and student projects
> interested in working with current schools will apply for both OLPC
> and Sugar Labs projects; they are welcome to apply to both, and those
> doing work relevant to Sugar should be encouraged to!  Applying to
> multiple GSOC groups is standard practice; students do not need to
> choose.  We had a couple of students last year who ended up working on
> OLPC related projects for other orgs.


Yup, I remember that. :) We talked with Cjb about shuttling relevant apps
back and forth as needed - what we're doing right now is setting up
guidelines that will hopefully minimize the amount of sorting that's needed,
then waiting for students to come in, then sorting. Double-apping is not a
problem.

--Mel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel