Re: Autocompletion



El dom, 06-10-2002 a las 00:48, Havoc Pennington escribió:
> Ricardo Fernández Pascual <ric users sourceforge net> writes:
> > 
> > The recent thread about a GnomeURIEntry ended without a real conclusion
> > about autocompletion.
> > 
> > I have decided to take Galeon's autocompletion classes, clean them up a
> > bit and post them here. I'm looking for a sponsor to add this to LibEgg,
> > if there is interest.
> > 
> ... 
> > If there is interest in developing this I'll continue cleaning up the
> > code and documenting it. I have written a small README (attached), but I
> > don't think that it makes a lot of sense yet.
> > 
> > I think that having this as part of libgnomeui is a good idea, to avoid
> > code duplication and inconsistencies between Galeon, Nautilus... and any
> > other Gnome app or component that needs autocompletion (like the future
> > file selection dialog).
> > 
> 
> I think this is a good feature for GTK, and the fact that it works for
> Galeon probably means it's pretty close to the right UI.  Definitely
> having nautilus/galeon location bar behave consistently would be nice.
> 
> I see lots of small things in the code to comment on, but on a high
> level, I think the autocomplete entry should be a subclass of GtkEntry
> rather than of hbox, so you don't have to duplicate the functions such
> as get/set_text. This may require GtkEntry changes but we can
> certainly make those if required.
> 

Don't look too close at the code, I thing it has a lot of cruft still.
Some code comes from galeon1 and it was far from clean.

I'll change it to be a subclass of GtkEntry. It will make things
cleaner.

> <thing I always say>
> Again, remember that libgnomeui should be a glue layer between GTK+
> and the desktop runtime. A general GUI feature that has no relation to
> the runtime always belongs in GTK+ (if it belongs anywhere), not in
> libgnomeui.
> 
> And over time, as the relations between apps and the runtime are
> standardized and documented (along the lines of some of the
> freedesktop.org stuff) and thus more stable/long-term, most bits can
> move to GTK+ and we should see libgnomeui shrink.
> 
> We want a coherent overall platform and API, you can't have that if
> you have GtkFoo and GnomeFoo for every widget.
> </thing I always say>
> 
> Some interesting GTK bugs:
>  
>  combo box redesign with links to discussion:
>    http://bugzilla.gnome.org/show_bug.cgi?id=50554
>    note that we want to replace GtkCombo with a nice autocompleting
>    entry and a better option menu.

There is a lot to read in the archives.

First, for what I see the proposed combo box only autocompletes from
what is already in the dropdown. That's not good for many applications,
because it is infeasible to populate the dropdown list with the whole
history list of galeon or the whole address book of evolution.

>  fix GtkEntry to make it easier to implement completion:
>    http://bugzilla.gnome.org/show_bug.cgi?id=69613
> 
> Also I swear there was a bug or some list discussion on extending
> GtkEntry to have an autocomplete feature built-in, but I can't find
> it.
> 
> I'll look at the code in more detail and send along some comments, if
> you want.
> 
> Havoc




-- 
Ricardo Fernández Pascual
ric users sourceforge net
Murcia. España.




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