105
edits
Changes
no edit summary
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.
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, making it a huge task, even though the vast majority of code is trivial to port. 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.
For the most part, the port from PyGTK to PyGI only involves changing the names that are used to access methods and constants. PyGI uses a slightly different and more consistent naming scheme to wrap GTK+.
import gtk
gtk.MessageDialog(None, 0, gtk.MESSAGE_INFO, gtk.BUTTONS_CLOSE, "Hello World").run()
The above PyGTK code rewritten as PyGI is:
from gi.repository import Gtk
Gtk.MessageDialog(None, 0, Gtk.MessageType.INFO, Gtk.ButtonsType.CLOSE, "Hello World").run()
PyGI provides a script which can be used to automate much of the conversion.
The move from GTK2 to GTK3 is also expected to be unproblematic, because the vast majority of code does not need any changes - most GTK3 API/ABI is identical to GTK2. The cases which do require some intervention to solve will take some time, but the changes are [http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html well documented] and the number of cases encountered should be low.
== Benefit to Sugar ==
== Benefit to Sugar ==
# How to port from PyGTK/GTK2 to PyGI/GTK3.
# How to port from PyGTK/GTK2 to PyGI/GTK3.
#* This basically involves reading the [https://live.gnome.org/PyGObject/IntrospectionPorting PyGObject porting documentation], using pygi-convert.sh, then checking the result.
#* This basically involves reading the [https://live.gnome.org/PyGObject/IntrospectionPorting PyGObject porting documentation], using pygi-convert.sh, then checking the result.
#* The [http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html Migrating from GTK+ 2.x to GTK+ 3] should also be read.
== API changes ==
== API changes ==