Everywhere I look I see that writing a Finder Plugin in Snow Leopard is much easier than it was in Leopard. Can someone point me to some tutorial or simple code example I can download?
I am trying to write a customer right-click menu item for Finder.
There is no official or supported plugin system for the Finder. Starting with OS X 10.6, you will need to inject code into the Finder process and override objective C methods in the Finder process.
I've done this for a proprietary project. I can tell you that the reason that there are no examples or tutorials for this is because it is a significantly difficult and time consuming development task. For this reason, there's plenty of incentive for individuals or organizations who have accomplished this to guard the specifics of their process closely.
If there's any way at all that you can accomplish your goal using the Services API, do it. Writing a Finder plugin will take you 1-2 solid months of painstaking development and reasonably deep knowledge of C and Objective-C internals.
If you're still convinced that you want do to this, grab mach_star. Good luck.
If by plug-in you mean contextual menu, you can do this via the services API.
Hope this helps.
PK
Apple now requires that you write a Service instead of a Finder plug-in. That's why you're finding it so much more difficult now than before. In fact, context menu plug-in support has been removed from 64-bit applications (which the Finder is now by default). Even if the context menu plug-in is 64-bit, the application will not load it. However, enhanced services show up as context menu items, so this should allow you to implement the same feature set that you're looking for.
See the answers to this question for more on how to write Services in Snow Leopard.
Dropbox and Safesync have a Finder plugin for displaying contextual menues and overlay icons. I am not sure how Dropbox did, but for Safesync, you can find a bundle located in /Library/Application Support/SIMBL/Plugins. So SIMBL may helps.
This question has been around for awhile, but I know people are still looking so here's a completed solution for Finder icon badges and contextual menus in Lion and Mountain Lion using method swizzling.
Liferay Nativity provides a scripting bundle that will swizzle the relevant Finder methods and a Java client for setting the icons and context menus. It also includes equivalent projects for Windows and Linux.
Hopefully this will save you the 1-2 solid months of painstaking development described by anthony. :)
The project is open source under LGPL, so feel free to contribute any bug fixes or improvements!
Related
Apple introduced Xcode source editor extensions with Xcode 8.
Will Xcode 8 still support plugins served via Alcatraz?
Xcode 8 prohibits code injection (the way plugins used to load) for security reasons. You can circumvent this by removing the code signing on Xcode. Both of these tools are capable of simplifying that:
https://github.com/inket/update_xcode_plugins
https://github.com/fpg1503/MakeXcodeGr8Again
To work on Xcode 8+ without removing the code signing, plugins will have to be rewritten as Xcode Source Editor Extensions. Unfortunately, the APIs for these extensions only allow for text replacement at the moment, so they are not an adequate replacement.
I've filed a report on rdar, do not hesitate to express your mind as well:
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party
plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being
narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic
source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First
shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
https://github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day
without:
AxeMode – Xcode issues patching Backlight – active line highlighting
ClangFormat – code formatter DerivedData Exterminator – daily need
getting rid or bad stuff FuzzyAutocomplete – name says it all, still
more powerful than Xcode completion HighlightSelectedString MCLog –
console log filtering, including regexes OMColorSense Polychromatic –
variables colouring, cute stuff RSImageOptimPlugin – processing PNG
files before committing SCXcodeMinimap – love this SublimeText-thingy!
XCFixin_FindFix – fixing Find features XcodeRefactoringPlus – patching
Refactor functionality, still buggy, but less than Xcode without
plugin XToDo – TODOs collection ZLGotoSandbox – 'cause dealing with
your folders would be a hell without it
Most of them are not source code-related, thus deserve having a way to
be loaded and working like a charm again.
You can certainly load all your plugins by recode signing Xcode 8.0. All credits to the XVim team. They seemed to solve this problem.
https://github.com/XVimProject/XVim/blob/master/INSTALL_Xcode8.md
The Most Important Step From The Solution
There is no support and we can't expect any. Apple decides to shut down the ecosystem around the Alcatraz package manager before they have an api ready (extensions) that is able to do what the plugins were doing before. The extensions are currently limited to the text frame which does not allow to do much.
The main reason announced by apple is security and we can now disable code signing with effort to get back the most important features that were missing in Xcode.
Bad day for the community, bad decision from apple.
I also recommend the discussion on Alcatraz here: https://github.com/alcatraz/Alcatraz/issues/475
Most importantly if you want to support Alcatraz file a bug at http://bugreport.apple.com to make them aware that many people are suffering with this change
I did the same (openradar.appspot.com/28423208):
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day without:
AutoHighlightSymbol - Add highlights to the currently selected token
ClangFormat – code formatter
DerivedData Exterminator – daily need getting rid or bad stuff
FuzzyAutocomplete – name says it all, still more powerful than Xcode completion
KZLinkedConsole - be able to click on a link in the console to open the relevant file and be faster to debug
PreciseCoverage - nicer gui than xcode provides to view the coverage
XcodeColors - shows colors in the console depending on log level (how else should a console be used?)
Most of them are not source code-related, thus deserve having a way to be loaded and working like a charm again.
If you do not make a fast step to support your community i'm sure we
will find another platform to work with.
Seems like this should work. Found some answers here:
https://github.com/alcatraz/Alcatraz/issues/475
The key seems to be to removing code signing in order to get existing plugins to work.
Apparently not :'(
https://github.com/alcatraz/Alcatraz/issues/475
We have to wait until someone convert the plugins into the new Xcode Extensions
I'd like to add a find bar (just like the one that appears in Safari, Skim, etc) in the NSTextView of my app.
I'd like to use NSTextView's setUsesFindBar method, but it's a Lion only API at the moment (according to its documentation). It uses the NSTextFinder class, which is also available only in Lion.
My question is how I may be able to replicate this in my app that needs to run on both Snow Leopard and Lion. I could of course use the find panel on SL, but it would be nice to have a consistent look across the two versions.
Are apps like Safari, Skim and so on coding it from scratch in their SL versions?
Any explanations or pointers would be much appreciated.
Unfortunately, you'd need to implement the find bar from scratch for Snow Leopard, there's no API support for it. Safari may use a private implementation of this API in Snow Leopard (I don't know if it does or not) but the developer of Skim has most likely re-implemented it from scratch.
I think that letting Lion users make use of the new functionality while SL users get the old find panel is an appropriate way of dealing with the situation. I don't personally think it's worth going to the effort of re-implementing it for a legacy OS.
Updated: I just did a search for Skim and it appears to be open source. If that is the Skim app you're referring to, then just check out the source and have a look for yourself.
I have a .NET application, which I want to port to OSX. Up to now I used a DirectShow DLL for WebCam handling. Can I use an Objective-C DLL for Mono? How? I'm a newbie on Mac. Is there an existing (WebCam handling) solution for this? Is there a better solution?
You want to use the QTKit framework to do this, in particular you can use the QTCaptureView as a reusable NSView that you can embed in an existing window or in an application to do the actual video capturing.
I have just added support for capturing to the MonoMac bindings a few minutes ago after I saw your question, so you will need to do a little bit of work.
Steps:
Install Mono, MonoDevelop and the MonoMac addin as described here: http://mono-project.com/MonoMac
Download the latest sources for MonoMac and MacCore from Github: http://github.com/mono/maccore and http://github.com/mono/monomac
Update the MonoMac.dll to the latest version, by going into the monomac/src directory and typing "make update"
At this point you should be able to use the QTCaptureView in your MonoMac applications like any other NSView. A tutorial showing the use of the API in Objective-C is here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/QTKitApplicationTutorial/BuildingaSimpleQTKitCaptureApplication/BuildingaSimpleQTKitCaptureApplication.html#//apple_ref/doc/uid/TP40008155-CH8-SW1
You can just use the equivalent versions in C#
I'm not sure what you mean by "an object-c dll for Mono".
Your absolute best approach is to learn the platform you're targeting and port only the logic and general architecture.
To access cameras, microphones, line-ins, etc. on Mac OS X, use QTKit (Quicktime Kit). It's mind-numbingly simple to set up a web cam view, record to files, grab frames, etc. It's built in and designed to make this sort of thing mostly drag-and-drop for developers.
MonoMac is just one alternative. There are Monobjc, CocoSharp, NObjective, MObjc / MCocoa and ObjC# (I cannot choose between them). Theese are all "bridges" between Mono and Cocoa, what mean you can use Cocoa API in Mono application. But I don't want to use the API directly. I just want a dinamically linked library, which provide me some function for WebCam handling (as I said, I did this up to this time on Windows). In other words: I need a wrapper in Mono for QTKit.
PS: If I rewrite the application in object-c that means several months, and double work in the future when the application will grow. I love object-c but I hate to work unnecessary.
I tried the accepted code in XCode, and when I tried to port to Monodevelop, several classes are missing, eg. QTCaputureSession, QTCaputreDeviceInput, CVimagebuffer.
(Sorry, I cannot edit my previous messages, this is another account.)
I am looking to make a Mac version of one of my iPhone apps and was looking for a good ay to hit the ground running. I know how to code in Objective-c and Cocoa, and I know how to piece something together from scratch if I have to, but I am looking for an easier way.
Are there any open-source templates for coding Mac desktop applications that I might be able to pick up and use to get started off without reinventing the wheel?
EDIT:
I guess what I am looking for is an easy way to get started on an app that has the "iTunes Look and Feel". If there are some bare-bones version of this layout as some sort of template project, that would be great. Also, why has somebody down-voted this question? Have I asked something that is not appropriate for SO?
Apple includes lots of project templates with Xcode (vanilla application, document-based application, Core Data document-based application, etc.). I don't really know how much more you would want in a template. They're generally pretty good for getting you started, I think. If you're looking for something more than these offer out of a "template," maybe you could elaborate.
If you're just looking for a starting point for the interface, then check out BW Toolkit:
http://brandonwalkin.com/bwtoolkit/
He has some nice videos on his site showing how to create a Mail-like interface very quickly.
Besides the project templates included with Xcode, you should browse the application exmples in /Developer/Examples. Most of these examples are "full" applications that demonstrate one or more Cocoa-related concepts. Many could serve as the starting point for a similarly orriented app of your own.
I may want to create a RIA but am wondering, whether Adobe AIR or Titanium is the way to go.
Do you think the open source version will last longer? Will it be better in anyway?
Just in case anyone comes back to this post, I'll add my 2 cents.
Titanium has come along way in the last few months. It now has support for Ruby and Python. You can code your own modules in C++ (eg, IRC) and compile Titanium to have support for that module (Or you can code modules in Py/Ru/JS).
You can use flex, flash and silverlight all within Titanium. All have been tested and work without a hitch :)
Although AIR isn't open source yet, the technology stack it's on (Flex, Webkit, etc) is open source. Titanium definitely looks promising but has no where near the momentum and support AIR has yet. Until it's been actually released and has several production apps running on it I wouldn't bet too much on it.If you're looking to get involved in an open source project and actually work and help develop it that's something else...
Just to clarify, AIR lets you use HTML/js to build your apps as well.
Neither, as both technologies are for creating desktop applications not RIAs.
Now if you were to ask how should you build your RIA... so that when, if, it comes to a point of you making a desktop version, which technology should you use, Flex or Javascript/HTML?
The answer becomes obvious once you decide between Flex or Javascript/HTML. If you do Flex then your desktop application will be in AIR; If you do Javascript/HTML your Descktop app will be in Titanium.
My suggestion, go with Flex - Air. Both are environments where State is made easy. Flex are written much like client (desktop) applications anyway as they have state.