Line 1: |
Line 1: |
| <noinclude>{{TOCright}} | | <noinclude>{{TOCright}} |
− | [[Category:Feature Page Incomplete]] | + | [[Category:Feature Accepted 0.88]] |
− | [[Category:Feature|<Feature Name>]] | + | [[Category:FeatureObsoleted|TableView Widget]] |
| </noinclude> | | </noinclude> |
| | | |
Line 15: |
Line 15: |
| == Current status == | | == Current status == |
| * Targeted release: 0.88 | | * 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 == | | == 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 == | | == 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 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 == | | == Scope == |