We simply use the Tracker DBus api here, caching and direct
access that come with libtracker-sparql are probably not needed
here. Based on a patch by Martyn Russell.
https://bugzilla.gnome.org/show_bug.cgi?id=658272
gtk_tree_model_filter_free_level() should always release ref on parent
unless the parent has been removed in the child model. The unit tests
added in the previous commit test this.
If the level to be reordered did not contain an elt with offset == 0
(for example if that node was hidden), the first reference was not
correctly transferred.
A unit test for this has been added in a previous commit.
Handle dead keys in special_ucs_table and have them converted by
UCKeyTranslate(), so all dead key combinations can be entered.
Later, this should be handled in the input method, just as it's
done for X11/Win32.
This is due to the special handling for filter functions that depend
on child level state. If the parent level of a level is the root level,
the level cannot be removed from the cache. Any change in this level
can cause its parent in the root level to become visible again.
The most important change is that the function now properly releases
any external ref count and propagates these changes to the child model.
If a node is removed due to a filtering action, we now properly release
all external reference counts for its hierarchy of child nodes.
Apart from that, the function has been restructured to remove code
duplication.
Finally, there is still some doubt whether there are more calls to
gtk_tree_model_filter_free_level() which need unref_external set to TRUE.
Should be helpful when debugging this thing. Perhaps this needs to
be properly integrated in G_DEBUG/GTK_DEBUG, but currently I do not see
the need to.
There was still a discrepancy between the comments and the code about when
exactly a level was to be removed. The rule is now set on that for a level
to be removed its zero_ref_count as well as the zero_ref_count of its
parent has to be zero.
The code sets old_adj_ptr to the location containing the old weak ref,
but then wants to remove a weak ref from &view->old_hadj, causing warnings
when disposing the widget.
