Re: Autocompletion

[Kristian Rietveld <kris gtk org>]

On Sun, 2002-10-06 at 13:26, Ricardo Fernández Pascual wrote:
> 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.

The proposed combo box there is really outdated and should not be looked
at (:. My combo box in CVS also only completes from the list in the
dropdown, but that list is actually a GtkTreeModel, which can be used at
more places. So I think it's a bit less of an issue to put the entire
history list in there.



	Kris

> 
> >  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.
> 
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers