Python/C++/Objective-C native: File manager integration: Windows Explorer, Finder, Nautilus, Nemo

[binwiederhier]

The little icons for the Windows Explorer, Nautilus and Finder need to be managed by separate native applications communicating with the Syncany daemon.

The liferay-nativity is a good starting point. It offers file manager integration on all platforms, but the code by is nowhere near a nicely integrable.

I'm looking for someone to implement this. Please let me know if you're interested.

[binwiederhier]

Related: https://issues.liferay.com/browse/NVTY-58

[binwiederhier]

There's old code for Nautilus/Nemo here (based on Dropbox Nautilus plugin):
http://bazaar.launchpad.net/~binwiederhier/syncany/trunk/files/head:/nautilus-syncany/

Original Dropbox Nautilus plugin here:
https://github.com/dropbox/nautilus-dropbox

For Windows Explorer here:
http://bazaar.launchpad.net/~binwiederhier/syncany/trunk/files/head:/windows-syncany/

[binwiederhier]

ownCloud has been working on this too. There might a a way to reuse their code. In fact, it might be great to share code between ownCloud, Sparkleshare and Syncany on this:

See

• https://github.com/owncloud/mirall/tree/7ae6712d56ccaa42e533972130b0ec202be4a420/shell_integration
• http://dragotin.wordpress.com/2014/11/08/owncloud-client-1-7-0-released/
• https://twitter.com/binwiederhier/status/531258096971444224
• https://twitter.com/jancborchardt/status/531417168135852032

[danimo]

ownCloud dev here. We are basically using a modified version of the liferay nativity plugin which uses a (local) socket API to communicate with our app. Code sharing depends a lot on how your apps retrieve the status. I dont think there a lot of value in sharing code, except for Windows maybe, where overay icons are a scarce resource.

[binwiederhier]

@danimo
Thanks for the response! I looked at some of the code. I'll just summarize what I've learned. Feel free to chime in or correct me anywhere.

• Linux: Turns out that the Nemo/Nautilus plugin is shockingly easy to develop. I was not aware that it also supports Python code. For future reference: Some examples here, explanation here.
• Windows: The Windows DLL code looks really complex compared to that, but I guess that's the awkward Windows API -- and my lack of C++ knowledge.
• Mac: Also looks complicated to me -- but again, Objective-C is not my thing.

From a code search (also: that) and the Mirall wiki page, I see that all plugins (Mac/Linux/Windows) use the same text-based protocol to communicate with Mirall. I suppose that this protocoll is originated in the Liferay Nativity plugin.

In terms of the code sharing mentioned on Twitter, I believe that it's definitely a good idea to follow the same protocol, so we can (in the future) reuse a potentially packaged Nativity and/or Mac library. The Nemo/Nautilus plugin is definitely not really worth sharing.

@dejuknow (Liferay Nativity) and @hbons (Sparkleshare):
I thought you might be interested in this discussion. :)

[danimo]

Almost right, except the text protocol (and the idea to use sockets) was invented by us. Also, Windows and Mac code is mostly our invention these days, with quite some skeleton code left from liferay, and some concepts (e.g. the multi-handler registration on Windows) taken from tortoise.

[binwiederhier]

For Syncany, that means:

• Implement a socket/server to answer file/status requests (implementing that, possibly as part of the GUI plugin)
• Linux: "Steal" above mentioned Python script and package within the GUI plugin (also in .deb package)
• Windows: Find a way to compile Nativity Library with Gradle, package in Inno Setup installer (in GUI plugin) to install DLLs during setup
• Mac: No idea, don't care :)

[dejuknow]

Liferay Nativity developer here. I haven't been actively developing Nativity (other than a few bug fixes) as it's been functional for our own purposes.

Ideas (and contributions!) on making the project more integratable for other consumers would be greatly appreciated.

[dejuknow]

Also, OS X 10.10 now provides the FinderSync framework for adding badges and context menus via an API, obviating the need for hacky method swizzling. The current OS X implementation will eventually become obsolete as the Mac user base eventually migrates to Yosemite and above.

[binwiederhier]

@dejuknow
Having the Java parts of Nativity as Maven library would make it a lot easier to embed in existing applications. Right now, I would have to copy your code and somehow make it work. This strongly relates to my issue on your Jira.

[hbons]

hey! i develop SparkleShare. just chipping in here with my perspective. :)

it would be great if there was some language agnostic way to access the API. just saw Yosemite will have a native API, which is great, so i can use use that. on Linux/Windows commands that take a list of file paths and badge paths/names would be the only thing i need. i know commands can ugly, but bindings aren't easily created. i know there are services like DBus for cross app communication, but unfortunately these aren't cross-platform.

API-wise it would be handy to have the following:

• set a badge on a file or folder
• set a badge on a folder recursively
• remove badge from a file or folder
• remove badge from a folder recursively

i'm not sure what's already being covered right now...

[binwiederhier]

Liferay finally packaged their overlay library:
https://repo1.maven.org/maven2/com/liferay/com.liferay.nativity/