Re: [Nautilus-list] fixing the fact that updating menus takes a lot of time

[Alex Larsson <alexl redhat com>]

On Thu, 14 Jun 2001, Darin Adler wrote:

> On Thursday, June 14, 2001, at 08:38  AM, Alex Larsson wrote:
>
> > The problem is not the I/O. The problem is that each view of that
> > directory gets a lot of file_changed signals, which leads to every view
> > updating it's menus. Due to braindeadness in Bobobo, updating the menus
> > takes a lot of time, so performance drops rapidly as you get more views
> > displaying the directory.
> >
> > For more info on this, see my mail on 12 Jun with subject
> > "Re: [Nautilus-list] hidden files bug".
>
> Here's my thinking on this.
>
> I want to build a layer on top of Bonobo (probably in
> eel-bonobo-extensions.[ch] or in libnautilus-private) that keeps track of
> the UI items and their state in some fast data structure, like a hash
> table. Then, when the menu update is done, we'll build the appropriate XML
> and send a single piece of XML to Bonobo for changes in the component's
> menus and nothing at all if nothing changed.
Seems like a good way of routing past this problem.

> Before now I resisted doing this because I thought that what Alex calls
> the "branddeadness" in Bonobo would eventually get fixed. And because this
> problem would affect any other substantial Bonobo component and program.
> But now that it's clear I need to do it, it should be pretty easy to do.

The best solution would of course be to fix Bonobo, but I doubt this will
be possible now. I will gladly help you implement this, only I'm busy
with other stuff the rest of this month.

Has anyone talked to Michael about this problem? It would be nice if
Bonobo was fixed for Gnome 2. (But my hopes aren't high about this
unfortunately.)

/ Alex