Re: [Galeon-devel] Re: Galeon-Mozilla thread on nautilus-list from 2002 April

[Ricardo Fernández Pascual <ric users sourceforge net>]

El vie, 23-08-2002 a las 19:22, Luis Villa escribió:
> On Fri, 2002-08-23 at 13:11, Ricardo Fernández Pascual wrote:
> > One of my goals when rewriting galeon's bookmark code was to keep it as
> > independent of galeon as possible. It currently is a (static) lib that
> > can be compiled without the rest of galeon. This was done for
> > maintainability reasons only.
> > 
> > So, the current bookmark library does not depend on galeon. However, it
> > has been designed with a web browser in mind, and I'm not sure that it
> > would be useful for a file manager. 
> 
> Might be interesting to look at, at least. May I ask how it is 'designed
> for a web browser' in some way that might not be appropriate for a file
> manager? Granted, I hardly use bookmarks at all in galeon, and not at
> all in nautilus, but I'm curious to know what you think the differences
> are.

Some things like "smartbookmarks" don't make sense in nautilus.

Also, I never used bookmarks in a file manager so I don't know what else
could be needed. (who uses bookmarks in a file manager?)

> > In galeon2, the autocompletion system is also independent of galeon, and
> > actually i had thought about cleaning it and the location entry widget
> > and proposing them to libegg. It could be useful for entering filenames
> > or urls.
> > 
> > I wanted first to try to improve its performance. It currently takes a
> > lot of time building the GtkTreeView and GtkListStore to show possible
> > alternatives.
> 
> It would be cool to get it in, but it's definitely nearly unusably slow
> ATM, at least in my (admittedly now very old) version of galeon2. Has
> performance improved in the last couple of months?

It improved a bit, but I don't remember when I did the last changes (I
guess that it was less than two months).

I'll enable some debug output to know sure what is taking so much time.
The tests that I did on my machine showed that most time was wasted
building the gtkliststore. The matching was not the bottleneck even when
you had lots of history items. Making the matching process at least a
bit faster would be easy, but not very helpful.

If I don't find a good way to solve this, I'll just make the alernatives
list very small (like show only 10 entries).


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