Re: Why is GCompletion deprecated

[Milan Bouchet-Valat <nalimilan club fr>]

Le lundi 28 juin 2010 à 21:25 +0200, Xavier Claessens a écrit :
> How could I come up with a better API if:
> 1) You don't tell what's wrong with current?
> 2) You keep repeating completion is not used by app, and barely used 
> code shouldn't be included in GLib? If that was true, even a better API 
> should be rejected in glib... or is there something I didn't understand?

I think Emmanuele already listed the main issues with the current API:
>   • g_completion_new(): not bindable; requires at least a new version
> with a GDestroyNotify function for language bindings.
> 
>   • the GCompletionFunc doesn't have a data parameter, making it
> unbindable.
> 
>   • the GCompletion structure is completely exposed and cannot be
> extended or updated, hence we cannot add a GCompletionFuncData that
> takes a user data parameter, unless we use the struct alignment C
> trick,
> in which case the func pointers will be set to NULL even in valid
> cases.
> 
>   • the same applies for GCompletionStrncmpFunc.
> 
>   • the whole API uses untyped lists, which makes its use awkward from
> anything that's not C - and even in C it's odd to use, especially with
> regards to bookkeeping of the items.

So basically one would have to suggest an API more in key with the
current conventions and bindings-friendly.

What about providing something mixing search and completion from your
GtkLiveSearch proposal? These features are deeply related with e.g. the
advanced ways of searching (à la GNOME Do), allowing completion from
different parts of a string, the beginning of any word, escaping
accented characters...

The new API should be usable alone, or automatically tied to a couple
GtkEntry/GtkTreeView, so that only one completion API exists in
GLib/GTK.


Just my 2c