Re: Introducing GtkTreeModelFilter
- From: Owen Taylor <otaylor redhat com>
- To: Kristian Rietveld <kris gtk org>
- Cc: GTK Development list <gtk-devel-list gnome org>
- Subject: Re: Introducing GtkTreeModelFilter
- Date: Sun, 29 Dec 2002 21:34:04 -0500 (EST)
Kristian Rietveld <kris gtk org> writes:
> * filter specific rows, based on data from a "visible column", a column
> storing booleans indicating whether the row should be filtered or not,
> or based on the return value of a "visible function", which gets a
> model, iter and user_data and returns a boolean indicating whether the
> row should be filtered or not.
What's the relationship between the visible function and the
visible column? Can you set both at once? (The visible column
can be trivially implemented in terms of a visible function,
so perhaps one-or-the-other-but-not-both makes the most sense?)
> * modify the "appearance" of the model, using a modify function. You
> pass in the number of columns you want to have, together with the GTypes
> and a modify function. For each row, the modify function will be called,
> with a model, iter, GValue, column number, and user_data. The modify
> function should set a correct value in the GValue, which will be shown
> in the model. This is extremely powerful and allows for just changing
> some values and also for creating a completely different model based on
> the given child model. It's a bit difficult to explain this, you would
> just have to see this in action.
This seems like a pretty powerful feature, but, I have some
reservation about it too:
- It seems to largely duplicate the functionality of
gtk_tree_view_column_set_cell_data_func(); both allow
you to put in a function that munges the model values
in an abtrary
- It sounds like it would make a program rather hard to understand,
in that you have two sets of different model columns to
think about it.
Are there some good examples of when it comes in handy?
> Would it be a good idea to make my data really private using Owen's cool
> GObjectPrivate thing?
Yes (when we have it). I've arrived at the opinion that
it almost never makes sense to have public data members.
> Sidenote: you can set a modify or (filter function/filter column) only
> *once*.
Why? Would it be hard to change? These types of restrictions
tend to seem harmless, but often are a real pain for things
like GUI builders.
> typedef void (* GtkTreeModelFilterModifyFunc) (GtkTreeModel *model,
> GtkTreeIter *iter,
> GValue *value,
> gint column,
> gpointer data);
I think you should swap value and column in the ordering here,
since the iter/column together specify the piece of data to
retrieve.
> GType gtk_tree_model_filter_get_type (void);
> GtkTreeModel *gtk_tree_model_filter_new (GtkTreeModel *child_model,
> GtkTreePath *root);
Similar to the question above, would it be possible to have
set_model(), set_root() functions? Mandatory arguments to the
constructor, can be done as construct-only properties, but
language bindings (and GUI builders) are happiest if there
are no mandatory arguments at all.
> void gtk_tree_model_filter_set_modify_func (GtkTreeModelFilter *filter,
> gint n_columns,
> GType *types,
> GtkTreeModelFilterModifyFunc func,
> gpointer data,
> GtkDestroyNotify destroy);
Hmmm, there is some argument that the API here for providing the
types should parallel gtk_list_store_new/newv.
> /* conversion */
> void gtk_tree_model_filter_convert_child_iter_to_iter (GtkTreeModelFilter *filter,
> GtkTreeIter *filter_iter,
> GtkTreeIter *child_iter);
I think this function makes sense, but it is probably worth noting in
the API docs that this function has to convert the iter to a path and
back, since otherwise people may think that it is more efficient
than the path version and jump through hoops to use it instead.
> void gtk_tree_model_filter_refilter (GtkTreeModelFilter *filter);
> void gtk_tree_model_filter_clear_cache (GtkTreeModelFilter *filter);
What do these do?
Generally, looks really sensible, straightforward and useful.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]