After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 551589 - GtkEntryCompletion does not always obeys the return value of match_func
GtkEntryCompletion does not always obeys the return value of match_func
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkEntry
2.14.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 547899
 
 
Reported: 2008-09-09 23:37 UTC by Diego Escalante Urrelo (not reading bugmail)
Modified: 2018-02-10 03:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test showing the bug (1.33 KB, text/x-python)
2008-09-09 23:38 UTC, Diego Escalante Urrelo (not reading bugmail)
Details

Description Diego Escalante Urrelo (not reading bugmail) 2008-09-09 23:37:40 UTC
In epiphany, I wanted to limit the number of matches drawn, since the completion can't be told to call match_func ONLY until N matches are found, I wrapped my match_func with a count, so after N return values that were 'TRUE' i will return FALSE before anything happens, like this:

static gboolean
match_func_wrapper (GtkEntryCompletion *completion,
                const char *key,
                GtkTreeIter *iter,
                gpointer data)
{
        gboolean ret = FALSE;
        EphyLocationEntryPrivate *priv = ((EphyLocationEntry *) data)->priv;

        if (priv->matches_count > MAX_MATCHES)
                return FALSE;

        ret = priv->match_func(completion, key, iter, data);

        if (ret)
                priv->matches_count++;

        return ret;
}

Yes yes, matches_count begins as 0 and etc etc, this is just the real life snippet i wanted to show, I'm attaching a python testcase that shows the bug.

The bug: after adding this "early return", the completion popup held only 1 result no matter there were more matches. Only in the second loop of match_func it would show all the MAX_MATCHES matches. Like this:

User types: 'e':
| e                |
-------------------
  |http://e.com    |
  -----------------

User deletes 'e', types 'e' again:
| e                |
-------------------
  |http://e.com    |
  |http://e2.com   |
  |http://e3.com   |
  |http://e4.com   |
  |http://e5.com   |
  -----------------

See attached python test. Try writing 't' (that is supposed to show all the matches up to the set limit) and you'll see just 1 match, now delete and try again and you'll see N-1 matches, the last return True is being ignored.
Comment 1 Diego Escalante Urrelo (not reading bugmail) 2008-09-09 23:38:25 UTC
Created attachment 118396 [details]
Test showing the bug
Comment 2 Matthias Clasen 2018-02-10 03:28:24 UTC
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.