Difference between revisions of "Features/WebKit"
DanielDrake (talk | contribs) |
DanielDrake (talk | contribs) |
||
| Line 10: | Line 10: | ||
== Owner == | == Owner == | ||
| − | * | + | * 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. | ||
| − | === | + | === The PyGI GTK+-2 option === |
| − | + | 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 == | ||
Revision as of 12:05, 15 June 2011
Summary
Browse and related components are switching to WebKit as its back-end technology provider. (this is just a proposal, for now)
Owner
- Planned/proposed by Daniel Drake
- Implemented by: ? (volunteer here!)
Current status
- Targeted release: (SUGAR_VERSION)
- Last updated: (DATE)
- Percentage of completion: XX%
Detailed Description
Browse and related components currently embed Mozilla XUL/Gecko as their backend, however, Mozilla embedding has typically been neglected and buggy, causing a maintenance headache for us. It is now actively discouraged by Mozilla developers, who are focusing all their efforts on Firefox. From the perspective of a fairly regular open-source project, Mozilla's direction is also questionable on other points.
WebKit is a promising alternative, which is (by nature) an embeddable web engine. It is used in Apple Safari and Google Chrome and various other projects.
Existing prototype: Surf
The pywebkitgtk-based Surf activity can be used as a prototype. Possible areas that need work are:
- Downloads - originally missing due to no support in pywebkitgtk but now landed?
- persistant history - not saved across sessions (or journal entries)
- clipboard/undo/redo - should be simple
- back and forward buttons - you can go back and forward through your history, but autocomplete and skipping back or forward in the history is not implemented. shouldn't be too hard to complete
- arrow key navigation in textbox
- No cookie support
pywebkit is seen as deprecated, 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.
The PyGI GTK+-2 option
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
What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?
Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.
Scope
What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?
UI Design
Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.
How To Test
User Experience
If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.
Dependencies
pywebkitgtk is already a part of the Sugar platform (for epub support in Read).
Contingency Plan
If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If your feature is not completed in time, we want to assure others that other parts of Sugar will not be in jeopardy.
Documentation
Is there upstream documentation on this feature, or notes you have written yourself? Has this topic been discussed in the mailing list or during a meeting? Link to that material here so other interested developers can get involved.
Release Notes
The Sugar Release Notes inform end-users about what is new in the release. An Example is 0.84/Notes. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.