Re: [Nautilus-list] [patch] - hierarchical script menus - still incomplete

[Darin Adler <darin bentspoon com>]

On Monday, May 28, 2001, at 01:45  PM, David Emory Watson wrote:

> > I think the current code will already do the right thing, and no
> > additional work is needed here except for some testing. If a directory is
> > moved or deleted or even renamed, the "files_changed" signal for its
> > parent directory will be called. This will eventually cause
> > reset_scripts_menu to run, which rebuilds the entire scripts menu.
>
> The menus will be rebuilt just fine, but the list,
> scripts_directory_list, may contain extranious entries until nautilus
> shuts down.  In addition we won't know to stop monitoring the old script
> directories, unref them, etc.  In fact you can see Bonobo-WARNING's if
> you create a couple of sub-directories and then delete them.  This
> happens because the function call_when_ready_on_scripts_directory looks
> at the scripts_directory_list when it setups the callbacks, so if you
> delete a directory without removing it from the list then you get
> extranious callbacks.  It's really not a hugh deal (unless someone
> creates 10 million script directories), but if there is an easy fix I
> think we should take it..

I understand the problem now. We need to remember the URIs we used so we 
can remove the menu items. Since the NautilusDirectory objects 
automatically get updated, the code to remove the menu items doesn't work.
 This can't be fixed just by monitoring the objects more closely, because 
once you are notified about any changes, the object is already changed and 
there's no way to recapture the old URIs.

I suggest that we keep a second list with the paths that are used to build 
the Bonobo menus. Since the code always rebuilds the entire menu, we can 
remove all the menus using the separate list of menu paths, and there's no 
need to track changes in the individual NautilusDirectory objects.

I'm sure there are other ways to deal with this as well, but I can't think 
of any simple ones off hand.

> > If we want to notice the directory being moved or destroyed, we also need
> > to connect to the "changed" handler of the directory's corresponding 
> > file.
>
> I think this needs to be done to address problem 1).  When the "changed"
> handler is called we clean up the scripts directory list....  I will
> work on this for my next patch...

I don't think it's needed for the reasons I gave above.

> > > +	view->details->scripts_directory_list = NULL;
> >
> > This line of code is unnecessary.
>
> There are a few for loops, as well as an if statement in
> call_when_ready_on_scripts_directory which depend on this.  I am using
> this value to determine whether or not the scripts directory was
> found/created.

All details fields start as NULL (0, whatever). Setting it to NULL again 
seems unnecessary to me, but I guess it's OK.

> +/* FIXME: Allow the icon to be set. */

The code to set the icon would be pretty simple, but we can do that in a 
second pass after your check in, I guess.

    -- Darin