Features/TableView Widget: Difference between revisions
m adjusted category sort alias |
|||
| Line 1: | Line 1: | ||
<noinclude>{{TOCright}} | <noinclude>{{TOCright}} | ||
[[Category:Feature Ready for Release Manager]] | [[Category:Feature Ready for Release Manager]] | ||
[[Category:Feature| | [[Category:Feature|TableView Widget]] | ||
</noinclude> | </noinclude> | ||
| Line 24: | Line 24: | ||
=== SmoothTable class === | === SmoothTable class === | ||
Model less implementation. The real widget | 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 | * 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 | * 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 == | ||