(another) WebKit port of Browse

Tomeu Vizoso tomeu at tomeuvizoso.net
Tue Jul 8 14:21:28 EDT 2008

On Tue, Jul 8, 2008 at 8:05 PM, C. Scott Ananian <cscott at cscott.net> wrote:
> On Tue, Jul 8, 2008 at 1:32 PM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>> We could add many more of the missing features to Browse if all the
>> developers weren't so busy with the rest of Sugar. Also, although most
>> of the sugar developers have occasionally hacked on Browse, we are far
>> from experts in the big piece of code that Mozilla is.
> This was my original point.  We either have sufficient resources to
> develop our own browser, or we don't.  I think it will (in the end) be
> more efficient to develop small Firefox extensions to support Journal
> integration and collaboration, rather than taxing the sugar developers
> with an attempt to (basically) reimplement large parts of firefox.

Well, the same could be said about the rest of Sugar. If our users are
better served by standard linux desktop components progressively
improved for our learning goals, we should drop Sugar and go for that.

>> I know that hiring takes time, I'm just making the point that doing
>> the Browse activity we want for OLPC is not anything impossible nor a
>> gigantic task. But requires at least focused people and efforts, and
>> better if those people already have the right experience.
> And my basic point was that I thought we'd be better off leveraging
> more of the upstream feature development directly, so that our Browse
> would continue to improve w/o our hiring a full time Browse developer.

Same as above, if OLPC's strategy is to be that, I should be working
on Nautilus instead of the Journal.

Again, I would like to see a list of the features actually needed by
users and sales, and then revisit the decision of how OLPC should be
spending its resources. In the meantime, all the testing with kids
that could be done with different browsers would be very useful.

> Anyway, as Martin says, this is all armchair quarterbacking until
> someone gets Firefox to more-or-less the same level as Browse is now.
> In my earlier part I started the process by packing Firefox 3.0 as a
> self-contained .xo file (no yum required); the next steps are to
> install the appropriate theme tweaks to integrate it into the sugar
> look, possibly some libsugarization, and to write the extensions to
> integrate with Tubes and the datastore (XUL is your friend).

Sure, all this will be very interesting work regardless of which
browser each deployment chooses to deploy.



More information about the Devel mailing list