Line 22: |
Line 22: |
| | | |
| == Benefit to Sugar == | | == Benefit to Sugar == |
− | ''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?''
| |
| | | |
− | ''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 of 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 ok for us). |
| + | |
| + | 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 |
| + | * 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 |
| | | |
| == Scope == | | == Scope == |