The incompatibility with the File Tagging plugin hasn’t yet been worked out as the source isn’t available. If you’re using the download from B5X, be sure to disable this plugin until the conflict is resolved.

Note that some features (such as the “smart replace” pictured above) require setting the feature level to “developer”. You can do this by running the following two commands, then relaunching:

defaults write com.blacktree.Quicksilver "Cutting Edge Features" -bool yes
defaults write com.blacktree.Quicksilver "Feature Level" 3

I wrote a plugin for WordPress that allows you submit your RSS feed to Google Coop.

If you’re interested in this sort of thing, you can download the Quicksilver Smoke Actions plugin here.

Speed Cache basically takes external files such as javascript and CSS and mirrors them on your own server. I’m not going to go into detail about why you’d want to do this - you either do or you don’t. If you do, then feel free to use the plugin.

Here it is.

Support questions in the comments for now, but I’m not providing any guarantees. This post may be replaced by a proper info page about the plugin sometime in the future, but at the moment that’s unlikely.

It couldn’t be easier. Just drop the file or folder that you want the icon from onto IconGrabber, and choose a place to save it. The extension you choose determines the format, otherwise it defaults to tiff. That’s it!

If you’re a Quicksilver user, you can use the IconGrabber Quicksilver plugin. (It doesn’t require the IconGrabber application.) Once installed, you’ll get a “Save Icon To…” action. Not only can you save the icons of files and directories, you can save the icon of whatever appears in the first “object” pane. This is extremely handy.

Enjoy!

Update:

The Quicksilver plugin is now at version 0.95. Notable changes include:

• Forcing direct object to load icon.
• Indirect object for “Save Icon To…” starts at IconGrabberSaveTo defaults key. Format used is set by the IconGrabberFormat defaults key. Uses png by default.
• “Save Icon As…” action added. Indirect objects have different image formats. Images are saved to the IconGrabberSaveTo defaults key.
• Image files have the IconGrabberAppend key appended to the filename (”-icon” by default).

For example, if you want to use the tiff format for the “Save Icon To…” action, run defaults write com.blacktree.Quicksilver IconGrabberFormat tiff.

If you want to change the directory the images are generated in by “Save Icon As…”, run defaults write com.blacktree.Quicksilver IconGrabberSaveTo "~/NewDirectory".

Here’s your answer.

AppleScript can be handy sometimes, but when people release applications like this, and get awards for it, alarm bells should be going off. WallSaver is almost two megabytes in size. For a single command-line.

Just reinforce the point, I wrote another wrapper for the same command in Objective-C. It’s 100 kb, or 60 kb without the icon. It can pause the screensaver (which brings it down to 0 CPU usage), resume it or restart it. And not once will it throw an “AppleScript error” . Download it and see for yourself.

As for the source code, all you need is:

/System/Library/Frameworks/ScreenSaver.framework/Resources/ScreenSaverEngine.app/Contents/MacOS/ScreenSaverEngine -background

Finder info, .DS_Store files, resource forks, debug symbols… They do nothing for the user short of wasting disk space. For the developer, extra bandwidth costs. Do people not realise this is a problem, or are they just too lazy to act? Either way, the solution is simple.

You can clean apps (sometimes to less than half their original size) with some basic commands in the Terminal. But this takes time, and what’s more, Mac users in general have an aversion to the command line. Enter Trimmit.

Trimmit is a svelte utility which takes the pain out of keeping your applications as tight as possible. I use it on Flow each time I seed a build, and I seriously doubt the process could any easier.

Brian Amerige

Trimmit uses superfast UNIX APIs, Apple’s own developer tools, and the rock-solid Cocoa framework to automate your cleaning process. Just drop your built app onto it, maybe configure a few settings, and you’re away. It doesn’t get any easier - or faster.

Other applications claim to save disk space by stripping universal binaries, or removing languages. Trimmit does all of that - and more. But it works. Look at this screenshot from Xslimmer regarding Xcode:

Xslimmer naively believes that only two architectures can exist in any application, but the truth is revealed by Trimmit:

Because Trimmit interacts with the shell (zsh, in fact), no similar application can even come close to it’s level of power, accuracy and performance.

The results speak for themselves.

Use Trimmit to recover disk space that third-party applications so rudely waste.

Go get Trimmit.

The reason for this article should be obvious: too many OS X third party developers do an absolutely terrible job of building and packaging their applications. rixstep

Too many apps are shipped with debug symbols, uncompressed images, redundant files or generally useless rubbish that not only wastes users’ disk space, it ultimately ends up increasing the developer’s own bandwidth costs.

It’s not just the script kiddies at fault. Path Finder weighs in at over 60 MB on disk, but after a few simple operations, is halved in size to just over 30 MB. AppZapper can be trimmed from three megabytes to just one. Xslimmer (ironically) is over 80% junk, going from 5 MB on disk to a meagre 1 MB after being cleaned. In this case, the disk image is three times as big as the cleaned, uncompressed app. Starting to see the trend? Almost every app can be cleaned up to save a good deal of space.

Deploying your app

Rixstep provide instructions on deploying OS X apps covering most of the major areas.

Essentially, you need to:

Remove Junk

Get rid of all .DS_Store files. In Cocoa apps, remove PkgInfo. You should only have objects.nib or keyedobjects.nib in your nibs: remove classes.nib, info.nib, and data.dependency; these are not relevant for the user. Also remove all header files from your app and from embedded frameworks.

Clean up localization

Keep all non-language-specific resources in the Resources folder rather than duplicating them in each .lproj folder. Look through the framework you’re embedding, and remove any unnecessary files files. That includes language projects which your main app doesn’t support.

Compress images

Make sure all your images are compressed, especially if they’re in TIFF format. (But you shouldn’t use images for simple graphics like curves or gradients anyway; there are Cocoa drawing routines for that and NSBezierPath is your friend)

Trim binaries

Do not release an app that has been built using the Xcode “Debug” configuration. Remove the debug symbols from your build product, and if possible, release architecture-specific versions of your app, as well as a universal binary.

Get all the details in Building and Packaging Native OS X Applications.

Automation

A relevant question is: are there any tools that automate this process? And the answer has to be ‘not up to now there aren’t’. Until something comes along to save users from these issues it’s still all up to that developer you trust. Rixstep

There is finally a tool that automates at least some of the cleaning process. Say hello:

Go get trim-app

Trim-app is a shell script. It:

• Cleans out all the horrible .DS_Store files
• Removes unnecessary info.nib, classes.nib, and data.dependency files from inside nibs
• Strips “fat” universal binaries to contain code for a chosen architecture only
• Eliminates debug symbols that may be left in your application

You can perform all procedures at once, one at a time, multiple at a time, etc. using different parameters or flags (run trim-app -h for help).

The script searches the current working directory including every subdirectory so no files are missed. Even embedded frameworks are scanned through and cleaned out. So make sure you’re in the right directory before running (use the pwd command if unsure)

All changes performed are permanent and non-recoverable. (If you’re writing the app, that shouldn’t be a problem. Just build it again if something goes wrong)

While it’s written for cleaning out applications, this script is also great for general tasks - cleaning out .DS_Store files in a certain folder, for example.

Installation

• Unzip the download.
• Open Terminal and navigate to the folder where the unzipped trim-app is.
• Run chmod 0700 trim-app. This makes sure only you can execute it.

If you want easy access to the command, move the file to /usr/bin/ by running sudo mv trim-app /usr/bin/. You’ll be asked for the admin password, then file will be moved.

You can now test if it’s working by running trim-app -h. Instructions for trim-app will appear. Once you’re done reading them, press q to exit, and start using it!

Usage

Running the shell script without any parameters will attempt to run all four procedures. You’ll be prompted for an architecture to keep in universal binaries. Leave this blank (just hit return) to leave universal binaries universal, or type in an architecture to keep (usually ppc or i386) if you want them stripped down.

Here’s an example of how you would use it in the Terminal:

% cd myApp.app/
% trim-app
Architecture to keep? (ppc/i386) ppc
   Removing .DS_Store files…
   Trimming nibs…
   Trimming universal binaries…
   Stripping debug symbols…
   Cleaning up…
Done.
%

If you don’t want to be prompted each time for the architecture, use either --all (as in, trim-app --all) (which will run everything except the liposuction of universal binaries), or add the architecture to keep immediately after, like trim-app --all ppc.

Add a -p flag to the end if you want to see a list of affected files. For example,

% trim-app --all i386 -p

You can also run individual procedures. The following cleans out .DS_Stores from the entire Macintosh HD:

% cd /
% sudo trim-app -d

Run trim-app -h to find out more about the available parameters.

Don’t forget the standard shell practices still apply. Ctrl-C any time during operation to immediately halt execution, save output to a file with trim-app -p > trim-log.txt, and so on.

Lastly, remember that while this shell script does a lot of the work (and there is an application called CleanApp which can help remove unnecessary lproj files), it’s still up to you to take care of removing headers, compressing images, etc.

This isn’t a bona fide TextMate theme in that it has no effect on the fonts & colors in your main editing window, but it styles the preview window in Markdown (or blogging) mode, as well as the subversion windows (click the thumbnails just above to see bigger pictures).

The “virtuoso” theme is modeled from this very site and handles tags like big, small, strong, emphasized, kbd, abbreviations and acronyms, code, insertions, deletions, quotations, citations, super^script, sub_script etc. Smashing, really. You can explore the elements and classes in style.css to get an idea of what’s possible, or just look at the styles used on this site.

But that’s enough talk, you have to see it for yourself to really appreciate it. Download the archive, then extract it to ~/Library/Application Support/TextMate/Themes/WebPreview/. You may need to restart TextMate, then you’ll see “virtuoso” among the list of themes in the Markdown preview or subversion window.

The added benefit of this (for me) is being able to preview what a blog post is going to look like, so I don’t have to mess with WordPress until I’ve got the entire post written.

Please feel free to heap praise upon or post constructive criticism on this. I value your comments.

Fixed compatibility with other themes. Improved overall appearance.

- (DiggObject *)fetchStoryWithID:(int)ID;
- (DiggObject *)fetchStoryWithTitle:(NSString *)name;
- (DiggObject *)fetchStoryWithURL:(NSString *)url;
- (NSMutableArray *)fetchStoriesForDomain:(NSString *)domain;
- (NSMutableArray *)fetchStoriesForTopic:(NSString *)topic;
- (NSMutableArray *)fetchStoriesForContainer:(NSString *)container;
- (NSMutableArray *)fetchStoriesSubmittedBy:(NSString *)user;
- (NSMutableArray *)fetchPopular;
- (NSMutableArray *)fetchRecent;
- (NSMutableArray *)fetchStories;
- (NSMutableArray *)fetchUpcoming;

It’s also just as easy to set the options or parameters that you would like to call the query with:

-(void)setAppkey:(NSString *)newAppkey;
-(NSString *)appkey;

-(NSString *)proxy;
-(void)setProxy:(NSString *)newProxy;

-(BOOL)single;
-(void)setSingle:(BOOL)newSingle;

-(int)count;
-(void)setCount:(int)newCount;

-(int)offset;
-(void)setOffset:(int)newOffset;

-(int)total;

-(NSString *)domain;
-(void)setDomain:(NSString *)newDomain;

-(NSString *)sortBy;
-(void)setSortBy:(NSString *)newSort;

-(NSString *)status;
- (void)setStatus:(NSString *)newStatus;

- (NSString *)minSubmitDate;
- (void)setMinSubmitDate:(NSString *)newMinSubmitDate;

- (NSString *)maxSubmitDate;
- (void)setMaxSubmitDate:(NSString *)newMaxSubmitDate;

- (NSString *)minPromoteDate;
- (void)setMinPromoteDate:(NSString *)newMinPromoteDate;

- (NSString *)maxPromoteDate;
- (void)setMaxPromoteDate:(NSString *)newMaxPromoteDate;

Currently the focus is on fetching stories, but fetching information for users, events (Diggs and comments), topics and containers will be written in shortly.

The only major thing lacking now is people to use the framework!

If you’re interested, drop a comment below and I’ll provide you with the necessary ammunition to create, fetch, parse and utilize Digg API calls with the ease of regular Objective-C Cocoa methods.

The official release date will depend on the response from the initial testers, so what are you waiting for? Ask me for a copy!