GNOME Bugzilla – Bug 309035
gtkentry completion API support for getting dropdown item selection
Last modified: 2018-05-02 14:10:26 UTC
In Epiphany we need to be able to delete entries from the completion dropdown list by pressing the Delete key. (See bug 117892) Please make this possible with the gtkentry completion API.
bug 314754 also requires other keypresses (Ctrl+Enter) to be retrieved from the dropdown.
AFAICS the keypress event is already forwarded from the popup to the entry. So if you don't want to implement 'delete' in GtkEntryCompletion itself, what's needed here is API to check if popup is shown and if so, which item or action is selected from it.
adjusting summary
ping
Created attachment 85153 [details] [review] a patch Here is a patch that adds a GtkEntryCompletion::key-event signal that can be used to implement delete. Not sure if it is good for much else. It is not quite perfect for that purpose, since deleting a completion removes the selection, instead of moving it to the next selection. Unfortunately, implementing delete directly inside GtkEntryCompletion is not possible, since the model is just a GtkTreeModel and thus effectively readonly. The patch also fixes a bug in the current code: the model/iter passed to match_selected are the internal filtermodel, not the user-provided model.
cc'ing Xan
Can we get this in for 2.22?
Ping?
Still valid.
Review of attachment 85153 [details] [review]: I started looking at this patch in order to update it (gtkentrycompletion code has changed a bit), but I have a few doubts. ::: gtk/gtkentrycompletion.c @@ +1817,3 @@ + GtkTreeModel **model, + GtkTreeIter *iter, + gint *index_) What was the purpose if this index_ variable? @@ +1841,3 @@ + gtk_tree_model_filter_convert_iter_to_child_iter (completion->priv->filter_model, iter, &filter_iter); + } + GtkTreeModel *filter_model; At least now, there is a problem with this (not sure if originally it was the case): if the if clause is FALSE then model and iter are not initialized, so during the signal emission things go wrong. Maybe in such case this function should return FALSE?
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.
(In reply to Matthias Clasen from comment #11) > If this issue is still important to you and > still relevant with GTK+ 3.22 or master, #117892 is still important to me and depends on this, so I'd like this to be reopened. > please consider creating a gitlab issue for it. I'd be happy to do that, but I'm not sure how I can make the Epiphany report on bugzilla depend on the GTK+ one on gitlab. Also isn’t it a shame to lose the history here?
(In reply to Alexandre Franke from comment #12) > (In reply to Matthias Clasen from comment #11) > > If this issue is still important to you and > > still relevant with GTK+ 3.22 or master, > > #117892 is still important to me and depends on this, so I'd like this to be > reopened. Done. > > please consider creating a gitlab issue for it. > > I'd be happy to do that, but I'm not sure how I can make the Epiphany report > on bugzilla depend on the GTK+ one on gitlab. You can link to it. > Also isn’t it a shame to lose the history here? The history of this product in Bugzilla will remain available until bugzilla.gnome.org exists.
Is this bug really about what its title says, getting the currently active item - or is it really about having a keybinding to delete the currently focussed item? If the former, then Bug 778626 is a dupe.
*** Bug 778626 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/249.