GNOME Bugzilla – Bug 551202
GtkCompletion's GtkCellLayout interface is broken
Last modified: 2018-02-10 03:44:53 UTC
Please describe the problem: GtkCompletion implements CellLayout only half-heartedly. The model set by the user (let's call it user_model) is wrapped in a filter (let's call it filter_model) which is then used by a TreeView(Column). The latter is part of the private data. When setting an extraction function (let's call it data_func) using gtk_cell_layout_set_cell_data_func, GtkCompletion's implementation of this function simply installs data_func in the TreeViewColumn which operates on the private filter_model. Hence is called with the model and iter that belongs to private filter_model. Similarly, the match_selected signal is called both from GtkCompletion and from GtkEntry using the private filter_model, rather than user_model. There are two problems with this behaviour: 1. It leaks the private filter_model. 2. It assumes data_func and the handler of the match_selected signal blindly take the model that's passed to them and use the GtkTreeModel API and extract data by using column numbers. For custom models that do not have the concept of column numbers but merely hold a list of records it is impossible to use this API. This is quite a limitation in my language binding Gtk2Hs: the match_selected handler cannot be used since the iter refers to a row in filter_model and not in user_model. It would be possible to translate the iter from filter_model to user_model, but that assumes knowledge about how GtkCompletion is implemented. Steps to reproduce: 1. Set a data extraction function with cell_layout_set_cell_data_func or 2. install a handler for match_selected. 3. Observe that the model passed to the installed function is model_filter and not user_model. Actual results: Expected results: I want to receive user_model and an iter that points into the user_model. Does this happen every time? Yes! Other information: Passing the user_model and an iter into user_model to data_func and to the handler of match_selected is a transparent fix since the data can still be extracted by column using this information, albeit from the user_model.
Created attachment 118205 [details] [review] Only call user code with the user's model. The patch translates the filter_model to the user_model and the iter into the filter_model into an iter into the user_model. Two new fields in the private part of Completion are necessary to hold the user's data_func and it's data argument since I needed to add a new indirection function that is called from TreeView which does the translation. I'm not sure this patch is up to standard. I'm setting the two new private fields to NULL on initialisation, although this is not strictly necessary. I also set them to NULL when the data_func is removed in clear_attributes.
Couldn't you yourself translate the iterator from the filter_model to the user_model in the callback? Like this: completion.set_model(model) ... def match_selected_cb(completion, filter_model, iter): child_iter = filter_model.convert_iter_to_child_iter(iter) print model.get_value(child_iter, 0) ... completion.connect('match-selected', match_selected_cb) I don't know if the current design is intentional or not, but it is quite nice that you are given the filtered model in the match-selected callback because you can then see exactly which completions GtkEntryCompletion displays.
(In reply to comment #2) > Couldn't you yourself translate the iterator from the filter_model to the > user_model in the callback? Like this: [..] Yes, I could. However, it is not obvious from the documentation that my installed function is called with a different model, in particular, a filter model. Hence, it is not clear that I need to call filter_model_convert_iter_to_child_iter. > I don't know if the current design is intentional or not, but it is quite nice > that you are given the filtered model in the match-selected callback because > you can then see exactly which completions GtkEntryCompletion displays. Do you mean I can check the filter model to see which entries are currently selected? Yes, maybe that is useful. I think the problem I'm trying to highlight with this bug report is that either the documentation should state that GtkEntryCompletion uses a TreeModelFilter internally (which breaks the abstraction) or that it should be transparent to the user in which case it should translate all iterators to the user model. Changing the documentation might be a simpler fix since this would not break any programs. Futhermore, I expect other widgets to be similarly sloppy with the Layout interface.
(In reply to comment #3) > I think the problem I'm trying to highlight with this bug report is that either > the documentation should state that GtkEntryCompletion uses a TreeModelFilter > internally (which breaks the abstraction) or that it should be transparent to > the user in which case it should translate all iterators to the user model. > > Changing the documentation might be a simpler fix since this would not break > any programs. Futhermore, I expect other widgets to be similarly sloppy with > the Layout interface. I think so too. Even if the current behavior is not the intended one it is probably to late to change it anyway. There might be apps out there that rely on the model given in the callback to be filtered. They would break silently in very hard to debug ways.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.