[OS X] Use 10.10 Finder Sync icon indication

[guruz]

If running on 10.10:

https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_10.html

FinderSync (FinderSync.framework). The FinderSync framework enables Finder extensions to:
Express interest in specific folder hierarchies
Provide "badges" to indicate the status of items inside those hierarchies
Provide dynamic menu items in Finder contextual menus, when the selected items (or the window target) are in those hierarchies
Provide a Toolbar Item that displays a menu with dynamic items (even if the selection is unrelated)

This would replace our overlay icon code.

https://developer.apple.com/library/mac/documentation/FinderSync/Reference/FinderSync_Framework/

[nemphys]

Yes, this is the way to go; I suppose DropBox is using this, since the overlays were missing when I first upgraded to 10.10 and after a few weeks (ie. DB update), they came back, but different than ever before.

[iliyasbasir]

Screen Shot

ownCloud

DropBox

[jturcotte]

I tried to get it to work by hacking things together but I'm currently stuck in a corner: the FinderSync requires sandboxing to be enabled for the app extension bundle, and that means in return that the code can only communicate through unix sockets with other sandboxed applications (of the same "application group")

https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW24

I tried to mark the current socket path with temporary sandbox exceptions, or to tell the client to open the server inside the app group container path and OS X obviously doesn't let me open the socket for listening.

This means that we won't be able to use those fancy new icons unless we also make the desktop client application sandboxed. I'm assuming that this won't be trivial.

[guruz]

@danimo @dragotin ^^ FYI

[jturcotte]

A bit of research seem to reveal that it shouldn't be necessary to have the client sandboxed. This page suggests using XPC as communication, but this would require running the sync engine in a launchd service, this one probably also sandboxed: https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/Finder.html#//apple_ref/doc/uid/TP40014214-CH15-SW13

It could make sense to take the opportunity to split our syncing into a service. This would increase the security by sandboxing the communication with the server, would avoid UI lock-ups by avoiding doing the discovery on the client's main thread and allow using the FinderSync properly. The problem is that this will probably require quite some platform-specific code and the usual amount of bugs that this implies.

Another option it to have the XPC service only used as an intermediate communication end-point between the client and the finder extension, but this would be a bit of a hack.

[jturcotte]

I tried XPC and I couldn't find a way to use it without servicing it from a helper process that need to be launched from launchd.

I got something working using an NSConnection to communicate from the sandboxed extension, that should work. I still need to find a way to update parent directories since I can't handle UPDATE_VIEW the same way, and also make sure that the old extension still work to support < 10.10.

[guruz]

                                                                                  Cab you clarify on "update parent directories"?                                                                                                                                                                                                                                                                                                                                        Congrats btw!                                                                                                                                                                                                                From: Jocelyn TurcotteSent: Freitag, 22. Mai 2015 16:54To: owncloud/clientReply To: owncloud/clientCc: Markus GoetzSubject: Re: [client] [OS X] Use 10.10 Finder Sync icon indication (#2340)I tried XPC and I couldn't find a way to use it without servicing it from a helper process that need to be launched from launchd.

I got something working using an NSConnection to communicate from the sandboxed extension, that should work. I still need to find a way to update parent directories since I can't handle UPDATE_VIEW the same way, and also make sure that the old extension still work to support < 10.10.

—Reply to this email directly or view it on GitHub.

[jturcotte]

The client will update all file status when they change, I'm not sure what was the original purpose of UPDATE_VIEW, but in my case it seems like parent directories of synced files are the only one needing an force update (which UPDATE_VIEW triggers).

For example:
a
| - aa
| | - aaa
| | - aab
| | - aac

Once aaa through aac are done updating, UPDATE_VIEW is usually needed to get the OK status for a and aa, since a directory is marked as SYNC if any of it children are still syncing. So either I'll have to put the parent directory logic in UPDATE_VIEW, or even better put that logic directly in the SocketApi and get rid of the need for a force update in UPDATE_VIEW for all other plugins.

[jturcotte]

I got it pretty well working in my temporary branch, most of the risk involved by the feature is cleared, But I still need to figure out how well that will work with non ad-hoc signing since the Mach port name needs to be prefixed by the signing team ID. Here is what I think is left to do

• Get square unpadded icons
  • Figure out how we'll display the "shared" badge, since that makes the icon rectangular
• Get an OS X dev account to be able to make sure that it works with real distribution code signing
• Check if/why the extension isn't enabled by default and find a way to avoid asking the users to do it themselves
• Disable the OwnCloudInjector code path on >=10.10 in case that the extension is already on the system
• Remove the need for UPDATE_VIEW to re-query all file states, make sure that the client pushes everything that needs a status update

[jturcotte]

I consider the feature done, but there are surely issues remaining, I added some quick testing info at https://github.com/owncloud/client/wiki/Testing-Scenarios-2.0

[Dianafg76]

@jturcotte I need the steps to reproduce this issue. Thanks

[guruz]

Install 2.0 nightly build on OS X. Check if sync indicator icons show up in finder.

[Dianafg76]

It is work ok. Many thanks
Desktop v ownCloud-2.0.0.2582-nightly20150731.pkg
I close

[TomGem]

I just installed ownCloud-2.0.0.2666 on OS X 10.10.5 and since then the icons as well as the ownCloud finder actions (right click -> share with ownCloud) are gone. Both have been working with the 1.8.4 Client.

Futhermore, where is #2897 implemented, I can't find any options like those mentioned there?

Anyway, the most important thing, ownCloud 2.0 is syncing fine.

Please let me know if I can provide something.

[jturcotte]

@TomGem The extension loading is now handled by OSX directly instead of having to inject the bundle directly in Finder, so you can find the option in [System Preferences / Extensions / Finder] where you should be able to enable the "ownCloud Extensions"

There are some situations where the extension wouldn't be enabled properly on the first install, but normally just enabling it there should make it available again. Let me know if that doesn't work for you.

[TomGem]

That's it, thank you very much!