Bruji News

I am an avid Google user and even though the quality of results has suffered in the last few years, I still use Google almost exclusively when researching a topic. When the question is simple, a visit to Wikipedia or Stackoverflow will suffice but when things get complicated I tend to open several of the search results for browsing. Inevitably the time comes when I realize I want to open a previous result that was prematurely closed but is now key – unfortunately Google has left my history useless.

I’ll never find that page even though I distinctly remember having “Step by Step” in the title and a favicon that had some sort of diagonal stripes.

Why is my history so useless? Is my computer broken or has Google broken the internet? Google actually displays the actual link under each title of the page to let users know what page they will be visiting. The link is also the actual href attribute of the link and is displayed at the footer status bar during a mouse over. But why isn’t it the link I get when I click or copy it? Because when the time comes to use a link Google uses Javascript to replace the link with a redirect to their own servers in order to keep track of what links users are clicking on (except when the link points to their own Google domain like images or maps).

As wonderful as that information might be to Google in improving their results rankings and knowing what results I favor most, it’s messing with my history as well as my ability to copy and paste a link (“Copy Link” shown above picks up the modified link) for a blog post or to email to a friend.

There must be a way to get the old direct-to-result Google back. There are no options to disable this behavior that I could find, not even in the name of privacy. After some searching I ran into a Japanese gentleman with the same linking sensibilities as mine who has written a Grease Monkey script that solves the issue. But in this day and age I want a simple Safari Extension that I can install and manage natively in Safari. After poking around for such a script (Dear Apple, could we please have search functionality in the extension gallery) I decided to build my own. I know nothing about Safari Extensions or programming one, but I am a Mac developer and I know what I want, so I started developing.

One hour and three lines of code later I present to you Google Direct. The Safari Extension that will remove the redirects from the Google links by stripping the “onmouseover” events Google uses to trick the href link into the replacement link.

With Google Direct Safari extension installed I am a happy camper, my history is looking unique and identifiable (the same results but now with names and favicons).

‘Copy link’ also gives me the crisp, short, original URL instead of a indecipherable mess:

http://en.wikipedia.org/wiki/Croissant

Vs.

http://www.google.com/url?sa=t&rct=j&q=croisants&source=web&cd=1&
ved=0CCgQFjAA&url=http%3A%2F%2Fwww.cooks.com%2Frec%2Fsearch%2F0%2C1-
0%2Ccroisants%2CFF.html&ei=cCG4TtSiI6TX0QHD5NTRBw&usg
=AFQjCNF7fQtjSwE9hpdNkIV9Ytl7orz-Og

Are there any downsides? Depends on where you stand. I am indeed depriving Google of knowing what links I followed and approximating how long I stayed (how long it took me to come back and click on another link of the same result set). On my side of the fence, where I usually stand, it’s an added bonus that I now also control a little more of my privacy with my new extension.

P.S. I ended up using Fine Cooking Classic Croissants recipe for making croissants. Now it has an elegant white orange hat and a title that was easy to spot in my history when I went back two days later – after tasting the results – to add it to my permanent bookmarks.

We’re slowly but surely making our way into the 21st century: Bruji finally has a Twitter account!

Follow @teambruji to hear all about new releases, happenings at Bruji HQ and short musings from Alex about games, comics and other fun stuff.

We’ve just released a new version of the Pedias, 4.6.8. It’s mostly for Lion-related bug fixes but if you’re running DVDpedia then you will also want this for the fixed IMDb search plug-in. There have been a few changes on their site lately and fields such as Duration and Rating weren’t being imported along with the other data.
Use the programs’ “Check for Update” command found under the program menu to download the latest version.

App Store users – 4.6.8 has been submitted and should be released soon. Thanks for your patience!

Update 2/9/11: The App Store updates have been reviewed and released.

In case you’re wondering how the Pedias will fare when Lion comes roaring into the Apple world, they are all 100% ready. We’ve been testing the latest version of the programs on the latest Lion developer release and everything is running smoothly.

We have yet to work out how we’re going to tackle Lion-specific features such as the new Full Screen View and how it’ll work with the already existing Full Screen View in the Pedias but we’re very excited about all the new possibilities. Now all we need is 10.7 released!

Update: Just fixed two small bugs related to Lion compatibility so make sure you download the latest version (4.6.7) for the programs if you’re on Lion.

Since the Mac App Store is Intel only, developers have to submit applications that are stripped of all PPC code. Slowly more and more developers are building their applications Intel only, given that the latest versions of OS X, Snow Leopard and soon Lion, are Intel only. The Pedias rely on a large number of external frameworks, so it was not as simple as changing the build setting in Xcode. While the transition happens here is an easy command we used to find PPC code used in our applications.

find Bookpedia.app -exec file {} \; | grep "ppc"

Of course run in Terminal while inside the build directory and change Bookpedia for your app name. Should any frameworks or libraries be reported to contain PPC code, you can strip the PPC without rebuilding by using the lipo command.

lipo -remove ppc AFramework.framework/AFramework -output AFrameworkIntel

I stored these new Intel-only versions of the frameworks to be used by Xcode when building our software for the Mac App Store. Of course there is also the option of doing the stripping to the entire app after building with the ditto command (but I prefer to do modifications before Xcode’s final code signing step, even though Mac App submissions are re-signed for any changes during upload).

ditto --rsrc --arch i386 x86_64 Bookpedia.app Bookpedia-AppStore.app

Hope some developers with larger apps will find this useful.

Today we had the rare opportunity to see where Apple devices are born. Luckily we were allowed to take a few pictures and with the sun just right, it was a magical moment.

We decided to take the office outdoors on this sunny Sunday afternoon. (Click on the images to view larger.)

Version 4.6.5 is just a small update but it fixes some nagging bugs, especially for the RTF text export (which didn’t encode correctly for diacritics and languages with characters not found in ASCII). The search plug-in architecture has also been completely revamped along with fixes to most of the plug-ins for retrieving more data, in particular larger cover images where available.

To get the update just run your current Pedias and use the ‘Check for Updates’ command found under the program name.

For Mac App Store users – the update has been submitted for DVDpedia, Bookpedia and CDpedia and hopefully they’ll be approved soon.

DVDpedia user Chas has written an info view template, with the help of Forum user Jonas, that includes some nifty links to Wikipedia and IMDb.

Just click on the little icons next to a name and the relevant page will open. Of course the possibilities here are endless – icons like these could be used for links to Metacritic, Rotten Tomatoes, Hulu… (Reminds me of the LeoTab info view template which incorporates a trailer and cover image search.)

You can download the template from our Extras page. I hope you enjoy it; thanks Chas!

A lot of developers are in the process of rebuilding their apps for the Mac App Store. One of the guidelines is not using any update mechanism and leaving the updating to the App Store. Like most developers we also use the Sparkle framework to do our non-App Store updates and figuring out how to build a version of your application without Sparkle can be frustrating. Some developers have already solved it in clever ways – our favorite being Gus Mueller from Flying Meat who uses a script to run a find and replace:

Then when my build script is run for App Store builds (-s) it’ll use /usr/bin/sed against Acorn’s project.pbxproj and replace all instances of Sparkle.framework with Noop.framework. Then the automated build takes place, and Noop.framework gets copied in instead of Sparkle.

But we feel there’s still space for another solution on how to conditionally include Sparkle:

1. You should have a configuration for the App Store. It can be created under the project settings “Configurations” tab. You should duplicate your Release configuration for these new settings.

2. Remove Sparkle from being automatically included in all linker calls. To do this remove it from under the Targets–>Link Binaries With Libraries.

3. Under all your regular configurations (Debug, Release, …) add Sparkle to the linker flags. Open the build setting and set “other linker flags” to “-framework Sparkle”.

OTHER_LDFLAGS = -framework Sparkle

4. You now need to remove Sparkle from the Mac App Store application folder after building it. Create a new custom script build phase to run at the end of your build (Custom Package Processing above) and make the script the following (do make sure that the value of $CONFIGURATION matches the name you set  your new configuration for Mac App Store releases):

#!/bin/sh
# Remove Sparkle Framework for MacAppStore
if [ $CONFIGURATION == MacAppStore ]
then
rm -rf "$TARGET_BUILD_DIR/$FRAMEWORKS_FOLDER_PATH/Sparkle.framework"
fi

The above takes care of the physical framework and linking but you still need to remove any code that calls the Sparkle framework. To do so set a variable in the Mac App Store build that you can use in your code to conditionally include Sparkle calls.

5. In your Mac App Store build setting set a flag, we use:

OTHER_CFLAGS = $(OTHER_CFLAGS) -DMacAppStore

6. Encapsulate all  your sparkle code with #ifdef preprocessor directives.

#ifndef MacAppStore
[[SUUpdater sharedUpdater] checkForUpdatesInBackground];
#endif

7. Don’t forget to update your interface if necessary. Remove any menus and check for update preferences. Include the menus programmatically for non-Mac App Store builds at applicationWillFinishLaunching:

#ifndef MacAppStore

// Insert Check For Updates menu
NSMenu *mainMenu = [NSApp mainMenu];
NSMenu *appMenu = [[mainMenu itemAtIndex:0] submenu];
NSMenuItem *uploadMenu = [[[NSMenuItem alloc] init] autorelease];
[uploadMenu setTitle:NSLocalizedStringWithDefaultValue(@"Check for Updates", nil, frameworkBundle, nil, nil)];
[uploadMenu setTarget:self];
[uploadMenu setAction:@selector(checkForUpdate:)];
[appMenu insertItem:uploadMenu atIndex:1];

#endif

The same method can be used for the eSellerate registration engine. The linker flags would be, “-lEWS -lValidateUniversal” and you would remove both the libEWS.a library and the compressed .zip version of the engine. Hoping the following proves useful to a few developers. Code on.

Our first few weeks on the App Store have gone well and even though there have been some minor confusions both on our part and the users’, all in all it seems to be a good addition to our distribution channels.

The one niggle I have is about demo versions. We can send users from the App Store to our website to download the demo and try out the programs for free but then they have to delete the demo in order to purchase the full version from the App Store. This is not the best user experience, especially if users think that their data will be affected by the deletion of the program (it won’t – the Pedias keep their data separately from the applications for exactly this reason).

Of course the time-lag between submitting an update and getting it approved is also a bit of a stumbling stone because we never know how fast the process will be. With our latest update (4.6.4) now in review, the first one we’ve done since the release of the App Store, that’s not critical because there weren’t any major bug fixes included. But I can understand that it might be frustrating for Mac App Store customers to have to wait for an update when they know that it’s out and available on other channels. We’ll have to see how this plays out in the future.