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.
The button press/release handlers did invariably return FALSE, even
though it shouldn't if a row was found on the event coordinates. Also,
use GDK_EVENT_* defines for the return values.
The 'direction' parameter to gtk_widget_keynav_failed() is based on
gtk_list_box_move_cursor()'s 'count' parameter. However if the passed
in movement is GTK_MOVEMENT_DISPLAY_LINES, 'count' is modified by
the keynav handling and will always be 0. To avoid messing up the
'direction' parameter, use a local variable for keynav handling and
leave 'count' untouched.
https://bugzilla.gnome.org/show_bug.cgi?id=709687
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
We already take care to not track headers when the listbox is hidden,
because that can be very expensive during creation, so we might as
well skip reseparate() too. The only time we don't want to skip it
is when we're about to show the list.
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.
Unhighlight rows if they are removed.
Drop the automatic drag motion based auto-scrolling. This is not really
right, as it e.g. hardcodes auto-scroll regions and assumes we're the only
widget inside the scrolled container. Its also imho in the wrong place,
autoscrolling if any should be done on the scrolled-window or viewport.
All the removed code is implementable outside Gtk+ though.
