628
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − + Line 15:
Line 15: − + − + − + + + + + + + + + + − ''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?'' − + + + + +
Features/TableView Widget (view source)
Revision as of 16:31, 5 November 2013
, 16:31, 5 November 2013no edit summary
<noinclude>{{TOCright}}
<noinclude>{{TOCright}}
[[Category:Feature Page Incomplete]]
[[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 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 ==
''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 ==
== Scope ==