GNOME Bugzilla – Bug 159103
Cannot get NautilusFileInfo when external event received in a nautilus extension
Last modified: 2010-04-28 14:52:42 UTC
If someone is writing a nautilus extension that adds emblems to a folder/file there's no way to make a call to Nautilus to get a NautilusFileInfo * which could be used to invalidate the extension information so an emblem is added/removed based on the external state of some other process. An example of this is when the iFolder Client (Mono/Gtk) converts a folder to an iFolder or reverts an iFolder to a normal folder. Other than saving a weak reference to every NautilusFileInfo * seen by the extension, there's no way to invalidate the information when there's an external update by the iFolder Client. Exposing the following functions to Nautilus extensions would solve this problem (per a discussion with dcamp in #nautilus): nautilus_file_info_get() nautilus_file_info_get_existing()
Thanks for your bug reports! Milestoning to 2.14, because this significantly impacts extension design. Would the function prototypes look like: NautilusFileInfo *nautilus_file_info_get (NautilusFileInfo *file, const char *uri); so that we can invoke the NautilusFile wrapper?
Created attachment 56222 [details] [review] Proposed patch Does this one satisfy your needs? :)
Missed 2.14 feature freeze. Remilestoning to 2.16. Byod: Without feedback we won't be able to provide you guys with something useful.
Chris, I was thinking more on the lines of: NautilusFileInfo *nautilus_file_info_get(const char *uri);
Missed 2.16 freeze, updating.
It shouldn't be part of the NautilusFileInfo interface, that makes no sense. It should be separate global functions.
Alex: I agree, but where should we declare them? Also in nautilus-file-info.h?
Created attachment 96376 [details] [review] Proposed patch Another patch proposal, that will proxy nautilus_file_info_get() to nautilus_file_get(). It will add run-time symbol dependency on libnautilus-private to libnautilus-extension. This won't be a problem IMO since they can always be resolved (libnautilus-private is of course always linked into the nautilus binary).
Created attachment 96377 [details] [review] Proposed patch
This has been implemented during the 2.30 cycle, closing as OBSOLETE.