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 395964 - GtkEntryCompletion's prefix calculation is case sensitive.
GtkEntryCompletion's prefix calculation is case sensitive.
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkEntry
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 361599 489281 680288 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-13 00:13 UTC by Peter Johanson
Modified: 2018-05-02 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Peter Johanson 2007-01-13 00:13:27 UTC
I'm doing some work with GtkEntry, and GtkEntryCompletion, and have what seems to be a bug in the behaviour of the inline completion. In particular, the default matching function uses a normalized, case folded string comparison for determining matches, but the prefix detection code in gtk_entry_completion_compute_prefix just uses g_str_has_prefix on the original strings. Here's an example to demonstrate:

completion model has the following two strings in the model:
BAM
BOOM

Steps:
1. User types in "ba".
2. The completion dropdown shows only the item "BAM", as this is a match.
3. No prefix text is set.

Compared to:
1. User types in "BA"
2. The completion dropdown shows only the item "BAM", as this is a match.
3. No prefix text of "M" is appended, so the entry now reads "BAM".

This may actually be the intended behaviour, maybe not. I can think of two potential fixes if this is deemed a bug:

1. Change gtk_entry_completion_compute_prefix to first normalize and case fold the strings before calling g_str_has_prefix. The downside to this I could see is the case where a user has called gtk_entry_completion_set_match_func with their own function which behaves differently, is case sensitive, etc.

2. Provide new API on GtkEntryCompletion along the lines of gtk_entry_completion_set_prefix_func and the prefix function would be called with a key and a TreeIter, and be expected to calculate and return the prefix for the item. Haven't thought out the details on this, but this seems like the more complete fix.

Thoughts? NOTABUG?
Comment 1 Matthias Clasen 2007-01-14 04:55:49 UTC
hmm, while this was not explicitly intended when I added the inline completion,
I have a hard time seeing how we can do better than this. If the user types 'ba'
and the possible completions have 'BAM', what character would you insert ?
completing to 'baM' is wierd. Completing to 'bam' might be better, but in both
cases, you end up with a text that is not in the list of possible completions.
And what do you do if there are case variations among the possible completions,
e.g. if there are 'BAM' and 'bamama', would you insert 'M' or 'm' ?
Comment 2 Sven Neumann 2007-10-23 12:27:50 UTC
*** Bug 489281 has been marked as a duplicate of this bug. ***
Comment 3 Daniel Boles 2017-08-28 00:49:36 UTC
*** Bug 361599 has been marked as a duplicate of this bug. ***
Comment 4 Daniel Boles 2017-08-28 00:49:43 UTC
*** Bug 680288 has been marked as a duplicate of this bug. ***
Comment 5 GNOME Infrastructure Team 2018-05-02 14:26:44 UTC
-- 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/275.