Line 1: |
Line 1: |
| <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> |
| | | |
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 == |
Line 24: |
Line 24: |
| === SmoothTable class === | | === SmoothTable class === |
| | | |
− | Model less implementation. The real widget consist of ''visible-columns'' * (''visible-rows'' + 2) identical widgets(constructor is beeing passed to SmartTable while creation) and while scrolling(per line, not per row) class 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 === |
Line 32: |
Line 32: |
| == 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 == |