DropPy has no way to know how long your script takes.
It extracts the files from your dropped object and kicks off your Workflow.
And I didn’t want to require any kind of status reporting or time estimation inside Task. Writing Tasks should be as easy as possible. Not even understanding inheritage is necessary for writing a Task.
DropPy uses the item-based API for accessing dragged & dropped objects that was introduced at WWDC 2016 and rolled out in Sierra.
The old NSPasteboard based implementation is deprecated now, but still available in High Sierra.
The reason why I don’t want to support both implementations is because they react fundamentally different on dropped items. For example when dragging a file from Finder to DropPy accessing it through the NSPasteboard implementation moves it while the item-based API copies it.
Once it was clear that I needed at least 10.12 I also used Unified Logging.
Well, not for the financial reasons (Apple tax) often criticized by other developers.
I’d love for DropPy to get in there and gain visibility this way.
However this simply isn’t possible due to Apple’s sandboxing requirements. The whole point of an automation app like DropPy is to enable you to launch your code on all your files, calling any 3rd party programs you want. And exactly this is prevented by the app sandbox.
I started in Swift 3 (Xcode 8) and migrated to Swift 4 (Xcode 9).
And of course droppy-workspace is written in Python 2.7, with compatibility for Python 3.6.
I got a lot of ideas - but it all depends how well received v1 is.