Features/TableView Widget: Difference between revisions

(10 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 ==

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

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 ~~in case of~~ using widgets ~~then~~ renders, we can reuse our ~~existed~~ custom widgets instead of coding sugarized cell renders

* 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 ~~its~~ hard to sugarize cells theme(we still have ugly progress bar for Journal entries), with new widget, we use just gtk.ProgressBar

* 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 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 ==
-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).
+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 in case of using widgets then renders, we can reuse our existed custom widgets instead of coding sugarized cell renders
+* 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 its hard to sugarize cells theme(we still have ugly progress bar for Journal entries), with new widget, we use just gtk.ProgressBar
+* 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 ==