[sugar] (another) WebKit port of Browse

[Jim Gettys]

Oh, and as Walter points out, journal integration is also important to
us, and necessary in any replacement.  Sometimes brain is not engaged.

If we can build the OLPCfs stuff that Scott has come up with, this will
help unmodified apps interoperate with the journal, but I suspect for
something like browse, we'd want pretty full integration.
                        - Jim


On Tue, 2008-07-08 at 12:32 -0400, Jim Gettys wrote:
> Let me summarize where I think we are and/or should go and try to put
> this into some context:
> 
> 0) good rendering onto our high resolution screen is very important to
> us; this is why we went with a Gecko based web browser in the first
> place.  Before we moved to the development builds of gecko/xulrunner, we
> had terrible issues with many web site's rendering. I don't know whether
> or not WebKit supports scaling at this date, but it is a question well
> worth asking.  This new version of Gecko etc. are slated for our next
> release and are in current development builds. What is WebKit's current
> capability?
> 
> 1) memory usage is a very high concern to us.  The recent work on
> FF/Gecko's memory consumption and leak plugging (as reported all over
> the web) is outstanding, and they should be commended for this work.
> This improvement should be reflected in the current development build.
> And this has a major impact on our usability.
> 
> 2) the lack of a certificate UI has hampered our Browse usage primarily
> in G1G1 developed world situations: this tells me while it is of
> concern, it's not as high priority as some other issues might be,
> certainly lower than 0) or 1).  This could be satisfied by adding UI to
> browse, I believe.
> 
> 3) Sayamindu has made good progress toward swapping out Matchbox in
> favor of a conventional window manager; once this is complete, we can
> satisfy 2) at worst, by those who need it installing a standard Firefox;
> one could go up from there by using a Sugar theme, to XUL chrome
> modifications of arbitrary ambition; or installing your favorite web
> browser of choice.  This work to replace Matchbox won't make this
> release, but I expect be planned on thereafter.
> 
> 4) alternative browsers are always welcome; but, to make it as our
> default browser, it needs to:
>     - address our rendering concerns for our screen.
>     - have competitive memory performance
>     - provide sharing features for classroom work (note that
> 	providing only an unmodified conventional browser won't 
> 	currently have these facilities).
> Additional goodness would be to have a single HTML rendering engine for
> everything, to save flash space, and the certificate UI we're missing.
> 
> I can also anticipate Javascript performance may become an issue as its
> use continues to increase.
> 
>                  - Jim
> 
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child