Features/GTK3: Difference between revisions

Line 92:

# How to handle each of the sugar-toolkit API changes (detailed in the following section)

# 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.

== API changes ==

Line 100:

I propose that once sugar-toolkit is ported and mostly operational, we run a 30-day window where API changes that have seen some kind of planning and discussion below can be made and committed.

=== ~~markup thing~~ ===

=== Plain text as the default for palettes ===

http://article.gmane.org/gmane.~~linux~~.~~laptop~~.~~olpc~~.~~sugar~~/~~30466~~

Sugar's palette classes currently accept strings, but then they pass those strings to GTK as markup (always, unconditionally). However, markup is only used in a handful of places, and this means that all users of palettes that draw in translations or strings from other sources which might contain characters such as < or > must escape their arguments, leading to big patches [http://article.gmane.org/gmane.comp.education.sugar.devel/32398 like this].

~~=== removal of keep button ===~~

As agreed [http://article.gmane.org/gmane.linux.laptop.olpc.sugar/30466 here], it would make more sense for palettes to pass those strings as standard text by default, and to have different functions to opt-in to receive markup processing. Then the excessive escaping would go, and the only users would have to escape would be those who use markup.

== ~~removal~~ of ~~old toolbars~~ ==

=== Removal of keep button ===

~~== Scope ==~~

Sugar-0.94 proposes the [http://article.gmane.org/gmane.linux.laptop.olpc.sugar/30771 removal of the Keep button], but the old KeepButton classes would be kept around for activities that directly use it. Porting sugar-toolkit to GTK3 would be a good time to remove these classes.

~~''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?''~~

== ~~How To Test~~ ==

== Removal of old toolbars ==

~~{{:{{PAGENAME}}~~/~~Testing}}~~

Sugar-0.86 [[Features/New_Toolbar_Design|redesigned activity toolbars]], with the new toolbars implemented by new classes, and the old classes being kept around so that old activities are not immediately broken. This would be a good opportunity to remove the long-deprecated old activity toolbar classes.

== Dependencies ==

''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, does your feature depend on completion of another feature owned by someone else or that you would need to coordinate, which might cause you to be unable to finish on time? Other upstream projects like Python?''

~~== Contingency Plan ==~~

Sugar would start depending on PyGObject built with gobject introspection support, GTK3, and (at the end of the transition) period would drop its dependencies on GTK2 and PyGTK.

~~''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~~.''

== 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.''

== Comments and Discussion ==

* See [[{{TALKPAGENAME}}|discussion tab for this feature]]

@@ Line 92: / Line 92: @@
 # How to handle each of the sugar-toolkit API changes (detailed in the following section)
 # 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.
 == API changes ==
@@ Line 100: / Line 100: @@
 I propose that once sugar-toolkit is ported and mostly operational, we run a 30-day window where API changes that have seen some kind of planning and discussion below can be made and committed.
-=== markup thing ===
+=== Plain text as the default for palettes ===
-http://article.gmane.org/gmane.linux.laptop.olpc.sugar/30466
+Sugar's palette classes currently accept strings, but then they pass those strings to GTK as markup (always, unconditionally). However, markup is only used in a handful of places, and this means that all users of palettes that draw in translations or strings from other sources which might contain characters such as < or > must escape their arguments, leading to big patches [http://article.gmane.org/gmane.comp.education.sugar.devel/32398 like this].
-=== removal of keep button ===
+As agreed [http://article.gmane.org/gmane.linux.laptop.olpc.sugar/30466 here], it would make more sense for palettes to pass those strings as standard text by default, and to have different functions to opt-in to receive markup processing. Then the excessive escaping would go, and the only users would have to escape would be those who use markup.
-== removal of old toolbars ==
+=== Removal of keep button ===
-== Scope ==
+Sugar-0.94 proposes the [http://article.gmane.org/gmane.linux.laptop.olpc.sugar/30771 removal of the Keep button], but the old KeepButton classes would be kept around for activities that directly use it. Porting sugar-toolkit to GTK3 would be a good time to remove these classes.
-''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?''
-== How To Test ==
+== Removal of old toolbars ==
-{{:{{PAGENAME}}/Testing}}
+Sugar-0.86 [[Features/New_Toolbar_Design|redesigned activity toolbars]], with the new toolbars implemented by new classes, and the old classes being kept around so that old activities are not immediately broken. This would be a good opportunity to remove the long-deprecated old activity toolbar classes.
 == Dependencies ==
-''What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, does your feature depend on completion of another feature owned by someone else or that you would need to coordinate, which might cause you to be unable to finish on time?  Other upstream projects like Python?''
-== Contingency Plan ==
+Sugar would start depending on PyGObject built with gobject introspection support, GTK3, and (at the end of the transition) period would drop its dependencies on GTK2 and PyGTK.
-''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.''
 == 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.''
 == Comments and Discussion ==
 * See [[{{TALKPAGENAME}}|discussion tab for this feature]]