On Thu, 2006-12-14 at 22:57 -0800, Gene Z. Ragan wrote:
> > It looks kind of limited. You only look at the NautilusFile for the
> > current path, whereas the bug report is about a button to the right of
> > the current path (after going up) being deleted.
> >
> > The way i see it you need to monitor all the files for the buttons to
> > the right of the active one, otherwise you wouldn't detect them being
> > deleted.
> >
> > Also, if you just connect to the "changed" signal nautilus won't know
> > you're interested in changes to the file. You have to express interest
> > in certain attributes about the file using nautilus_file_monitor_add().
> >
> One more try! This does the proper monitoring of each path node and
> properly tears down the observers and unrefs the files when retargeting
> and destroying the view. I did several debug sweeps looking for dandling
> references.
>
> I tested this by navigating into and out of directories and deleted
> child path nodes
> from within Nautilus and with the terminal. The path view responded by
> removing
> the deleted node and children and retargetted to the remaining valid path.
There is one behaviour issue.
Say you go into /tmp/1/2/3/4, then click on the "2" button, and then "4"
is deleted. With the patch as-is we're transported to "3". That
shouldn't happen in this case. Only if we're currently in or under the
deleted path.
Also, the client used for the monitoring worry me a bit. Really, the
NautilusFile+pathbar pair *should* be unique, but I'd just feel better
if you used the ButtonData pointer as the client.
Otherwise this looks good. Did you get your cvs account yet?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
[EMAIL PROTECTED] [EMAIL PROTECTED]
He's an old-fashioned crooked paramedic from the 'hood. She's a warm-hearted
antique-collecting snake charmer from out of town. They fight crime!
--
nautilus-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/nautilus-list
