105
edits
Changes
Jump to navigation
Jump to search
Line 22:
Line 22: + + + + + Line 32:
Line 37: + +
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.
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.
== Benefit to Sugar ==
== Benefit to Sugar ==
# PyGI is technologically better than PyGTK. It is a nicer way of calling into GObject-style libraries from Python that means less maintenance is needed upstream (PyGObject automates the creation of bindings to a degree much higher than PyGTK ever could, and automatically achieves more complete coverage).
# PyGI is technologically better than PyGTK. It is a nicer way of calling into GObject-style libraries from Python that means less maintenance is needed upstream (PyGObject automates the creation of bindings to a degree much higher than PyGTK ever could, and automatically achieves more complete coverage).
# PyGTK is no longer maintained; PyGI is actively maintained.
# The move to GTK3 allows us to [http://blog.tomeuvizoso.net/2011/05/time-to-port-your-python-application-to.html keep up with our GNOME neighbours], as they improve and refine the base technologies that we share.
# The move to GTK3 allows us to [http://blog.tomeuvizoso.net/2011/05/time-to-port-your-python-application-to.html keep up with our GNOME neighbours], as they improve and refine the base technologies that we share.
# The move to PyGI is expected to result in [http://blog.tomeuvizoso.net/2009/05/reducing-sugars-memory-usage.html lower memory usage and faster startup].
# The move to PyGI is expected to result in [http://blog.tomeuvizoso.net/2009/05/reducing-sugars-memory-usage.html lower memory usage and faster startup].
== Implementation Plan ==
== Implementation Plan ==
Sugar is divided into different components, many of which run in different processes. This means that we are able to
== API changes ==
== API changes ==