105
edits
Changes
no edit summary
In order to remain innovative and current, and to take advantage of the latest developments, Sugar needs to follow suit and move to GTK3 and PyGI. Lagging behind on this conversion is already bringing negative consequences to Sugar; notably 2 of our most important activities (Read and Browse) are already broken and without a future until we catch up again.
In order to remain innovative and current, and to take advantage of the latest developments, Sugar needs to follow suit and move to GTK3 and PyGI. Lagging behind on this conversion is already bringing negative consequences to Sugar; notably 2 of our most important activities (Read and Browse) are already broken and without a future until we catch up again.
Unfortunately, this is an API-incompatible change. As confirmed by the PyGI developers, PyGTK and PyGI cannot be mixed in the same process. If sugar-toolkit were to be simply replaced with a PyGI/GTK3 port, this means that all activities would stop working until they themselves have also been ported - <b>all activities will need modifications as part of this feature</b>. The community has expressed desire for old activities to continue working (many are unmaintained); unfortunately this is not realistic in the long term. As a compromise, this feature discussion includes the requirement that for a certain period of time, both PyGTK/GTK2 and PyGI/GTK3 activities must be able to function alongside each other.
Unfortunately, this is an API-incompatible change. As confirmed by the PyGI developers, PyGTK and PyGI cannot be mixed in the same process. This means that the conversion process can't be done on a fine, incremental basis, and if sugar-toolkit were to be simply replaced with a PyGI/GTK3 port, this means that all existing activities would stop working until they themselves have also been ported - <b>all activities will need modifications as part of this feature</b>. The community has expressed desire for old activities to continue working (many are unmaintained); unfortunately this is not realistic in the long term. As a compromise, this feature discussion includes the requirement that for a certain period of time, both PyGTK/GTK2 and PyGI/GTK3 activities must be able to function alongside each other.
This task will involve modifications to almost every file within Sugar and its activities. Although much of this work can be automated, and the porting process for a given chunk of code is usually trivial, it is still a huge task. This feature discussion attempts to identify ways that this porting process can be done in distinct stages, where Sugar remains functional at the completion of each stage, making this more manageable.
This task will involve modifications to almost every file within Sugar and its activities. Although much of this work can be automated, and the porting process for a given chunk of code is usually trivial, it is still a huge task. This feature discussion attempts to identify ways that this porting process can be done in distinct stages, where Sugar remains functional at the completion of each stage, making this more manageable.
== Implementation Plan ==
== Implementation Plan ==
Sugar is divided into different components, many of which run in different processes. This means that we are able to
Sugar is divided into different components, many of which run in different processes. This means that we are able to divide up the required work on a process-by-process basis. While this work is being conducted, some Sugar processes might be based on PyGI/GTK3 and others based on PyGTK/GTK2, but the platform would keep functioning at each stage. There would be some system resource overhead during this transitional time (as the system would need to have PyGTK, GTK2, PyGI and GTK3 all in memory) but this feature implementation would end with the whole sugar ecosystem using PyGI/GTK3.
=== HippoCanvas removal ===
A prerequisite to porting a Sugar process, component or activity is to remove all its usage of hippocanvas. This library is unmaintained, would be painful to port to GTK3, and can be done better with standard GTK+ code at the Python level. Most users of HippoCanvas can switch to custom GtkContainer widgets.
One complication is that hippo usage is not limited to Sugar's core; some activities use hippo, or they pull on sugar-toolkit classes which are implemented with hippo. These are: Chat (<em>please list others here</em>).
=== Backwards-compatibility for activities ===
As mentioned above, as mixing PyGTK/GTK2 and PyGI/GTK3 is impossible, a straightforward port of sugar-toolkit to PyGI/GTK3 would break all activities. However, having backwards compatibility for activities for a limited time is considered a requirement, and having a "flag day" where all activities stop working until ported is not seen as an option - there must be a transition period.
As the conversion process from PyGTK to PyGI makes minor changes to almost every single line of code that involves GTK/glib, maintaining both PyGI and PyGTK codepaths in the same files is not realistic (there would be an unrealistic amount of <tt>if</tt> conditions). <b>We are therefore required to have two copies of sugar-toolkit during the transition period</b>: one for ported PyGI/GTK3 activities, and another for PyGTK/GTK2 activities that have not yet been ported.
As we do not have plentiful developer resources, I propose that the PyGTK/GTK2 version of sugar-toolkit is frozen as soon as this feature development is underway. No bugfixes or improvements, just a copy of the code at that point.
==== Selecting a sugar-toolkit version ====
With two versions of sugar-toolkit available, activities need a mechanism for choosing which toolkit they will use. As we require existing activities to continue working without modifications, this selection mechanism must be <em>opt-in</em> - ported activities must somehow mark themselves as being GTK3-ported, and hence will receive the GTK3 version of sugar-toolkit, and all other activities will receive the GTK2 version.
One easy way to achieve this would be to give the GTK3 version of sugar-toolkit a different name. The unported GTK2 activities could continue to <tt>import sugar.foo</tt> and ported GTK3 activities would <tt>import sugar1.foo</tt>. "sugar1" is chosen as an example to indicate Sugar-1.0, but other naming schemes would obviously work equally well.
If the community has strong desires to maintain the <tt>sugar</tt> module name, this would be possible through a Python trick which could be deployed during the transition period, and then removed once
=== Proposed plan of action ===
# Remove hippocanvas from sugar-toolkit
# Port sugar-toolkit to GTK3 while keeping backwards compatibility
# Rescue Browse and Read, and allow independent activity porting efforts to begin
# Remove hippocanvas from all other parts of Sugar, including activities
# Port Sugar core to hippocanvas
# Some time later, remove sugar-toolkit's GTK2 compatibility.
=== How to port ===
== API changes ==
== API changes ==
http://article.gmane.org/gmane.linux.laptop.olpc.sugar/30466
http://article.gmane.org/gmane.linux.laptop.olpc.sugar/30466
=== removal of keep button ===
== Scope ==
== Scope ==