Changes

<noinclude>{{TOCright}}

<noinclude>{{TOCright}}

[[Category:Feature Ready for Release Manager]]

[[Category:Feature Accepted 0.88]]

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

[[Category:FeatureObsoleted|TableView Widget]]

</noinclude>

</noinclude>

== Current status ==

== Current status ==

* Targeted release: 0.88

* Targeted release: 0.88

* Last updated: Sat Nov 28 21:15:02 UTC 2009

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

* Percentage of completion: 90%

* Percentage of completion: 90%

=== SmoothTable class ===

=== SmoothTable class ===

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

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

=== TableView class ===

== Benefit to Sugar ==

== 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:

Benefits we have for such scheme:

* coding cells is more useful by 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 ==

== Scope ==