Re: [Nautilus-list] [PATCH] location bar autocompletion

> In the current code the "return_value == FALSE" case implies that we
> skip auto-completion.

Right, because it means that the key wasn't handled by the entry.

> If the auto-completion code resides primarily in the event-after
> callback then the "return_value == FALSE" case will not exist (i.e. it
> will not have any effect, you can't skip something your not doing)...

The idea was that it would set some kind of flag to tell the event-after
callback that the key wasn't handled. I figured you'd connect before to set
a flag to say "event handled", connect after to clear the flag for the case
where it wasn't, and connect to "event-after" to do the work in the case
where the event was hanlded.

> Since I am still unclear on exactly what the "return_value == FALSE" is
> comprised of (I've only seen it occur with things like, for ex.,
> Gdk_Shift and this case is properly handled by the
> entry_would_have_inserted_characters () function), the attached patch
> only connects to event-after.

It's true that we ended up having to second guess GtkEntry anyway. Perhaps
you're right and there's no particular key we'll handle wrong. Just make
sure that you try all the keys on your keyboard, and that will cover most
everything I hope. Please try that.

> +    uint base_name_length;

Needs to be guint -- the fact that the old code was using uint was a bug.
But normally we use int for things like this even if all the value numbers
are nonnegative.

> +    current_path_length = strlen (current_path);
> +    user_location_length = g_utf8_strlen (user_location, -1);
> +    offset = current_path_length - user_location_length;

Looks like a recipe for disaster, doing math with byte counts (strlen) and
character counts (g_utf8_strlen).

Deal with the above, and I think you are ready to commit.

    -- Darin

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]