Here's the available targets for Snow Leopard services in automator.
Available service targets http://s3.amazonaws.com/augustl-stuff/automator-available-service-targets-84.png
I want my service to operate on all files. It would sort of work to choose "files or folders" and ignore the action if the input is a folder, but that means the service will appear when right clicking folders too, which isn't very elegant.
I can't think of any good reasons to why I posted this question here. The answer is pretty obvious; it's not in the list, so it can't be done.
Related
I want to add a new section to the "Get Info" panel in the Finder, but I don't know where to start.
Everything I have found about "App Extensions" seems to refer to adding extensions to apps/applications, not the finder.
There are these two questions that have been asked, but the newest one is two years old and was never answered.
I'll gladly accept examples in any language, or a pointer to docs on how to do this; I haven't been able to find anything.
I don't think what you are trying to do is possible. At least not using publics APIs provided by Apple. You may be able to do something with techniques like SIMBL, but that's not even sure, and it requires a solid knowledge of the Mac OS X environment.
If you are new to OS X development, this is probably not the best place to start...
In Xcode 3.26 I am used to having a variety of plugin hosts supporting various audio plugin formats (VST, Audiounit, VST3 etc) in the "Active Executable" menu. This is very useful for quickly debugging in different hosts. When I bring my projects into Xcode4 I loose this menu and I can't think of a way in which to get the same behaviour without making a new scheme for each format in each host. Anyone got any ideas if it is possible?
I think you'll have to get used to the one scheme per host, sorry. Xcode isn't as ideal for developing desktop apps as it used to be.
However, AppCode does have run configurations which are similar to Xcode 3's active executables. It's also a generally awesome IDE, so maybe it's worth trying out. :)
There's lots of questions about installers but I haven't seen one about whether or not to actually use one in the first place.
What is the logic behind using them in the first place? Can't the user just extract it somewhere? But I guess it depends on the target user.
And on the subject of the actual setup: Can't that be done on the first startup?
It very much depends on your target audience, and what your installer needs to accomplish.
If your audience is technically savvy, and the installer just has to extract some files, and create shortcuts, I probably wouldn't bother.
If you need to modify system variables, register services, etc, definitely create an installer to make life easier for your users - regardless of how technically savvy they are.
You can always offer the option of installer / no installer, and let your users decide what they want. The number of downloads and resulting support requests will tell you whether you should utilize one or not.
And on the subject of the actual setup: Can't that be done on the first startup?
uTorrent used to do this (I'm not sure if it still does... I update automatically) and I found it a little confusing at first, since I'm used to installers. For users that are possibly clueless though, it's perfect.
For more complicated applications that have multiple files installed to several locations, I think it's better to have an installer. For a series of products we produce where I work, we have several 'flavours' of installer for each product: auto-update installers can be smaller as we know the user already has prerequisites. New users, though, get a larger installer.
I can't see any reason not to use an installer. When you use something like Inno Setup, creating the installer is no more difficult than creating a zip file, and you don';t have to explain to the user how to install.
Having an installer will help your users a lot.
The application will be installed at the right place
The user won't have to set links in program files himself, or copy the extracting content you suggest in a directory
Your application will looks more professionnal
Moreover:
The user will know that using the uninstall system of windows will safely remove your application without affecting the system
You need something which can set up the registry and install prerequisites before starting the app, that's why you need an installer :)
Including a well designed installer can also add value over the lifetime of the application by enabling the application to be updated and enabling the application to be uninstalled cleanly. Eventually the user will want to uninstall the application, and the ideal is to leave their computer in the same state as prior to installation.
I'm fighting with OSX's packageMaker as it doesn't allow me to create a '.pkg'. Instead it's forcing me to make a '.pkg.mpkg'.
This seems like a stupid question I should be able to respond with a couple of google searches, but I'm not being able to find much info about this.
Could anyone explain the main differences between them and if you know the restriction for which you have to use one or the other?
To the best of my knowledge, .pkg files are simple, straightforward Installer packages. However, .mpkg files are very customizable, and can link to multiple .pkg files which the end user can turn on and off in the Installer.
I think the .pkg.mpkg double-extension you're seeing is just a text appending issue. Packages are either .pkg or .mpkg, not a combination of the two.
I believe Collin Allen is correct -- the main difference is that the metapackage can reference other packages. But as to your PackageMaker problem, have you tried Iceberg? It's an alternative (free) that we have had generally better luck with: fewer bugs, easier to understand and use, greater freedom, etc.
I don't have a good answer, but PackageManager automagically switched from .pkg to .mpkg once I tried to modify the text that the user sees. Both included sub installers (.pkg) prepared by vendors.
I am developing an application for the Mac as a small team (me + another person) effort. We are located in different cities, and have started to see the need for solid source control management.
None of us have any experience with this, and both of us are relatively new to Cocoa/Obj-C/Xcode (but do have C knowledge).
Does anyone have any recommendations as to which SCM system to choose? I understand that a lot of people are using Subversion, which is also supported in Xcode 3.1. Does anyone have experience with using Subversion through Xcode? Or is it a better option to chose a stand alone GUI alternative, such as Versions?
Grateful for any input on this.
Gregor Tomasevic,
Sweden
Update/personal experiences:
Since this post, we have tried Versions and Cornerstone (both of which are SVN GUI-clients), as well as Xcodes built-in support for SVN. We were not particularly pleased with Versions, which seemed to have some problems with committing unversioned files/build files. The built-in SVN support in Xcode works quite well, although it probably has limitations that we have still not run into. Cornerstone is both simple to use and powerful, and does not seem to suffer from the problems we encountered with Versions.
So far, we have just tried committing, updating repo, checking out latest/previous versions of our files and worked some with file comparison. It might be a whole different ball game once you start working extensively with branching, an area which we have been told both these GUI clients might have some weaknesses in.
For what it's worth (and with only days of evaluation) Cornerstone seems to be a somewhat better alternative, although for simpler SCM, Xcode works well too.
Thanks for all the comments.
Xcode only supports Subversion, Perforce, and CVS. However, there are also distributed version control systems out there, such as Mercurial, Bazaar, and Git. These have no Mac-native GUIs, but you should still consider them. Personally, I love managing my projects in Mercurial repositories.
[Added 2011-03-10] Xcode 4 adds support for Git. Several of us have filed requests for Mercurial support; you should, too, if you want it.
There is a nice GUI frontend for Mercurial on Mac called MacHG: http://jasonfharris.com/machg/
It is free and very nice IMHO.
You can't really go wrong with using Subversion.
If, like me, you don't like Xcode's SVN integration too much you can always choose to use the command-line tools, or one of the several GUI apps like Versions, CornerStone or SvnX. Most of these tools work together pretty well, so you're not necessarily tied in to the tool you start out with.
I personally do most of my work with Versions, and use the command-line tools with the same working copies every once in a while.
If you're comfortable working with command-line tools exclusively until someone creates a good GUI app around it, git is a pretty viable option too.
disclosure: I'm one of the people who work on Versions, so I might be slightly biased ;)
Xcode's Subversion support is pretty good. 90% of the SVN activities I perform are easily doable from Xcode. For the other few things I just fire up Terminal.
There are a couple things in their SVN client implementation that are annoying:
The code that checks to see which local files have been modified seems to run on a background timer, and its pretty latent. Sometime it takes 5 minutes for Xcode to show a file as modified. The same thing is even more exaggerated w/r/t remote modifications.
Sometimes when you rename or delete a file that isn't under source control, a dialog will appear, asking "Do you wish to [rename/delete] this file in SVN as well?" And the options are "Yes" or "Cancel." You choose Yes out of desperation only to be presented with a well-deserved SVN error.
Overall, I'd recommend it.
Caveat: If you simply tell XCode to add a project to a repository by giving it the top-level dir, it WILL add the build directory to the repository, which of course is a terrible thing to do.
In order to get around this you have to move the build dir to another location so that XCode won't try to import it, or manually add the discrete folders of a project one by one.
Subversion is the traditional OS X source control solution, in Leopard it's supported in Xcode and OS X, not to mention the third party GUI apps (a few of which look very slick). Despite all of this though, a lot of the independent OS X developers have switched to Git over the past year or two. As a single developer I can tell you Git has turned out to be a very good solution for me, and along with Github it makes a great solution for a small team effort.
If you're interested in using Mercurial on OS X, try SourceTree, it's not free but it's competitively priced and has a very polished Mac OS feel. I've been using it for personal projects for the last few months on and off and find it intuitive and reasonably robust.
It's available through the Mac App Store and supports Git and Mercurial. They have a website at http://www.sourcetreeapp.com/ with more information.
If your going for subversion, I've heard good things said about Springloops. I code together with some friends too in a similar fashion and we use Github. Git is such a wonderful experience. I don't use any GUI for it since I'm much more efficient with a shell prompt. But of course, I'd welcome if Xcode had support for Git repos.
Mercurial (like git) is "distributed" and perhaps regarded as more modern and up-and-coming than svn (but less established). If you want to auto-checkin using mercurial, you can add the line:
hg commit -m "Xcode auto commit"
as part of a "Run Script" stage of the XCode build, as found in:
Project > New Build Phase > New Run Script BUild Phase
I use : https://bitbucket.org/hsivank/xcode4-with-mercurial/wiki/Home