Features/WebKit: Difference between revisions

Line 52:

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.

==== WebKit or WebKit2? ====

http://blogs.igalia.com/alex/2011/04/08/webkit2-minibrowser-for-the-gtk-port-running/

== Benefit to Sugar ==

@@ Line 52: / Line 52: @@
 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.
+==== WebKit or WebKit2? ====
+http://blogs.igalia.com/alex/2011/04/08/webkit2-minibrowser-for-the-gtk-port-running/
 == Benefit to Sugar ==