Changes

Jump to navigation Jump to search
1,108 bytes added ,  12:05, 15 June 2011
no edit summary
Line 10: Line 10:     
== Owner ==
 
== Owner ==
* Name: [[User:DanielDrake|Daniel Drake]]
+
* Planned/proposed by [[User:DanielDrake|Daniel Drake]]
 +
* Implemented by: ? (volunteer here!)
    
== Current status ==
 
== Current status ==
Line 35: Line 36:  
pywebkit is seen as deprecated, [http://janalonzo.wordpress.com/2010/01/18/using-introspected-webkitgtk-in-gwibber/ even by the author himself]. PyGI is the solution, allowing direct calls into pywebkitgtk with no static bindings, and is now mature. Some of the missing features above can't be solved until either pywebkitgtk grows more API, or the switch is made to PyGI.
 
pywebkit is seen as deprecated, [http://janalonzo.wordpress.com/2010/01/18/using-introspected-webkitgtk-in-gwibber/ even by the author himself]. PyGI is the solution, allowing direct calls into pywebkitgtk with no static bindings, and is now mature. Some of the missing features above can't be solved until either pywebkitgtk grows more API, or the switch is made to PyGI.
   −
=== Proposed implementation ===
+
=== The PyGI GTK+-2 option ===
   −
Browse should move to WebKitGtk (for GTK+-2.x) using PyGI (gobject-introspection). Even though most applications of PyGI target GTK+ v3, we believe it should work on v2. However, a possible problem here is that sugar-toolkit bindings use static GTK+ bindings, and mixing PyGI calls in the same app might lead to problems ([http://lists.sugarlabs.org/archive/sugar-devel/2011-June/031869.html source]).
+
To take Surf to the next level, it needs to switch to PyGI for access to the GTK2 version of WebKitGtk, which would fit in with the rest of the Sugar environment. However, this is not possible, for 2 reasons (as explained by pygi developers Tomeu and J5):
 +
# PyGI introspection to GTK2-based libraries is not supported and does not work well
 +
# sugar-toolkit uses pygtk static bindings, and mixing pygtk static bindings with pygi bindings will not work at all
 +
 
 +
Therefore a simple port of Surf to webkitgtk via pygi is not an option.
 +
 
 +
=== Implementation plan ===
 +
 
 +
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.
 +
 
 +
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.
    
== Benefit to Sugar ==
 
== Benefit to Sugar ==
105

edits

Navigation menu