Features/GTK3: Difference between revisions

No edit summary
Godiard (talk | contribs)
No edit summary
 
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<noinclude>{{TOCright}}
<noinclude>
[[Category:Feature Page Incomplete]]
[[Category:FeatureLanded|GTK3]]
[[Category:Feature|GTK3]]
</noinclude>
</noinclude>


Line 9: Line 8:


== Owner ==
== Owner ==
* This plan/proposal maintained by [[User:DanielDrake|Daniel Drake]] (other editors welcome!)
* This plan/proposal maintained by [[User:DanielDrake|Daniel Drake]] and [[User:Erikos|Simon Schampijer]]
* A number of developers will be needed at each stage to successfully execute this; Daniel offers his assistance for a coordination/oversight role if that would be useful.
* A number of developers will be needed at each stage to successfully execute this; Daniel offers his assistance for a coordination/oversight role if that would be useful.


== Current status ==
== Current status ==
* Targeted release: <b>0.96</b> (at least for sugar-toolkit port)
* Targeted release: <b>0.96</b> (the sugar-toolkit and sugar-artwork port)
* Last updated: (DATE)
* Last updated: 31.01.12
* Percentage of completion: XX%
* Percentage of completion: 35% (the sugar-toolkit and sugar-artwork port will count as 50% when finished)


At the Desktop summit, Raul Gutierrez Segales, Benjamin Berg and Paul Proteus successfully [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg22070.html prototyped] some of the ideas below. After only a few hours of effort, a minimal Sugar GTK3 activity was running alongside GTK2 activities. The plan below should therefore be quite credible, but some prerequisites remain.
At the Desktop summit, Raul Gutierrez Segales, Benjamin Berg and Paul Proteus successfully [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg22070.html prototyped] some of the ideas below. After only a few hours of effort, a minimal Sugar GTK3 activity was running alongside GTK2 activities. The plan below should therefore be quite credible, but some prerequisites remain.
Line 60: Line 59:
A prerequisite to porting a Sugar process, component or activity is to remove all its usage of hippocanvas. This library is unmaintained, would be painful to port to GTK3, and can be done better with standard GTK+ code at the Python level. Most users of HippoCanvas can switch to custom GtkContainer widgets.
A prerequisite to porting a Sugar process, component or activity is to remove all its usage of hippocanvas. This library is unmaintained, would be painful to port to GTK3, and can be done better with standard GTK+ code at the Python level. Most users of HippoCanvas can switch to custom GtkContainer widgets.


One complication is that hippo usage is not limited to Sugar's core; some activities use hippo, or they pull on sugar-toolkit classes which are implemented with hippo. These are: Chat (<em>please list others here</em>).
One complication is that hippo usage is not limited to Sugar's core; some activities use hippo, or they pull on sugar-toolkit classes which are implemented with hippo. These are: Chat, Speak (<em>please list others here</em>).


=== Theme porting ===
=== Theme porting ===
[[/Theme|Theme status.]]


One major internal change in GTK3 is the way that themes are designed. GTK2 allowed themes to be implemented with a special format in a gtkrc file, but GTK3 now requires that themes are implemented using CSS. Therefore another non-trivial prerequisite for a GTK3-based sugar release of any visual component is the porting of the theme.
One major internal change in GTK3 is the way that themes are designed. GTK2 allowed themes to be implemented with a special format in a gtkrc file, but GTK3 now requires that themes are implemented using CSS. Therefore another non-trivial prerequisite for a GTK3-based sugar release of any visual component is the porting of the theme.
Line 115: Line 116:
And there are arguments against:
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 might interpret the number 1.0 as indicating a higher level of maturity than what the developers feel
* Some developers have very specific ideas about what should be included in Sugar-1.0, even if development of such items is barely even on the horizon
* Some people want a much longer lead-up time to Sugar-1.0 so that the API can be refined/reworked/perfected
* 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."
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."


The migration of sugar-toolkit, sugar, datastore, etc, is likely to take more than 1 release cycle, but the above scheme can still apply. When each component is ported to GTK3, it would then pick up the 1.0 tag. For example, the first major release that includes any GTK3 may well include sugar-toolkit-1.0 (GTK3 ported) alongside sugar-datastore-0.96 (not yet ported).
However, current Sugar developers feel strongly that the changes described here are not significant to warrant a major version bump and have specific ideas about what should be included in a 1.0 release. Therefore, in the interest of being slightly less intrusive, this feature does not ultimately propose a version numbering change - it is planned that sugar-toolkit-0.96 will be released as the first with GTK3 support, and once we reach sugar-0.98, the next releases will be 0.100, 0.102, etc.


=== Retaining the 'sugar' module name ===
=== Retaining the 'sugar' module name ===
Line 181: Line 183:


In the event of problems in the GTK3 version of sugar-toolkit, activity authors have the (default) choice of staying with GTK2. The transition period before the GTK2 version is removed would obviously be extended in the face of significant problems with GTK3 version.
In the event of problems in the GTK3 version of sugar-toolkit, activity authors have the (default) choice of staying with GTK2. The transition period before the GTK2 version is removed would obviously be extended in the face of significant problems with GTK3 version.
== Documentation ==
* [[Features/GTK3/Development | Development page]]
* [[Features/GTK3/Porting | Activity porting guide]]


== Release Notes ==
== Release Notes ==
Line 188: Line 194:
This work would benefit from some focused attention at in-person meetings.
This work would benefit from some focused attention at in-person meetings.


See [[Features/GTK3/DesktopSummitActivities]] for some initial steps that could be taken at the desktop summit.
See [[Features/GTK3/Desktop Summit activities]] for earlier desktop summit ideas.
 
On September 10th-12th, a SugarCamp will be held in Paris. We will be working on this plan at the event, starting with the prerequisites.


On September 10th-11th, a SugarCamp will be held in Paris. We could work on this during or immediately after that event.
On October 28th-30th, a hackfest will be held in Prague with the specific purpose of implementing this plan: [[Marketing_Team/Events/Gtk3_Hackfest_2011]]


== Comments and Discussion ==
== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]
== Subpages ==
{{Special:PrefixIndex/{{PAGENAMEE}}/}}