Re: [Sugar-devel] Sugar-devel Digest, Vol 17, Issue 49

2010-03-21 Thread vijit singh 
-- Forwarded message --

> From: Walter Bender 
> To: Lucian Branescu 
> Date: Sun, 21 Mar 2010 21:10:59 -0400
> Subject: Re: [Sugar-devel] [GSoC] Sugar Browser
> On Sun, Mar 21, 2010 at 8:27 PM, Lucian Branescu
>  wrote:
> > On 22 March 2010 00:12, Benjamin M. Schwartz 
> > wrote:
> >>
> >> Lucian Branescu wrote:
> >> > I am inclined to choose the second for a few reasons. First, current
> >> > webkit
> >> > is much faster and uses less memory than current gecko, which has been
> >> > especially visible on XOs.
> >>
> >> I'm not willing to accept this as proven.  As for faster, see
> >> http://weblogs.mozillazine.org/bz/archives/020434.html
> >>
> >> As for memory usage, see
> >> http://dotnetperls.com/chrome-memory
> >
> > Of course Chrome usage is much higher. Chrome has at least one process
> for
> > each tab.
> > Safari is also a wreck, especially on Windows.
> >>
> >> Webkit may be faster (although... with which javascript engine? on what
> >> graphics hardware? with which bookmarks/awesomebar system?) but I don't
> >> think it's so obvious.  Previous comparisons on the XO have been deeply
> >> flawed because Gecko was scaling up all fonts and images, while Webkit
> was
> >> not.
> >
> > The test I have done both on OS X and soas have shown webkit to be far
> > superior in execution speed and still superior in memory usage for
> > benchmarks. These weren't entirely relevant, so I will do another set of
> > benchmarks that are more relevant to XO usage (with firefox 3.6).
> > Here are my old results:
> > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt
> > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt
> > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt
> >>
> >> > While gecko has superior extendability (XUL
> >> > extensions), Browse isn't compatible with Firefox extensions, so
> >> > anything
> >> > would need to be rewritten anyway. Userscripts (Greasemonkey) serve
> most
> >> > needs for now and if needed, an extension API akin to Mozilla's
> Jetpack
> >> > or
> >> > Chrome's extensions could be implemented.
> >>
> >> This sounds like an argument for staying with Gecko and adopting
> >> Greasemonkey and Jetpack.
> >
> > It's an argument for not really needing Gecko. Both could be implemented
> on
> > Webkit.
> >>
> >> > Second, webkit is being used by a lot of projects and has the backing
> of
> >> > several companies.
> >>
> >> Gecko is far more widely deployed (~30% of all internet users).
> >
> > The arguments other people have given to me have to do with how many
> > projects use it (maintained by many companies/communities).
> >>
> >> > Furthermore, it is packaged more consistently across
> >> > platforms/distributions.
> >>
> >> I'm not sure what this means, but it doesn't seem critical.
> >
> > Xulrunner tends to have many patches applied by distros. Webkit doesn't.
> >>
> >> > Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk
> tries
> >> > not
> >> > to diverge unless necessary) and it should be possible to not depend
> too
> >> > much on any one of them. A thin abstraction layer could be written on
> >> > top to
> >> > handle most differences and it should only rarely be needed to go
> >> > beneath
> >> > this abstraction. While this would most likely not result in a browser
> >> > than
> >> > can switch engines at runtime, it should make any future porting much
> >> > easier.
> >>
> >> I'm certainly not going to complain about an abstraction layer of this
> >> sort.  As I've said before, I think a lot of developers would enjoy an
> >> "engine-agnostic" browser widget.
> >>
> >> --Ben
> >>
> >
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>
> While performance differences might be somewhat interesting, the fact
> that tests tend to be inconclusive suggests it is not a compelling
> reason to choose one over the other. I think one point that Lucian
> made is being lost in the discussion: maintainability. Is a
> webkit-based browser going to be easier to maintain in the near to
> long term?
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>
Yes, surely maintainability over the long term should be a major concern in
making any decision. I think the fact that Mozilla might lose support for
XPCOM ( if that's true) is something that matters. However, developing the
webkit-based browser during gsoc( to explore the possibilities) along with
maintaining browse is what might be a good solution.

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

Re: [Sugar-devel] [GSoC] Sugar Browser FireFox 6 on ASLO?

2010-03-21 Thread Thomas C Gilliard 




FireFox 6 on ASLO?

It works on Nightly Composes liveusb-creator 2Gb sticks
Tom Gilliard
satellit

Walter Bender wrote:

  On Sun, Mar 21, 2010 at 8:27 PM, Lucian Branescu
 wrote:
  
  
On 22 March 2010 00:12, Benjamin M. Schwartz 
wrote:


  Lucian Branescu wrote:
  
  
I am inclined to choose the second for a few reasons. First, current
webkit
is much faster and uses less memory than current gecko, which has been
especially visible on XOs.

  
  I'm not willing to accept this as proven.  As for faster, see
http://weblogs.mozillazine.org/bz/archives/020434.html

As for memory usage, see
http://dotnetperls.com/chrome-memory
  

Of course Chrome usage is much higher. Chrome has at least one process for
each tab.
Safari is also a wreck, especially on Windows.


  Webkit may be faster (although... with which _javascript_ engine? on what
graphics hardware? with which bookmarks/awesomebar system?) but I don't
think it's so obvious.  Previous comparisons on the XO have been deeply
flawed because Gecko was scaling up all fonts and images, while Webkit was
not.
  

The test I have done both on OS X and soas have shown webkit to be far
superior in execution speed and still superior in memory usage for
benchmarks. These weren't entirely relevant, so I will do another set of
benchmarks that are more relevant to XO usage (with firefox 3.6).
Here are my old results:
http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt
http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt
http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt


  
While gecko has superior extendability (XUL
extensions), Browse isn't compatible with Firefox extensions, so
anything
would need to be rewritten anyway. Userscripts (Greasemonkey) serve most
needs for now and if needed, an extension API akin to Mozilla's Jetpack
or
Chrome's extensions could be implemented.

  
  This sounds like an argument for staying with Gecko and adopting
Greasemonkey and Jetpack.
  

It's an argument for not really needing Gecko. Both could be implemented on
Webkit.


  
Second, webkit is being used by a lot of projects and has the backing of
several companies.

  
  Gecko is far more widely deployed (~30% of all internet users).
  

The arguments other people have given to me have to do with how many
projects use it (maintained by many companies/communities).


  
Furthermore, it is packaged more consistently across
platforms/distributions.

  
  I'm not sure what this means, but it doesn't seem critical.
  

Xulrunner tends to have many patches applied by distros. Webkit doesn't.


  
Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries
not
to diverge unless necessary) and it should be possible to not depend too
much on any one of them. A thin abstraction layer could be written on
top to
handle most differences and it should only rarely be needed to go
beneath
this abstraction. While this would most likely not result in a browser
than
can switch engines at runtime, it should make any future porting much
easier.

  
  I'm certainly not going to complain about an abstraction layer of this
sort.  As I've said before, I think a lot of developers would enjoy an
"engine-agnostic" browser widget.

--Ben

  


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



  
  
While performance differences might be somewhat interesting, the fact
that tests tend to be inconclusive suggests it is not a compelling
reason to choose one over the other. I think one point that Lucian
made is being lost in the discussion: maintainability. Is a
webkit-based browser going to be easier to maintain in the near to
long term?

-walter

  



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

Re: [Sugar-devel] [GSoC] Sugar Browser

2010-03-21 Thread Walter Bender 
On Sun, Mar 21, 2010 at 8:27 PM, Lucian Branescu
 wrote:
> On 22 March 2010 00:12, Benjamin M. Schwartz 
> wrote:
>>
>> Lucian Branescu wrote:
>> > I am inclined to choose the second for a few reasons. First, current
>> > webkit
>> > is much faster and uses less memory than current gecko, which has been
>> > especially visible on XOs.
>>
>> I'm not willing to accept this as proven.  As for faster, see
>> http://weblogs.mozillazine.org/bz/archives/020434.html
>>
>> As for memory usage, see
>> http://dotnetperls.com/chrome-memory
>
> Of course Chrome usage is much higher. Chrome has at least one process for
> each tab.
> Safari is also a wreck, especially on Windows.
>>
>> Webkit may be faster (although... with which javascript engine? on what
>> graphics hardware? with which bookmarks/awesomebar system?) but I don't
>> think it's so obvious.  Previous comparisons on the XO have been deeply
>> flawed because Gecko was scaling up all fonts and images, while Webkit was
>> not.
>
> The test I have done both on OS X and soas have shown webkit to be far
> superior in execution speed and still superior in memory usage for
> benchmarks. These weren't entirely relevant, so I will do another set of
> benchmarks that are more relevant to XO usage (with firefox 3.6).
> Here are my old results:
> http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt
> http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt
> http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt
>>
>> > While gecko has superior extendability (XUL
>> > extensions), Browse isn't compatible with Firefox extensions, so
>> > anything
>> > would need to be rewritten anyway. Userscripts (Greasemonkey) serve most
>> > needs for now and if needed, an extension API akin to Mozilla's Jetpack
>> > or
>> > Chrome's extensions could be implemented.
>>
>> This sounds like an argument for staying with Gecko and adopting
>> Greasemonkey and Jetpack.
>
> It's an argument for not really needing Gecko. Both could be implemented on
> Webkit.
>>
>> > Second, webkit is being used by a lot of projects and has the backing of
>> > several companies.
>>
>> Gecko is far more widely deployed (~30% of all internet users).
>
> The arguments other people have given to me have to do with how many
> projects use it (maintained by many companies/communities).
>>
>> > Furthermore, it is packaged more consistently across
>> > platforms/distributions.
>>
>> I'm not sure what this means, but it doesn't seem critical.
>
> Xulrunner tends to have many patches applied by distros. Webkit doesn't.
>>
>> > Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries
>> > not
>> > to diverge unless necessary) and it should be possible to not depend too
>> > much on any one of them. A thin abstraction layer could be written on
>> > top to
>> > handle most differences and it should only rarely be needed to go
>> > beneath
>> > this abstraction. While this would most likely not result in a browser
>> > than
>> > can switch engines at runtime, it should make any future porting much
>> > easier.
>>
>> I'm certainly not going to complain about an abstraction layer of this
>> sort.  As I've said before, I think a lot of developers would enjoy an
>> "engine-agnostic" browser widget.
>>
>> --Ben
>>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>

While performance differences might be somewhat interesting, the fact
that tests tend to be inconclusive suggests it is not a compelling
reason to choose one over the other. I think one point that Lucian
made is being lost in the discussion: maintainability. Is a
webkit-based browser going to be easier to maintain in the near to
long term?

-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] [GSoC] Sugar Browser

2010-03-21 Thread Lucian Branescu 
On 22 March 2010 00:12, Benjamin M. Schwartz wrote:

> Lucian Branescu wrote:
> > I am inclined to choose the second for a few reasons. First, current
> webkit
> > is much faster and uses less memory than current gecko, which has been
> > especially visible on XOs.
>
> I'm not willing to accept this as proven.  As for faster, see
> http://weblogs.mozillazine.org/bz/archives/020434.html
>
> As for memory usage, see
> http://dotnetperls.com/chrome-memory

Of course Chrome usage is much higher. Chrome has at least one process for
each tab.
Safari is also a wreck, especially on Windows.

>
>
> Webkit may be faster (although... with which javascript engine? on what
> graphics hardware? with which bookmarks/awesomebar system?) but I don't
> think it's so obvious.  Previous comparisons on the XO have been deeply
> flawed because Gecko was scaling up all fonts and images, while Webkit was
> not.

The test I have done both on OS X and soas have shown webkit to be far
superior in execution speed and still superior in memory usage for
benchmarks. These weren't entirely relevant, so I will do another set of
benchmarks that are more relevant to XO usage (with firefox 3.6).

Here are my old results:
http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt
http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt
http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt

>
> > While gecko has superior extendability (XUL
> > extensions), Browse isn't compatible with Firefox extensions, so anything
> > would need to be rewritten anyway. Userscripts (Greasemonkey) serve most
> > needs for now and if needed, an extension API akin to Mozilla's Jetpack
> or
> > Chrome's extensions could be implemented.
>
> This sounds like an argument for staying with Gecko and adopting
> Greasemonkey and Jetpack.
>
It's an argument for not really needing Gecko. Both could be implemented on
Webkit.

>
> > Second, webkit is being used by a lot of projects and has the backing of
> > several companies.
>
> Gecko is far more widely deployed (~30% of all internet users).
>
The arguments other people have given to me have to do with how many
projects use it (maintained by many companies/communities).

>
> > Furthermore, it is packaged more consistently across
> > platforms/distributions.
>
> I'm not sure what this means, but it doesn't seem critical.
>
Xulrunner tends to have many patches applied by distros. Webkit doesn't.

>
> > Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries
> not
> > to diverge unless necessary) and it should be possible to not depend too
> > much on any one of them. A thin abstraction layer could be written on top
> to
> > handle most differences and it should only rarely be needed to go beneath
> > this abstraction. While this would most likely not result in a browser
> than
> > can switch engines at runtime, it should make any future porting much
> > easier.
>
> I'm certainly not going to complain about an abstraction layer of this
> sort.  As I've said before, I think a lot of developers would enjoy an
> "engine-agnostic" browser widget.
>
> --Ben
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] Sugar Browser

2010-03-21 Thread Benjamin M. Schwartz 
Lucian Branescu wrote:
> I am inclined to choose the second for a few reasons. First, current webkit
> is much faster and uses less memory than current gecko, which has been
> especially visible on XOs.

I'm not willing to accept this as proven.  As for faster, see
http://weblogs.mozillazine.org/bz/archives/020434.html

As for memory usage, see
http://dotnetperls.com/chrome-memory

Webkit may be faster (although... with which javascript engine? on what
graphics hardware? with which bookmarks/awesomebar system?) but I don't
think it's so obvious.  Previous comparisons on the XO have been deeply
flawed because Gecko was scaling up all fonts and images, while Webkit was
not.

> While gecko has superior extendability (XUL
> extensions), Browse isn't compatible with Firefox extensions, so anything
> would need to be rewritten anyway. Userscripts (Greasemonkey) serve most
> needs for now and if needed, an extension API akin to Mozilla's Jetpack or
> Chrome's extensions could be implemented.

This sounds like an argument for staying with Gecko and adopting
Greasemonkey and Jetpack.

> Second, webkit is being used by a lot of projects and has the backing of
> several companies.

Gecko is far more widely deployed (~30% of all internet users).

> Furthermore, it is packaged more consistently across
> platforms/distributions.

I'm not sure what this means, but it doesn't seem critical.

> Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not
> to diverge unless necessary) and it should be possible to not depend too
> much on any one of them. A thin abstraction layer could be written on top to
> handle most differences and it should only rarely be needed to go beneath
> this abstraction. While this would most likely not result in a browser than
> can switch engines at runtime, it should make any future porting much
> easier.

I'm certainly not going to complain about an abstraction layer of this
sort.  As I've said before, I think a lot of developers would enjoy an
"engine-agnostic" browser widget.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [GSoC] Sugar Browser

2010-03-21 Thread Lucian Branescu 
Some have expressed concern about Browse and its current xulrunner
dependency (http://bugs.sugarlabs.org/ticket/1850). To make matters even
worse for the future, Mozilla plans to get rid of XPCOM at some point in
favour of better JavaScript interfacing to C++ and a JavaScript ffi similar
to ctypes.

Surf is an existing browser activity that uses webkit (pywebkitgtk). It is
not yet on par feature-wise with Browse, but it could be extended.

I see a few possible ways forward, that I could work on for GSoC:
1) Get Browse into shape (with a bundled xulrunner?)
2) Update Surf to be on par with Browse

I am inclined to choose the second for a few reasons. First, current webkit
is much faster and uses less memory than current gecko, which has been
especially visible on XOs. While gecko has superior extendability (XUL
extensions), Browse isn't compatible with Firefox extensions, so anything
would need to be rewritten anyway. Userscripts (Greasemonkey) serve most
needs for now and if needed, an extension API akin to Mozilla's Jetpack or
Chrome's extensions could be implemented.

Second, webkit is being used by a lot of projects and has the backing of
several companies. Furthermore, it is packaged more consistently across
platforms/distributions.

Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not
to diverge unless necessary) and it should be possible to not depend too
much on any one of them. A thin abstraction layer could be written on top to
handle most differences and it should only rarely be needed to go beneath
this abstraction. While this would most likely not result in a browser than
can switch engines at runtime, it should make any future porting much
easier.

Any thoughts on this?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] scalability in the neighborhood view

2010-03-21 Thread Eben Eliason 
On Wed, Mar 3, 2010 at 2:08 PM, Martin Langhoff
 wrote:
> On Wed, Mar 3, 2010 at 1:02 PM, Caroline Meeks  
> wrote:
>> would be a nice feature to eventually have to let the teacher narrow down
>> the neighborhood based on a specific Moodle group, for a specific period of
>> time.  That is have students focus on only other students in their class
>> right now.
>
> Yeah, I've thought of that, and heard/read this kind of request a few times.
>
> Once we are where Tomeu wants to take us, I think it'll make sense to
> add something like what you describe, perhaps in the neighbourhood
> view or in the 'friends' view.

This has always been the intent of the "middle" view, which was
designed as a "Groups" view (with a number of configurable filters for
various groups a student might be a part of) and is currently just a
"Friends" view. After adding further group support, I suspect
"Friends" will just be one of the available groups.

I know that improvements to Groups/Friends view have been no the table
for upcoming releases, so maybe we can start with a Moodle-only
approach and later extend to a generic system that works with or
without a server.

Eben

> It's probably a mode that Moodle signals to the laptops. The data on
> the Sugar side is the same, but the UI changes a bit to help focus.
>
> 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
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SoaS change in engineering direction: activity questions

2010-03-21 Thread sankarshan 
On Sat, Mar 20, 2010 at 7:55 AM, Sebastian Dziallas  wrote:
> SoaS engineering just proposed a major change-in-direction for the
> upcoming (Mirabelle) release. See
> http://lists.sugarlabs.org/archive/soas/2010-March/000906.html and
> http://lists.sugarlabs.org/archive/marketing/2010-March/002727.html for
> more information - the short version is that instead of "include all
> Activites by default," we're thinking of shipping very few (6)
> Activities by default - the ones that help users get further Activities
> and help - and driving them to ASLO to download Activities and engage
> directly with Activity creators (you!) instead.

What is the criteria for selecting the minimal set ? Is there a
process to review and modify the minimal set for upcoming releases
(ie. is this the frozen/final list) ? As a minimal set ensures that
these activities are necessarily translated/localized, is there a
means to mark them appropriately in Pootle as part of translation team
goals ?

-- 
sankarshan mukhopadhyay

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