Features/TableView Widget: Difference between revisions

(15 intermediate revisions by 3 users not shown)

Line 1:

<noinclude>{{TOCright}}

[[Category:Feature ~~Page Incomplete~~]]

[[Category:Feature Accepted 0.88]]

[[Category:~~Feature~~|~~<Feature Name>~~]]

[[Category:FeatureObsoleted|TableView Widget]]

</noinclude>

Line 15:

== Current status ==

* Targeted release: 0.88

* Last updated: ~~Sat Nov 28 01~~:20:59 UTC ~~2009~~

* Last updated: Mon Jan 11 21:15:02 UTC 2010

* Percentage of completion: 75%

* Percentage of completion: 90%

== Detailed Description ==

''~~Expand on the summary, if appropriate~~. ~~A couple of sentences suffices to explain the goal, but the more details you can provide the better~~.''

Feature introduced two new classes - SmoothTable and TableView.

=== SmoothTable class ===

Model less implementation. The real widget consists of ''visible-columns'' * (''visible-rows'' + 2) identical widgets (constructor is passed to SmoothTable during creation) and while scrolling (by pixel); SmoothTable shifts these widgets.

=== TableView class ===

Just adds gtk.TreeModel support.

== Benefit to Sugar ==

''What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''

''~~Make sure~~ to ~~note here as well if this feature has been requested by a specific deployment~~, ~~or if it has emerged from a bug report~~.''

Standard gtk components are not designed to be lazy. Third party widgets, I managed to find, uses scheme with renders (like gtk components), introduced component uses widgets instead (could have performance penalties, I guess, in common case but we don't have many rows in Journal view, so should be ok for us).

Benefits we have for such scheme:

* coding cells is more useful by using widgets than renders, we can reuse our existing custom widgets instead of coding sugarized cell renders

* in some cases it's hard to sugarize cells theme (we still have ugly progress bar for Journal entries), with new widget, we use just gtk.ProgressBar

== Scope ==

Line 31:

Line 43:

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

Nothing.

== How To Test ==

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

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

Nothing will be changed in case of user experience.

== Dependencies ==

@@ Line 1: / Line 1: @@
 <noinclude>{{TOCright}}
-[[Category:Feature Page Incomplete]]
+[[Category:Feature Accepted 0.88]]
-[[Category:Feature|<Feature Name>]]
+[[Category:FeatureObsoleted|TableView Widget]]
 </noinclude>
@@ Line 15: / Line 15: @@
 == Current status ==
 * Targeted release: 0.88
-* Last updated: Sat Nov 28 01:20:59 UTC 2009
+* Last updated: Mon Jan 11 21:15:02 UTC 2010
-* Percentage of completion: 75%
+* Percentage of completion: 90%
 == Detailed Description ==
-''Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better.''
+Feature introduced two new classes - SmoothTable and TableView.
+=== SmoothTable class ===
+Model less implementation. The real widget consists of ''visible-columns'' * (''visible-rows'' + 2) identical widgets (constructor is passed to SmoothTable during creation) and while scrolling (by pixel); SmoothTable shifts these widgets.
+=== TableView class ===
+Just adds gtk.TreeModel support.
 == Benefit to Sugar ==
-''What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''
-''Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.''
+Standard gtk components are not designed to be lazy. Third party widgets, I managed to find, uses scheme with renders (like gtk components), introduced component uses widgets instead (could have performance penalties, I guess, in common case but we don't have many rows in Journal view, so should be ok for us).
+Benefits we have for such scheme:
+* coding cells is more useful by using widgets than renders, we can reuse our existing custom widgets instead of coding sugarized cell renders
+* in some cases it's hard to sugarize cells theme (we still have ugly progress bar for Journal entries), with new widget, we use just gtk.ProgressBar
 == Scope ==
@@ Line 31: / Line 43: @@
 ==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.''
+Nothing.
 == How To Test ==
 {{:{{PAGENAME}}/Testing}}
 == 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.''
+Nothing will be changed in case of user experience.
 == Dependencies ==