Changes

A decision must be made on modularisation: do we create something like hulahop, providing a nice easy-to-use web view widget for Sugar, or do we just call into WebKit directly from Browse? A hulahop equivalent would only be needed if embedding WebKit is painful and complicated, like mozilla was.

A decision must be made on modularisation: do we create something like hulahop, providing a nice easy-to-use web view widget for Sugar, or do we just call into WebKit directly from Browse? A hulahop equivalent would only be needed if embedding WebKit is painful and complicated, like mozilla was.

Another possibility is the creation of a Sugar-level "web widget" - again, this would depend on the complexity and difficulty of embedding webkit. Such a widget could be shared between Browse and Wikipedia, but finding the right level of abstraction to avoid making that widget over-specific to those two use cases could be tricky - it depends partially on WebKit's design and their level of success in achieving an easily-embeddable experience.

Another possibility is the creation of a Sugar-level "web widget" - again, this would depend on the complexity and difficulty of embedding webkit. Such a widget could be shared between Browse and Wikipedia, but finding the right level of abstraction to avoid making that widget over-specific to those two use cases could be tricky. Having looked at the [http://webkitgtk.org/reference/index.html WebKitGTK+ API reference], I don't believe that a web widget will be necessary, as this API seems high-quality: simplistic and powerful, directly exposing the core functions we'd need at an easy-to-comprehend level.

 

 

== Benefit to Sugar ==

== Benefit to Sugar ==