105
edits
Changes
Jump to navigation
Jump to search
Line 60:
Line 60: − + + + + + + + + + + + + + Line 74:
Line 86: + + + + + + + Line 86:
Line 105: + + − − ==UI Design== − ''Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.'' − − == User Experience == − ''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.'' Line 104:
Line 119: − − == Documentation == − ''Is there upstream documentation on this feature, or notes you have written yourself? Has this topic been discussed in the mailing list or during a meeting? Link to that material here so other interested developers can get involved.'' Line 112:
Line 124: − +
no edit summary
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.
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
If the community has strongly desires it, it would be possible maintain the <tt>sugar</tt> module name through a Python trick which could be deployed during the transition period, and then removed once the GTK2 version is dropped. Here is how it could be done:
* The new GTK3 version of sugar toolkit would be installed with name <tt>sugar</tt>, and the old GTK2 version would be installed with name <tt>sugar_gtk2</tt>.
* Before <tt>sugar-activity</tt> imports sugar.activity (or any other sugar-toolkit class), it would look for an empty file called "GTK3_PORTED" in the activity's directory. If present, the GTK3_PORTED environment variable would be set.
* sugar/__init__.py would then include the following code snippet:
import os
import sys
if not 'GTK3_PORTED' in os.environ:
import sugar_gtk2
sys.modules["sugar"] = sugar_gtk2
* The result is that all unported/unmodified activities (without the GTK3_PORTED file) would <tt>import sugar.foo</tt> as before, but the above trick that modifies Python's module table would result in them (transparently, magically, automatically) being redirected to sugar_gtk2.foo.
* At the end of the transition period, sugar_gtk2 would be deleted in entirity, the above addition to sugar/__init__.py would be dropped, and activities could drop the GTK3_PORTED files at their leisure.
=== Proposed plan of action ===
=== Proposed plan of action ===
The steps below prioritise the porting of sugar-toolkit, as this is where Sugar would see the most immediate benefit: the revival of Browse and Read. The steps that follow can largely be parallelised.
# Remove hippocanvas from sugar-toolkit
# Remove hippocanvas from sugar-toolkit
=== How to port ===
=== How to port ===
I plan to start a page at [[Features/GTK3/Porting]] that details the porting process, that could be provided as documentation to anyone involved in these efforts (including thsoe working on porting Sugar core, but also those working on activities). The content covered will be:
# How to remove hippo and what to replace it with (links to commits that have done this for other activities, etc)
# How to select the GTK3 version of sugar-toolkit
# 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.
== API changes ==
== API changes ==
=== removal of keep button ===
=== removal of keep button ===
== removal of old toolbars ==
== Scope ==
== Scope ==
''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?''
''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 ==
== How To Test ==
{{:{{PAGENAME}}/Testing}}
{{:{{PAGENAME}}/Testing}}
== Dependencies ==
== Dependencies ==
== Contingency Plan ==
== Contingency Plan ==
''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.''
''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 ==
== Release Notes ==
== Comments and Discussion ==
== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page. -->
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]