I personally think D-BUS is an extreme solution for refreshing, making IPC calls tend not to be the best in performance. The current state of libnautilus can be easily extended to support simple refreshes. I'm currently working on a streaming filesystem that would be very useful to be able to update folder view after the files are done streaming down. Currently, the hack is to change modified time on the file to trigger this notification refresh. It's a workaround at best, and I was hoping for a little cleaner mechanism to trigger such.
Best, Bryan On Sat, Jul 25, 2009 at 10:24 PM, Mike Rooney <mroo...@gmail.com> wrote: > On Sat, Jul 25, 2009 at 3:16 AM, Christian Neumair<cneum...@gnome.org> > wrote: > > If you think that the D-Bus round trip all-too-complex for controlling > > Nautilus from your plugin, you need to bring up a good use case why you > > have to programmmatically refresh the current location from a plugin. > > While I am sure a D-Bus API would be useful, it does seem potentially > heavy weight for this problem. However if it existed and was a > solution I'd certainly prefer it over nothing. The use case I am > trying to solve is when nautilus is viewing a directory which is a > symlink to A, and then becomes symlinked to B. Nautilus doesn't > realize it isn't viewing the correct directory anymore so I need a way > to tell it to re-visit the same address to get to the new location. > This comes up often when working with encrypted directories or > partitions which are often layered filesystems dealt with through > symlinks. So if I want to have a nautilus extension to encrypt or > decrypt the directory, this is going to involve a symlink swap and > require a refresh. Does that seem fair enough? Currently I am blocked > on this extension without a way to make it usable as it requires > manually hitting F5 each time. > > Thanks, > Michael Rooney > mroo...@gmail.com >
-- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list
