Merge lp:~teemperor/granite/table-view into lp:~elementary-pantheon/granite/granite
Status: | Work in progress |
---|---|
Proposed branch: | lp:~teemperor/granite/table-view |
Merge into: | lp:~elementary-pantheon/granite/granite |
Diff against target: |
454 lines (+407/-1) 4 files modified
demo/GraniteDemo.vala (+42/-1) lib/CMakeLists.txt (+2/-0) lib/Views/Table.vala (+333/-0) lib/Views/TableItem.vala (+30/-0) |
To merge this branch: | bzr merge lp:~teemperor/granite/table-view |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
xapantu (community) | Needs Information | ||
Review via email: mp+240380@code.launchpad.net |
Description of the change
We have quite a lot of implementations of widgets that do nothing more than displaying a list of items. A good example is the keyboard-plug which has at least 5 of those widgets and all those widgets are reimplemented from scratch.
This is especially annoying since on each review you have to recheck if the lists work correctly to figure out minor problems as seen here: https:/
This branch introduces a widget that displays a Gee.List and in a MVC-compatible way.
The advantages are:
* Better performance as we can fine-tune this widget to not fire item_changed events if they are not necessary.
* Less code and less time spent with testing list-implementa
* Design-changes regarding lists can be implemented easier by just changing the code here in granite. This also allows that all third-party developers are automatically updated to the new design if they use this widget.
See the granite-demo under Static notebook -> "Table"-tab and look at stdout to see it in action.
Unmerged revisions
- 806. By Raphael Isemann
-
We can now select items from the code
- 805. By Raphael Isemann
-
Everything works as expected, but we are still firing too many item-changes
- 804. By Raphael Isemann
-
Implemented up-down (only for the underlying list)
- 803. By Raphael Isemann
-
We only accept lists now
- 802. By Raphael Isemann
-
First version of the new Table-class
Hum, in what way is that better than the classic MVC approach of a GtkListViem/ GtkTreeView with a custom renderer?