Having an explicit property for this will make it easier
to have a hover style only for rows which are activatable
or selectable.
Rows are selectable by default, to preserve compatibility.
This will let us theme activatable rows differently.
We also avoid emitting the ::row-activated signal for
rows that are not activatable. For compatibility reasons,
rows are activatable by default.
https://bugzilla.gnome.org/show_bug.cgi?id=733112
This commit adds API for dealing with multi-selection. It is identical
to the flow box API for this purpose. The implementation is still limited
to single-selection, and will be updated in subsequent commits.
keyboard navigation didn't support activation since we moved
the keynav to the child row widgets. We fix this by adding a
activate signal handler for the row and setting
widget_class->activate_signal to it.
https://bugzilla.gnome.org/show_bug.cgi?id=707778
... to make it possible to insert rows in the middle of the list without having
to fiddle with the sort functions. One of the first users is going to be Glade.
https://bugzilla.gnome.org/show_bug.cgi?id=705558
This was added from https://bugzilla.gnome.org/show_bug.cgi?id=691979
where it was wanted in order to get a "all children filtered" kind
of row. However, the solution is not really generic enough, because
filtering can happen for other reasons than a full refilter (i.e. due
to a row change), and the partial fix you can get by counting children
after refilter can be achieved by manually doing it whenever you manually
called refilter anyway.
Its possible we should have some better solution for the "empty state"
though.
Now that we automatically set up the focus_vadjustment we only
need the adjustment to handle the page-up/down scroll length correctly.
We use parent_set to automatically pick up the adjustment from a
scrollable (i.e. viewport) parent which makes add_to_scrolled useless, so
it can be removed.
