That usage should be fine. Check out this example: https://git.gnome.org/browse/nautilus-python/tree/examples/update-file-info-async.py of using the _full method. The reason I added the _full method is to get access to the closure object which is then passed back to Nautilus to let it know that the extension is done using that file handle. Also you may want to read up on the documentation here: https://projects-old.gnome.org/nautilus-python/documentation/html/class-nautilus-python-info-provider.html which will give you details on which Nautilus.OperationResult constants you can use and how to use them.
Adam On Wed, Jul 1, 2015 at 4:19 AM, Christian Kamm <ck...@woboq.com> wrote: > Hello, > > we've received a bug report saying a user had nautilus 3.14.2 crash when > performing actions related to the owncloud nautilus-python script: > > https://github.com/owncloud/client/issues/3067 > > Unfortunately we haven't been able to reproduce the issue. > > However, the question came up of whether the integration script uses the > nautilus-python API in an invalid way. In particular, it uses the > InfoProvider's update_file_info(file) API, stores the file objects it > receives this way and updates their metadata long after > update_file_info() has returned. > > It does seem like update_file_info_full() was invented to cover this > asynchronous use case. It seems to work pretty well however. Is that > intended? Is that use of the API safe? > > The source of the nautilus-python integration script is here: > > https://github.com/owncloud/client/blob/master/shell_integration/nautilus/syncstate.py > > Regards, > Christian > > -- > nautilus-list mailing list > nautilus-list@gnome.org > https://mail.gnome.org/mailman/listinfo/nautilus-list >
-- nautilus-list mailing list nautilus-list@gnome.org https://mail.gnome.org/mailman/listinfo/nautilus-list
