105
edits
Changes
Jump to navigation
Jump to search
Line 23:
Line 23: − + − + Line 110:
Line 110: + + + + + + + + + + + + + + + +
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. 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. As detailed below, this can be pulled off quite easily and in a way that will not drain resources.
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.
This project 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+.
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+.
#* 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.
#* 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.
=== Version number considerations ===
It goes without saying that such a migration would be the basis of a new major release. When this topic has been discussed before, people have toyed with the idea of calling the GTK3 version of Sugar "Sugar-1.0".
There are arguments for:
* This is undoubtedly a paradigm shift for Sugar, so a major bump to the version number is called for.
* It would make the change really obvious
And there are arguments against:
* Some people might interpret the number 1.0 as indicating a higher level of maturity than what the developers feel
* Some people want a much longer lead-up time to Sugar-1.0 so that the API can be refined/reworked/perfected
Tomeu, Simon and Marco agreed that the 1.0 version number could be used here, and communicated in a slightly different sense: we are really still in the first iteration and 1.0 will be when that first iteration reaches maturity, without big changes in the API. After 1.0 we can start working on what will be one day 2.0 which should be the second iteration of Sugar, hopefully using what we have learned during these years.
However, if the migration of sugar-toolkit, sugar, datastore, etc, takes more than 1 release cycle (which it probably will), at which point do we switch to the 1.0 name? Personally, I think sugar-toolkit must be the first item to be ported, and being the most outward-facing component (on the code level), this would be a good opportunity to pick up the 1.0 tag. Version 1.2 could then include GTK3 ports of the other components, and so on.
== API changes ==
== API changes ==