[Sugar-devel] Fwd: Requesting review for Sugar-gsoc application "Marbles"

[Puneet Girdhar]

-- Forwarded message --
From: Puneet Girdhar 
Date: Fri, Apr 10, 2009 at 10:16 PM
Subject: Requesting review for Sugar-gsoc application "Marbles"
To: "Google Summer of Code @ Sugarlabs list" 
Cc: Jameson Quinn 


Hi all,
   After Jameson encouraging support, I think I should discuss my
proposal "Marbles" with you all once again.

*Marbles*
  Marbles aim to build a UI Designer/Creator tool for sugar . The Tool
would allow users to drag and drop widgets. Edit the widgets and their
properties and also to create custom widgets. The Tool can also be used to
connect actions to various signals from the user via the UI and will finally
generate code which can be run directly. It can be written either in Wx or
Qt making it platform independent. And the generation of code can also made
to work on any platform. In short, it would be a stripped down but effective
version of Glade ported to sugar.


*Design Approach*
It's a UI builder tool for creating UI applications. Detailed discussion
on this can be found at
http://wiki.sugarlabs.org/go/Marbles#Basic_Design_Principles.
I have also considered to use existed UI builder for sugar . Here are my
results/findings
http://socghop.appspot.com/document/show/user/chasedspeed/marbles.

*Benefits*
 1. Promote healthy brain development
 2. Preparing young children for digital programming enviroment.
 3. Boost child learning process and success.
 4. Support for developers for future advancements ( like addition of
widgets, events etc. )

Sugar Wiki-Link : http://wiki.sugarlabs.org/go/Marbles

Once again, Thank you jameson for bringing my proposal to review. I would
like to request all community members to go to the sugar-wiki page and give
valuable comments/ suggestions . Your feedback will help me to remain
positive.

Thanks,
Puneet




-- 
Puneet Girdhar
BTECH CSE ( IIIrd Year )
IIIT Hyderabad
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Labyrinth-5

[Gary C Martin]

Hi Michael,

On 11 Apr 2009, at 06:48, Michael Stone wrote:

>> P.S. One notable bug for XO 8.2 distro users, is that adding images
>> from the Journal is currently broken (bumping into rainbow), adding
>> images works fine on sugar-jhbuild and should be fine on Soas distros
>> and xo-rawhide (though I haven't tested there just yet).
>
> Gary,
>
> Could you please send me a link to a ticket with logs?

Sorry if I wasn't clear, it's not a Rainbow bug, but an issue I need  
to fix in Labyrinth. I had a few early passes at fixing Journal image  
import integration but not quite there yet. Basically the issue is  
that Labyrinths image loading code is buried deep down in multiple  
levels of class and/or Python modules, so I don't have obvious access  
to the various Activity name spaces for knowing where is safe to save.

Line 51 if you want a quick peek:

http://git.sugarlabs.org/projects/labyrinth/repos/mainline/blobs/master/src/ImageThought.py

Let me take another shot (might have some time on Sunday), alsroot  
made some changes here after my initial attempts, but I think he was  
fixing something else, need to catch up with what he was after.

Regards,
--Gary

> Thanks,
>
> Michael

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

Re: [Sugar-devel] Fwd: Requesting review for Sugar-gsoc application "Marbles"

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Apr 11, 2009 at 01:24:21PM +0530, Puneet Girdhar wrote:
>*Marbles*
>  Marbles aim to build a UI Designer/Creator tool for sugar . The 
>Tool would allow users to drag and drop widgets. Edit the widgets and 
>their properties and also to create custom widgets. The Tool can also 
>be used to connect actions to various signals from the user via the UI 
>and will finally generate code which can be run directly. It can be 
>written either in Wx or Qt making it platform independent. And the 
>generation of code can also made to work on any platform. In short, it 
>would be a stripped down but effective version of Glade ported to 
>sugar.

Sounds interesting.

Most current use of Sugar is on size-constrained machines (the OLPC 
XOs).  It would help if, in addition to Qr and Wx, your tool could be 
made to generate GTK code, as that is the framework currently used for 
most of Sugar (and, I believe, the only generic framework currently 
used: those not using that framework use something non-generic).


Kind regards,

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkngXO4ACgkQn7DbMsAkQLgVuQCfSxTtZVZcAjLjIWlqwTNLiaqn
xzMAnixTUU0XBx/RK9GjK0ZllDbutFu7
=YcBK
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sound in SoaS

[Bert Freudenberg]

On 11.04.2009, at 11:38, Caroline Meeks wrote:

The SoaS-Beta that came out on Thursday afternoon had some sound  
fixes.



AFAIK it only added the missing gst-speech plugin for Speak, no? Any  
other changes? Too bad there is no change log.


- Bert -


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

Re: [Sugar-devel] Sound in SoaS

[Elena of Valhalla]

On Sat, Apr 11, 2009 at 11:54 AM, Bert Freudenberg  wrote:
> AFAIK it only added the missing gst-speech plugin for Speak, no? Any other
> changes? Too bad there is no change log.

speak is working for me with the latest beta (tested on eee only), but
I couldn't manage to test any other activity

-- 
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valha...@gmail.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Labyrinth-5

[Aleksey Lim]

On Sat, Apr 11, 2009 at 09:44:33AM +0100, Gary C Martin wrote:
> Hi Michael,
> 
> On 11 Apr 2009, at 06:48, Michael Stone wrote:
> 
> >> P.S. One notable bug for XO 8.2 distro users, is that adding images
> >> from the Journal is currently broken (bumping into rainbow), adding
> >> images works fine on sugar-jhbuild and should be fine on Soas distros
> >> and xo-rawhide (though I haven't tested there just yet).
> >
> > Gary,
> >
> > Could you please send me a link to a ticket with logs?
> 
> Sorry if I wasn't clear, it's not a Rainbow bug, but an issue I need  
> to fix in Labyrinth. I had a few early passes at fixing Journal image  
> import integration but not quite there yet. Basically the issue is  
> that Labyrinths image loading code is buried deep down in multiple  
> levels of class and/or Python modules, so I don't have obvious access  
> to the various Activity name spaces for knowing where is safe to save.
> 
> Line 51 if you want a quick peek:
>   
> http://git.sugarlabs.org/projects/labyrinth/repos/mainline/blobs/master/src/ImageThought.py

looks like rainbow prevents activity to save files to its(activity) own
instance directory: os.path.join(get_activity_root(), 'tmp'...

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

Re: [Sugar-devel] GSoC Proposal: Multimedia Broadcasting

[Martin Langhoff]

On Sat, Apr 11, 2009 at 1:37 AM, Geza Kovacs  wrote:
> According to http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4292735
> then the slowest transmission speed, Mode1 (6 Mbps) is only beneficial
> for multicasting over very large distances; in the case of the AWGN

I am sure they did their tests in quiet RF environments. In crowded
environments nodes can tell the AP that they're having trouble hearing
the frames, please transmit slower.

You've calculated 1.6Mbps but that's only the stream. You need to get
each to the AP, and _then_ it'll be broadcast. The frame to the AP may
be transmittedfast if the XO is close to the AP. The datarate for the
broadcast frame from the AP to all the nodes is set by the AP based on
the nodes it has registered...

> In terms of airtime consumption, this of course depends on the
> airtime-fairness mechanisms used by the wireless network. However,

Which just don't exist (not in the QoS sense that you seem to be
picturing at least), and deal rather badly with dense networks. There
is a backoff mechanism that avoids collisions (rather than detect
them) ... in very dense environment this means that the available
bandwidth is significantly reduced.

The tools that you want to reuse work well in a switched network with
ample capacity. The workload of video streaming -- however "light" you
might thing 1.6Mbps is -- in a saturated shared medium with "slowest
client sets the speed" broadcast and conservative backoff strategies
is AFAIK an unsolved problem.

There's surely a complex research project there -- can it be made to
work? What strategies can work on that complex problem? But if you
start by assuming you can reuse existing high level tools, it'll be a
disaster. It might work in a test environment. But it will never ever
work in a real life school.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sound in SoaS

[Aleksey Lim]

On Sat, Apr 11, 2009 at 11:54:25AM +0200, Bert Freudenberg wrote:
> On 11.04.2009, at 11:38, Caroline Meeks wrote:
>
>> The SoaS-Beta that came out on Thursday afternoon had some sound  
>> fixes.
>
>
> AFAIK it only added the missing gst-speech plugin for Speak, no? Any  
> other changes? Too bad there is no change log.

from Soas2-200904021455.iso soas has pulse installed by default, so
sound should work in Etoys, could you test soas-2 last image from
http://download.sugarlabs.org/soas/releases/soas-beta.iso

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

Re: [Sugar-devel] [RELEASE] Labyrinth-5

[Aleksey Lim]

On Sat, Apr 11, 2009 at 10:33:06AM +, Aleksey Lim wrote:
> On Sat, Apr 11, 2009 at 09:44:33AM +0100, Gary C Martin wrote:
> > Hi Michael,
> > 
> > On 11 Apr 2009, at 06:48, Michael Stone wrote:
> > 
> > >> P.S. One notable bug for XO 8.2 distro users, is that adding images
> > >> from the Journal is currently broken (bumping into rainbow), adding
> > >> images works fine on sugar-jhbuild and should be fine on Soas distros
> > >> and xo-rawhide (though I haven't tested there just yet).
> > >
> > > Gary,
> > >
> > > Could you please send me a link to a ticket with logs?
> > 
> > Sorry if I wasn't clear, it's not a Rainbow bug, but an issue I need  
> > to fix in Labyrinth. I had a few early passes at fixing Journal image  
> > import integration but not quite there yet. Basically the issue is  
> > that Labyrinths image loading code is buried deep down in multiple  
> > levels of class and/or Python modules, so I don't have obvious access  
> > to the various Activity name spaces for knowing where is safe to save.
> > 
> > Line 51 if you want a quick peek:
> > 
> > http://git.sugarlabs.org/projects/labyrinth/repos/mainline/blobs/master/src/ImageThought.py
> 
> looks like rainbow prevents activity to save files to its(activity) own
> instance directory: os.path.join(get_activity_root(), 'tmp'...

(just a joke)

In my mind using rainbow is like using cannons to shot sparrows
more relevant weapon is http://en.wikipedia.org/wiki/Slingshot :D

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

Re: [Sugar-devel] Fwd: Requesting review for Sugar-gsoc application "Marbles"

[Puneet Girdhar]

Hi Jonas,

   I agree, It should be extended to GTK too, since it's a live face for
sugar or we can use  QT+GTK support to make it real platform independent &
rich functionality with QT widget styles on GTK  ( just idea ) .

 For GSOC proposal, you can find a small discussion of GTK support for
Marbles in my proposal here
http://wiki.sugarlabs.org/go/Marbles#Basic_Design_Principles.

Thank you for your support,

Puneet.


On Sat, Apr 11, 2009 at 2:33 PM, Jonas Smedegaard  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Apr 11, 2009 at 01:24:21PM +0530, Puneet Girdhar wrote:
> >*Marbles*
> >  Marbles aim to build a UI Designer/Creator tool for sugar . The
> >Tool would allow users to drag and drop widgets. Edit the widgets and
> >their properties and also to create custom widgets. The Tool can also
> >be used to connect actions to various signals from the user via the UI
> >and will finally generate code which can be run directly. It can be
> >written either in Wx or Qt making it platform independent. And the
> >generation of code can also made to work on any platform. In short, it
> >would be a stripped down but effective version of Glade ported to
> >sugar.
>
> Sounds interesting.
>
> Most current use of Sugar is on size-constrained machines (the OLPC
> XOs).  It would help if, in addition to Qr and Wx, your tool could be
> made to generate GTK code, as that is the framework currently used for
> most of Sugar (and, I believe, the only generic framework currently
> used: those not using that framework use something non-generic).
>
>
> Kind regards,
>
>  - Jonas
>
> - --
> * Jonas Smedegaard - idealist og Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkngXO4ACgkQn7DbMsAkQLgVuQCfSxTtZVZcAjLjIWlqwTNLiaqn
> xzMAnixTUU0XBx/RK9GjK0ZllDbutFu7
> =YcBK
> -END PGP SIGNATURE-
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Puneet Girdhar
BTECH CSE ( IIIrd Year )
IIIT Hyderabad
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Unified Objects (was Unified bundles)

[Aleksey Lim]

On Thu, Apr 09, 2009 at 03:30:00AM -0400, Michael Stone wrote:
> 
> Now here's a mess of ideas from which these three basic intuitions originate:
> 
> 1. It would be nice to be able to generate various views of "what the user can
> do" with shell globs rather than by writing complicated queries over in-memory
> data-structures that have to be fully loaded and locked into RAM before you 
> can
> render anything...
> 
> 2. Activities need to expose their API to the shell. In particular, we /need/
> to be able to get an activity to self-test a system for deps, to run
> non-graphical tests, to run graphical tests, to run network tests, to run a
> demo or tutorial of itself, to show its source, ...
> 
> 3. One interesting way to think about (1) and (2), which I have previously
> discussed with Eben, is in the context of the Plan 9 plumber. Go read about 
> it.

But it means adding p9 kernel module of FUSE to SugarPlatform
dependencies - a bit overmuch for "to try sugar just install it in your
favourite distro"

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

Re: [Sugar-devel] Sound in SoaS

[Bert Freudenberg]

On 11.04.2009, at 12:46, Aleksey Lim wrote:

> On Sat, Apr 11, 2009 at 11:54:25AM +0200, Bert Freudenberg wrote:
>> On 11.04.2009, at 11:38, Caroline Meeks wrote:
>>
>>> The SoaS-Beta that came out on Thursday afternoon had some sound
>>> fixes.
>>
>>
>> AFAIK it only added the missing gst-speech plugin for Speak, no? Any
>> other changes? Too bad there is no change log.
>
> from Soas2-200904021455.iso soas has pulse installed by default, so
> sound should work in Etoys, could you test soas-2 last image from
> http://download.sugarlabs.org/soas/releases/soas-beta.iso


Meh. What happened to version numbers? I take it it's not the same  
file as the "soas-beta.iso" from 3 days ago.

- Bert -


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

Re: [Sugar-devel] Turtle Art in sugar-jhbuild--defaults to Spanish

[Walter Bender]

Are you running it from outside of Sugar? If so, you should try
pullling the most recent version from git, which should default to
your default locale. I've never seen the failure you have described
from within Sugar. From within Sugar, the relevant code is:

lang = locale.getdefaultlocale()[0]
if not lang:
lang = 'en'

-walter

On Fri, Apr 10, 2009 at 7:34 PM, Edward Cherlin  wrote:
> Why does TurtleArt in sugar-jhbuild default to Spanish? How do I
> change the language for TurtleArt?
>
> I have found the language-specific files in images, locale, and
> samples, and the place in turtleart.py that says to use the .es file,
> but there must be some other place that specifies Spanish, because
> changing .es to .en and copying the po.en file over the po.es file
> don't give me English.
>
> --
> Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
> And Children are my nation.
> The Cosmos is my dwelling place, The Truth my destination.
> http://earthtreasury.org/worknet (Edward Mokurai Cherlin)
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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

Re: [Sugar-devel] Fwd: Requesting review for Sugar-gsoc application "Marbles"

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Apr 11, 2009 at 04:30:47PM +0530, Puneet Girdhar wrote:
>   I agree, It should be extended to GTK too, since it's a live face 
>for sugar or we can use QT+GTK support to make it real platform 
>independent & rich functionality with QT widget styles on GTK ( just 
>idea ) .

Using Qt+GTK sounds platform independent, yes, but Sugar is not platform 
independent anyway, it is tied to Linux+Python+DBus+GTK, and from a 
Sugar point of view requiring Qt (isn't Qt+GTK a GTK wrapper around Qt?) 
is bloat.  It might integrate well, but consumes space and memory.


> For GSOC proposal, you can find a small discussion of GTK support for
>Marbles in my proposal here
>http://wiki.sugarlabs.org/go/Marbles#Basic_Design_Principles.

I only skimmed that page (my strength is in software packaging, not in 
developing software) but it seems you do not talk about Qt there, only 
PyGTK.



Kind regards,

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkngmhcACgkQn7DbMsAkQLgL+gCeKjK22ufUic/l78pNJ8GAGZPX
UGgAn3WRq7SiJCPZWNrKRIYUzQbjMGLS
=JTGj
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Labyrinth-5

[Wade Brainerd]

On Sat, Apr 11, 2009 at 4:44 AM, Gary C Martin  wrote:
> Hi Michael,
>
> On 11 Apr 2009, at 06:48, Michael Stone wrote:
>
>>> P.S. One notable bug for XO 8.2 distro users, is that adding images
>>> from the Journal is currently broken (bumping into rainbow), adding
>>> images works fine on sugar-jhbuild and should be fine on Soas distros
>>> and xo-rawhide (though I haven't tested there just yet).
>>
>> Gary,
>>
>> Could you please send me a link to a ticket with logs?
>
> Sorry if I wasn't clear, it's not a Rainbow bug, but an issue I need
> to fix in Labyrinth. I had a few early passes at fixing Journal image
> import integration but not quite there yet. Basically the issue is
> that Labyrinths image loading code is buried deep down in multiple
> levels of class and/or Python modules, so I don't have obvious access
> to the various Activity name spaces for knowing where is safe to save.
>
> Line 51 if you want a quick peek:
>        
> http://git.sugarlabs.org/projects/labyrinth/repos/mainline/blobs/master/src/ImageThought.py
>
> Let me take another shot (might have some time on Sunday), alsroot
> made some changes here after my initial attempts, but I think he was
> fixing something else, need to catch up with what he was after.

A strategy that has worked for me in the past is to chdir to the right
directory in the activity module startup.  That way you don't have to
import sugar modules into low level source code.

Another way to deal with it is to use the environment variables
instead of the sugar APIs, and just test for the presence of the
environment variables before using them.

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

[Sugar-devel] [SoaS] Progress on the Virtual Appliance

[Sebastian Dziallas]

Hi folks,

I'm happy to report some progress over the weekend on the SoaS 
appliance. Finally, it turned out that some live media bits were 
accidentally included in the recent builds, which caused them not to 
boot. This has been fixed and I can confirm it now to boot into Sugar 
here. It's probably alpha quality right now and contains quite some issues:

* It runs firstboot when you start it for the first time. maybe we can 
circumvent this? If not, we need a skin for firstboot.

* We can automatically download activities from a.sl.o and include them, 
but they won't appear, as we can't link them to the /home directory, 
because that get's created in firstboot.

* The current version does NOT work in VMware Fusion. This is a known 
issue and will be fixed once we resume building.

So, please note: I just built this over the weekend to sort this out. 
You can grab it nevertheless, but I wouldn't expect it to be around much 
long after newer snapshots appeared on dl.sl.o.

Here's the link: http://people.sugarlabs.org/sdz/soas2-20090411.tar.gz

Thanks to all those who continuously tried the images!

To those who celebrate it, happy Easter!

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

Re: [Sugar-devel] [SoaS] Progress on the Virtual Appliance

[Dave Bauer]

On Sat, Apr 11, 2009 at 12:13 PM, Sebastian Dziallas wrote:

> Hi folks,
>
> I'm happy to report some progress over the weekend on the SoaS
> appliance. Finally, it turned out that some live media bits were
> accidentally included in the recent builds, which caused them not to
> boot. This has been fixed and I can confirm it now to boot into Sugar
> here. It's probably alpha quality right now and contains quite some issues:
>
> * It runs firstboot when you start it for the first time. maybe we can
> circumvent this? If not, we need a skin for firstboot.
>
> * We can automatically download activities from a.sl.o and include them,
> but they won't appear, as we can't link them to the /home directory,
> because that get's created in firstboot.
>
> * The current version does NOT work in VMware Fusion. This is a known
> issue and will be fixed once we resume building.
>
> So, please note: I just built this over the weekend to sort this out.
> You can grab it nevertheless, but I wouldn't expect it to be around much
> long after newer snapshots appeared on dl.sl.o.
>
> Here's the link: http://people.sugarlabs.org/sdz/soas2-20090411.tar.gz
>
> Thanks to all those who continuously tried the images!
>
> To those who celebrate it, happy Easter!
>

Thanks, this is great news! Does the appliance include vmware tools?

Dave


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



-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Progress on the Virtual Appliance

[Sebastian Dziallas]

Dave Bauer wrote:
> On Sat, Apr 11, 2009 at 12:13 PM, Sebastian Dziallas  <mailto:sebast...@when.com>> wrote:
> 
> Hi folks,
> 
> I'm happy to report some progress over the weekend on the SoaS
> appliance. Finally, it turned out that some live media bits were
> accidentally included in the recent builds, which caused them not to
> boot. This has been fixed and I can confirm it now to boot into Sugar
> here. It's probably alpha quality right now and contains quite some
> issues:
> 
> * It runs firstboot when you start it for the first time. maybe we can
> circumvent this? If not, we need a skin for firstboot.
> 
> * We can automatically download activities from a.sl.o and include them,
> but they won't appear, as we can't link them to the /home directory,
> because that get's created in firstboot.
> 
> * The current version does NOT work in VMware Fusion. This is a known
> issue and will be fixed once we resume building.
> 
> So, please note: I just built this over the weekend to sort this out.
> You can grab it nevertheless, but I wouldn't expect it to be around much
> long after newer snapshots appeared on dl.sl.o.
> 
> Here's the link: http://people.sugarlabs.org/sdz/soas2-20090411.tar.gz
> 
> Thanks to all those who continuously tried the images!
> 
> To those who celebrate it, happy Easter!
> 
> 
> Thanks, this is great news! Does the appliance include vmware tools?
> 
> Dave

Actually not. Well, I've lost track of the vmware-tools development, but 
  it seems like they've recently open-sourced them. Downside is that 
those won't get in Fedora: 
https://bugzilla.redhat.com/show_bug.cgi?id=294341

http://open-vm-tools.wiki.sourceforge.net/Distro+Package+Status

We could get it from RPM Fusion, though:

http://download1.rpmfusion.org/free/fedora/development/i386/os/repoview/open-vm-tools.html

The biggest problem would be that this requires the installation of 
additional kernel modules and - which could be imo a blocker - that 
VMware Fusion for the Mac is NOT free.

So we might want to consider VirtualBox as a (better) alternative, as 
this is free for Linux, Mac and Windows. But for that, we don't have any 
RPM for the additions around, so this would need to be packaged first.

And I don't know about:

* the license; so I'm not even sure if we'd be allowed to package and 
redistribute them (it sounds like you'd only get the permission to 
distribute an ISO or to include the stuff at build time, but IANAL!).

* how to package it, as we'd probably need additional kernel modules 
(which are - afaik - not permitted in Fedora and would go in some 
third-party repository like RPM Fusion then) and other stuff.

So this sounds all a bit complicated...

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

Re: [Sugar-devel] [SoaS] Progress on the Virtual Appliance

[Luke Faraone]

On Sat, Apr 11, 2009 at 12:42 PM, Sebastian Dziallas wrote:

> * the license; so I'm not even sure if we'd be allowed to package and
> redistribute them (it sounds like you'd only get the permission to
> distribute an ISO or to include the stuff at build time, but IANAL!).
>
> * how to package it, as we'd probably need additional kernel modules
> (which are - afaik - not permitted in Fedora and would go in some
> third-party repository like RPM Fusion then) and other stuff.
>

What's stopping us from adding it to our own repo? The source is available
and GPL'd, it's just the sun bins that are PUELed. Worst case we can simply
have it run the installer in the final section of the building, as we don't
*need* it packaged.


-- 
Luke Faraone
http://luke.faraone.cc
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GSoC Proposal: Multimedia Broadcasting

[Geza Kovacs]

Since you apparently have more experience with multicasting over
wireless I'll assume it's not a realistic option in this context
(though it might nevertheless be an interesting experiment to try if
have spare time over the course of GSoC after finishing a
unicast-based implementation).

Returning to unicasting and simply limiting net bandwidth usage, as I
understand the "slowest client sets the speed" issue with the access
node switching to Mode1 for broadcast applies only to multicasting. If
I have the XO send the video in a single UDP stream to the central XS
server (which as I understand has a wired connection to the AP), then
have those streams be individually relayed by the XS over the AP to
each designated viewer in over unicast UDP, then as I understand the
AP will be able to operate near its 56 Mbps net throughput limit,
which, factoring in the fact that the effective throughput will be
decreased due to noise and that my application of course can't hog all
the bandwidth and airtime, means that I will have around 20 Mbps
available for unicasting to all clients.

Rather than limiting the number of viewers as I originally proposed, I
believe that automatically limiting the framerate of the broadcast
based on the number of viewers will be a better way to scale for
larger numbers of viewers - that is, once the broadcaster gets to the
"broadcast" stage and selects the intended viewers, then based on the
available bandwidth and network congestion, then an ideal framerate is
calculated out and the stream is encoded and broadcast to all of the
viewers at that framerate. Given that the most interest has been
expressed over the remote desktop broadcasting feature, and given that
there's rather little motion overall on a desktop broadcast, the
desktop activity should still be easily viewed at very low framerates.
>From my personal experience, I don't really miss any features of my
own typical desktop activity even at around 3-4 fps (except for
gaming, but presumably this will be used primarily for relatively
low-motion educational software). At 4 fps, the MJPEG video stream,
with a 96 Kbps audio stream, comes out at around 0.5 Mbps. Using 20
Mbps, this stream could be broadcast to 40 users, which I assume is
around the upper limit of the number of students in the classroom.
Assuming fewer viewers, then higher framerates could be used. Would
this be a reasonable approach to limiting airtime usage with unicast
streams?

On Sat, Apr 11, 2009 at 6:36 AM, Martin Langhoff
 wrote:
> On Sat, Apr 11, 2009 at 1:37 AM, Geza Kovacs  wrote:
>> According to http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4292735
>> then the slowest transmission speed, Mode1 (6 Mbps) is only beneficial
>> for multicasting over very large distances; in the case of the AWGN
>
> I am sure they did their tests in quiet RF environments. In crowded
> environments nodes can tell the AP that they're having trouble hearing
> the frames, please transmit slower.
>
> You've calculated 1.6Mbps but that's only the stream. You need to get
> each to the AP, and _then_ it'll be broadcast. The frame to the AP may
> be transmittedfast if the XO is close to the AP. The datarate for the
> broadcast frame from the AP to all the nodes is set by the AP based on
> the nodes it has registered...
>
>> In terms of airtime consumption, this of course depends on the
>> airtime-fairness mechanisms used by the wireless network. However,
>
> Which just don't exist (not in the QoS sense that you seem to be
> picturing at least), and deal rather badly with dense networks. There
> is a backoff mechanism that avoids collisions (rather than detect
> them) ... in very dense environment this means that the available
> bandwidth is significantly reduced.
>
> The tools that you want to reuse work well in a switched network with
> ample capacity. The workload of video streaming -- however "light" you
> might thing 1.6Mbps is -- in a saturated shared medium with "slowest
> client sets the speed" broadcast and conservative backoff strategies
> is AFAIK an unsolved problem.
>
> There's surely a complex research project there -- can it be made to
> work? What strategies can work on that complex problem? But if you
> start by assuming you can reuse existing high level tools, it'll be a
> disaster. It might work in a test environment. But it will never ever
> work in a real life school.
>
> cheers,
>
>
>
> m
> --
>  martin.langh...@gmail.com
>  mar...@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GSoC Proposal: Multimedia Broadcasting

[Carol Farlow Lerche]

It seems like this conversation is somewhat at cross-purposes.  Martin
discusses the general case of multicast from an arbitrary client through an
access point serving many clients with a mixture of multicast and unicast
traffic.  Well known performance problems result.  However, Geza proposes a
special case (perhaps).  In a classroom, it would be nice to be able to have
a "projector" to send a stream of video to the stations within that
classroom.  Now, not every school could have extra hardware for this
purpose, but I think many could, just as our schools of yore had that funky
projector that got rolled into the classroom on the morning when our teacher
wanted us to see (or sleep through :-) a movie about something or other.

What might be interesting is to consider the possibiliity of connecting the
projector client via a USB ethernet connector to a separate "multicast"
access point, that the receiving clients associated with for the time of the
"movie".  This allows the originator of the stream to use a wired connection
to the AP, the AP to be chosen and configured to optimize multicasting, and
the whole thing to be somewhat isolated from the unicast traffic happening
elsewhere.

Not sure if this is workable, but some reading of the papers about multicast
performance issues on the Intertubes suggest it might be promising.

On Sat, Apr 11, 2009 at 3:07 PM, Geza Kovacs  wrote:

> Since you apparently have more experience with multicasting over
> wireless I'll assume it's not a realistic option in this context
> (though it might nevertheless be an interesting experiment to try if
> have spare time over the course of GSoC after finishing a
> unicast-based implementation).
>
> Returning to unicasting and simply limiting net bandwidth usage, as I
> understand the "slowest client sets the speed" issue with the access
> node switching to Mode1 for broadcast applies only to multicasting. If
> I have the XO send the video in a single UDP stream to the central XS
> server (which as I understand has a wired connection to the AP), then
> have those streams be individually relayed by the XS over the AP to
> each designated viewer in over unicast UDP, then as I understand the
> AP will be able to operate near its 56 Mbps net throughput limit,
> which, factoring in the fact that the effective throughput will be
> decreased due to noise and that my application of course can't hog all
> the bandwidth and airtime, means that I will have around 20 Mbps
> available for unicasting to all clients.
>
> Rather than limiting the number of viewers as I originally proposed, I
> believe that automatically limiting the framerate of the broadcast
> based on the number of viewers will be a better way to scale for
> larger numbers of viewers - that is, once the broadcaster gets to the
> "broadcast" stage and selects the intended viewers, then based on the
> available bandwidth and network congestion, then an ideal framerate is
> calculated out and the stream is encoded and broadcast to all of the
> viewers at that framerate. Given that the most interest has been
> expressed over the remote desktop broadcasting feature, and given that
> there's rather little motion overall on a desktop broadcast, the
> desktop activity should still be easily viewed at very low framerates.
> From my personal experience, I don't really miss any features of my
> own typical desktop activity even at around 3-4 fps (except for
> gaming, but presumably this will be used primarily for relatively
> low-motion educational software). At 4 fps, the MJPEG video stream,
> with a 96 Kbps audio stream, comes out at around 0.5 Mbps. Using 20
> Mbps, this stream could be broadcast to 40 users, which I assume is
> around the upper limit of the number of students in the classroom.
> Assuming fewer viewers, then higher framerates could be used. Would
> this be a reasonable approach to limiting airtime usage with unicast
> streams?
>
> On Sat, Apr 11, 2009 at 6:36 AM, Martin Langhoff
>  wrote:
> > On Sat, Apr 11, 2009 at 1:37 AM, Geza Kovacs  wrote:
> >> According to
> http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4292735
> >> then the slowest transmission speed, Mode1 (6 Mbps) is only beneficial
> >> for multicasting over very large distances; in the case of the AWGN
> >
> > I am sure they did their tests in quiet RF environments. In crowded
> > environments nodes can tell the AP that they're having trouble hearing
> > the frames, please transmit slower.
> >
> > You've calculated 1.6Mbps but that's only the stream. You need to get
> > each to the AP, and _then_ it'll be broadcast. The frame to the AP may
> > be transmittedfast if the XO is close to the AP. The datarate for the
> > broadcast frame from the AP to all the nodes is set by the AP based on
> > the nodes it has registered...
> >
> >> In terms of airtime consumption, this of course depends on the
> >> airtime-fairness mechanisms used by the wireless network. However,
> >
> > Which just don't exist (not i

Re: [Sugar-devel] Unified Objects (was Unified bundles)

[C. Scott Ananian]

Quick comment: you should probably be thinking about running
activities *in place from their ZIP file* rather than storing the
"unpacked" form in the Journal.  This will lead to a much simpler
implementation in the short term, since activities still have a single
identity.

There are a number of desktop search projects which are growing
notions of "nested identity" such that there's an activity bundle (zip
file, tar ball, open office document, directory, etc) which has other
documents "inside" it -- but support for this is still very immature.
It's easier to treat bundles as single blobs: python is perfectly
happy to run code from inside a ZIP file, and if you want to use
something other than python then there are several FUSE modules that
will let you temporarily mount your ZIP file on a directory mount
point.
 --scott

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

Re: [Sugar-devel] GSoC Proposal: Multimedia Broadcasting

[Geza Kovacs]

On 04/11/2009 07:07 PM, Carol Farlow Lerche wrote:
> It seems like this conversation is somewhat at cross-purposes.  Martin
> discusses the general case of multicast from an arbitrary client through
> an access point serving many clients with a mixture of multicast and
> unicast traffic.  Well known performance problems result.  However, Geza
> proposes a special case (perhaps).  In a classroom, it would be nice to
> be able to have a "projector" to send a stream of video to the stations
> within that classroom.  Now, not every school could have extra hardware
> for this purpose, but I think many could, just as our schools of yore
> had that funky projector that got rolled into the classroom on the
> morning when our teacher wanted us to see (or sleep through :-) a movie
> about something or other.
>
> What might be interesting is to consider the possibiliity of connecting
> the projector client via a USB ethernet connector to a separate
> "multicast" access point, that the receiving clients associated with for
> the time of the "movie".  This allows the originator of the stream to
> use a wired connection to the AP, the AP to be chosen and configured to
> optimize multicasting, and the whole thing to be somewhat isolated from
> the unicast traffic happening elsewhere.
>

I don't think requiring an additional access point is the right way to 
accomplish this. As you said, hardware is expensive, so it would be 
unrealistic to install a new access point into every classroom, and if 
it were only available in certain classrooms then we're back to what we 
have right now with projectors - only those classrooms which have them 
at the moment can use them. As for adding the need for a wired 
connection to the AP, as I understand the XS already has one so it might 
be used as a "relay" so that the actual source machine is simply sending 
the XS the signal over unicast and the XS is handling the multicasting. 
Personally I don't like the notion of requiring any wiring because that 
would limit the locations from which video could be broadcast - say you 
wouldn't be able to project a video stream from a lab station unless it 
was pre-wired before class to do so. I think limiting airtime usage on 
the existing network, by limiting framerates, viewers, or similar 
mechanisms, is the optimal way to solve this issue - additional hardware 
requirements would mean that this couldn't immediately be of use in many 
existing deployments.

Right now I'm thinking that, given that I saw at max one full-motion 
video in class each school year in high school, full-motion video is 
really a limited niche to be addressing. Given that lecture slides are 
shown in many classes via projectors basically every day, then extremely 
low framerate video is really the key to be thinking about here (simply 
broadcasting the lecture slides in PDF format and using libpoppler to 
render them client-side and broadcasting slide transition notices could 
also work - I actually implemented something like this last semester, 
but then we have the issue that most teachers prefer to present slides 
directly from PowerPoint/OpenOffice, and that all kinds of issues might 
occur if the teacher uses specialized fonts or the like).

I don't believe that lecture slides, which could be broadcast at much 
lower framerates (1 fps MJPEG is 100 Kbps per stream) and would thus 
occupy very little bandwidth and airtime, would suffer any of the issues 
that Martin and I have been discussing. I've updated my proposal 
accordingly to reflect the emphasis on broadcasting of lecture slides. 
Of course this doesn't mean I'm not planning to implement the features I 
originally proposed - this is merely a contingency plan so that Sugar 
Labs is left with a useful product nevertheless if technical issues make 
full-motion video broadcasting infeasible.

> Not sure if this is workable, but some reading of the papers about
> multicast performance issues on the Intertubes suggest it might be
> promising.
>
> On Sat, Apr 11, 2009 at 3:07 PM, Geza Kovacs  > wrote:
>
> Since you apparently have more experience with multicasting over
> wireless I'll assume it's not a realistic option in this context
> (though it might nevertheless be an interesting experiment to try if
> have spare time over the course of GSoC after finishing a
> unicast-based implementation).
>
> Returning to unicasting and simply limiting net bandwidth usage, as I
> understand the "slowest client sets the speed" issue with the access
> node switching to Mode1 for broadcast applies only to multicasting. If
> I have the XO send the video in a single UDP stream to the central XS
> server (which as I understand has a wired connection to the AP), then
> have those streams be individually relayed by the XS over the AP to
> each designated viewer in over unicast UDP, then as I understand the
> AP will be able to operate near its 56 Mbps net t

[Sugar-devel] GSoC proposal: Speech Synthesis

[chirag jain]

Hi !!

I have implemented a small application that works as a system side
keyboard speaker in sugar.
To test it please download the keboard_speaker.zip from the following link:

http://code.google.com/p/speech-synthesis/downloads/list

I want some reviews on it.

Regards

-- 
Chirag Jain

Undergraduate Student
Netaji Subash Institute of Technology
New Delhi
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel