105
edits
Changes
no edit summary
To implement this, Sugar must first be ported to pygi and GTK3. Once that is done, the following steps are proposed:
To implement this, Sugar must first be ported to pygi and GTK3. Once that is done, the following steps are proposed:
Browse should be ported to the gtk3 version of webkitgtk (already present in Fedora), using pygi and GTK3.
Browse should be ported to the gtk3 version of webkitgtk (already present in Fedora), using pygi to call into WebKitGTK, built on top of GTK3.
==== Modularisation ====
The previous Mozilla solution used a homegrown glue layer ("hulahop") in order to enable embedding of Mozilla in Browse and other activities. I believe the main reason for creation of this glue layer is that embedding Mozilla was complex, required lots of understanding of Mozilla's architecture, and needed to have some magic hidden somewhere. Marco, the original hulahop author, [http://lists.sugarlabs.org/archive/sugar-devel/2011-June/032000.html suggests that a hulahop replacement is not needed in WebKit context] as WebKit+PyGI seems to be equivalent.
Even if a complex glue layer is avoided, there is the possibility of creating a Sugar-level "web widget." This could be used to share code between Sugar activities that embed web browsing, and to reduce complexity of the embedding. However, 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.
http://blogs.igalia.com/alex/2011/04/08/webkit2-minibrowser-for-the-gtk-port-running/
Marco [http://lists.sugarlabs.org/archive/sugar-devel/2011-June/032000.html suggests] that Browse and another web-using activity (e.g. Wikipedia) first be ported to use direct calls into WebKitGTK, and then revisiting the question of modularisation/level of abstraction/code sharing. Once the work has been done on those activities, it should be obvious if there is a need for another layer. I agree with this approach, and my suspicion is that no such need will emerge thanks to the simplicity of the WebKitGTK API.
http://blog.kov.eti.br/?p=110
==== WebKit vs WebKit2 ====
[http://trac.webkit.org/wiki/WebKit2 WebKit2] is the development tree of WebKit, which includes fundamental architectural changes and a cross-platform API. WebKit will now define an API specification, which frontends such as WebKitGTK are expected to implement as closely as possible. This means that a function such as WKViewCreate() will return a GtkWidget under GTK+, and a QWidget under Qt, etc, meaning that moving webkit-using code from one platform to another is easy.
The WebKitGTK developers are embracing this direction and have already made [http://blogs.igalia.com/alex/2011/04/08/webkit2-minibrowser-for-the-gtk-port-running/ great progress] on the GTK implementation of the cross-platform API. They also have plans to [http://blog.kov.eti.br/?p=110 rebuild and refresh the GObject-style API] based on top of that cross-platform API.
My opinion, [http://lists.sugarlabs.org/archive/sugar-devel/2011-June/032000.html shared by Marco] (who originally did the whole Mozilla/hulahop dance), is that given this choice of API, Sugar should use the GObject-style one. This is because it would be automatically available in Python through GObject introspection, and would be consistent with the rest of the Sugar stack.
When it comes down to prototyping or implementing this, I suggest that the choice of WebKit vs WebKit2 is made based on which is the latest released version shipped in current distribution releases. Right now WebKit2 is not an option according to this plan as it does not yet offer a GObject-style API, so WebKit1 would be the right place to start, but that would change in future. As the API is well-designed, changing between versions doesn't seem like it would be a big job.
==== The HTML activities concept ====
[http://marcopg.org/2011/06/12/html-activities/ Marco] and [http://cscott.net/ Scott] have both recently explored ideas and developed prototypes around bringing web technologies closer to the heart of Sugar. Stated oversimplified, this is a "write an activity as a webpage" (instead of a GTK app) design idea. While this is an interesting direction to keep exploring, it is currently full of unknowns. Exactly which web technologies are/aren't relevant in activity context? Cookies? SSL certificates? Downloads? How would Journal interaction work? How would collaboration be implemented? Is WebKit appropriate for this? At which layer would it fit into the Sugar platform? These are all questions that will take time, care and prototypes to resolve.
On the other hand, the loss of Sugar's web browser is current: it screwed up a lot during late 2010 (xulrunner-1.9 / Fedora 14 timeframe), is now limping along again, has completely broken again (as of mid-2011, xulrunner-2.0 and Fedora 15 timeframe) and is no doubt up for a bumpy ride ahead. The solution can be designed and implemented now. Let's not mix a relatively straightforward, clearly defined and sorely needed task with one that is exploratory and uncertain.
The implementation proposed here is actually a simplification of the platform, as hulahop will be removed. Using WebKit instead of Mozilla in Browse is expected to result in a simplification of the codebase. If web technologies do catch on in other parts of Sugar, I predict that Browse will still retain its identity and requirements, due to considerations of cookies, SSL certificates, etc, which will not apply outside of web browser context. Finally, I expect the task of moving Browse from Mozilla to WebKit to be quite easy, and would generate experience and knowledge that would help towards the potential "HTML activities" direction.
== Benefit to Sugar ==
== Benefit to Sugar ==