top products

One of the very handy features in Cocoa is NSCoder, it allows you to easily write your objects to a file. Your objects need to know how to encode and decode themselves with an NSCoder and that’s it.

While this is pretty handy it also ties the created files tightly to your application. If you try to open such a file you need to have all the needed classes at hand. That’s a pretty ugly problem if you just want to know what’s inside the file.

Yesterday I had this exact problem and I’ve played around a bit until I had a tool that allows me to inspect any file that was written with an NSKeyedArchiver. NSArchiver is not yet supported.

Thanks to ObjC 2 this was relatively easy to do: If a class is missing, create it and retry to unarchive. That’s pretty brute force but I didn’t see no other way. With some private methods in NSKeyedArchiver I was also able to get all the keys of an Object. With the classes present and with the keys available I could then read all the Objects.

The tool is available here: PlistExplorer.zip

Usage: PlistExplorer <file>
It’ll write the content to stdout so you might want to pipe it to something like TextWrangler.

The tool comes with no warranty whatsoever. Use at your own risk.

Karsten (@_karsten_)

CuteClips 3 has been out since last May now and I’ve still had one big thing to add: Localization. Even though I’ve had the localized Nibs and strings files around, I didn’t find time yet to release a localized version. The long know problem was again that features were added I needed to update all those Nibs again.

After reading Pimp My Code 17: Lost in Translation I knew that this was gonna be the way to go for CuteClip’s Localization. I’ve finally had time to implement things. However, it was a bit messy and didn’t work out of the box as I would have expected it. So here’s a small Q/A of the questions that I came up with during the change.

Which strings go to which file?

Strings from the application that are used like NSLocalizedString(“key”,”comment”); go to Localizable.strings. Same as usual. Strings of Nibs however go into NibName.strings.
I.e: MainMenu.nib or MainMenu.xib has its strings in MainMenu.strings.

CuteClips uses plugins a bundles a lot. How are those Nibs looked up?

The lookup-change in DMLocalizedNibBundle.m is implemented on class-side in NSBundle. Every instance call is sent to [NSBundle mainBundle]. So all strings-files need to go to the MainBundle’s Resources folder.
If your plugins have a MainMenu.xib then there’s no separate file. If your plugin has a different name, like in CuteClips, you end up have multiple strings files.
I.e: Here i’ve got Localizable.strings, MainMenu.strings and OldUI.strings

How the heck do I convert my existing localized Nibs to strings files?

That’s a bit tricky! First you need to get the strings out of the Nib, which can easily done by using ibtool:
ibtool —generate-stringsfile MainMenu.strings MainMenu.nib

Not too difficult, but the devil is in the details: If that was a german Nib and you got a button called “Abbrechen” you wouldn’t find a line like “Cancel” = “Abbrechen”; in the strings-file. Instead you’ll have “Abbrechen” = “Abbrechen”. That doesn’t help much when your application tries to translate “Cancel” as it wouln’t find the key. Luckily that’s not the only information that you can find in the strings-file. Each translation also has a comment next to it that contains an ObjectId. Using this ObjectId you can use the english MainMenu.strings to convert the keys of the german MainMenu.strings. That doesn’t work for all translations though, so you need to fix the files by hand as well.

Another problem here is that many translations appear multiple times, so you might want to get rid of the clones.

I’ve written a little Smalltalk tool in VisualWorks but it should work in any Smalltalk Environment. Usage is simple:

    to convert the translation-keys to english:
    Converter new convert: '/Path/To/Project/German.lproj'
    to filter out the clones:
    Converter new filter: '/Path/To/Project/German.lproj'
     

The tool will create *.fixed.strings files by default.

You can load the tool at:TranslationScanner

I think that’s it.

One thing that i’d like to add: One of my resolutions for this year is finally joining Twitter. I did so on the last day of 2009 and my nick is _karsten_.

Happy New Year!
Karsten

Today all our services (briksoftware.com, snapplr.com, pdfkey.com) have been down for about 10 minutes. Some however may have had problems for much longer time, as we changed our IP address and DNS takes some time to propagate.

This was caused by the fact that we migrated to a new, more powerful server in order to better satisfy the sudden increase in traffic generated by the incredible interest Snapplr caused 😀

I apologize for any inconvenience this has caused you, but now we are Harder, Better, Faster, Stronger 😀

We are extremely excited today. Snapplr finally reached 1.0! After much coding, improving, and digging around Mac OS X internals we can finally share this great utility with you.

Plans for the future are grand, but of course we cannot reveal anything yet. Stay tuned, and enjoy Snapplr!

This year I’ve been on a trip to Rome during new year. I’ve visited Michele and we spent pretty much most of the time coding on Snapplr. After one week of rewriting the screenshot selection from scratch, we had a new beta of Snapplr available. We’re proud to say that the selection is now exactly like in Mac OS X, except that you can still decide what to do with the screenshot after it is taken.

In the previous beta one could not make screenshots of menus or utility windows. The problem was that Snapplr always activated and thus deactivated the frontmost application. That was needed because Snapplr needs the keyboard input for best usability. The system’s screen capture tool doesn’t need to activate and still receives the keyboard events. We thought that if this tool can do that, Snapplr can do that as well.

NSApplications can’t capture all keyboard events when they’re not active. This seems to only works for command line applications… and only if you do an animal sacrifice at new moon ;-). So we ended up extracting the screenshot selection into a new terminal tool that is now called by Snapplr upon activation. Unfortunately that also ment porting the NSView UI to a CoreGraphics UI.

During this week we really noticed that it totally pays out if you keep refactoring your code and if you have a good design. We could just drop a couple of classes in the main application and extract their functionality into the terminal tool without much effort.

We also updated the server-side of Snapplr. As of now it is not required to have accounts anymore. We decided that accounts are just too much of an inconvenience for the user.

The new beta is available to all existing beta users. The previous beta should automatically load the new version on launch.

Stay tuned, Snapplr just made a huge step towards final release.

Karsten

Yesterday I encountered a very strange bug/feature in Xcode. I just couldn’t run any application in Release configuration anymore. I always got “The Debugger has exited with status 1.” in the run-log. In debug configuration they worked, without Xcode they worked, in gdb they worked, but as soon as I tried to start them in Xcode in Release configuration it didn’t work. Not even a fresh new Project would work.

I tried removing the prefs but that didn’t help. But it seemed to be user-dependent. I could run my Projects in Release configuration when I logged in as another user.

This morning I saw the “GDB Log” setting in the Debugging Prefs. I activated them and compared the logs of Debug configuration and Release configuration. And this really showed the bug. I had a binary of a System-Framework in my Release folder and instead of the system-version it linked the application to this binary. To my bad it was a binary from a different mac, which is still running 10.4. This made the app exit right when it was started.
The solution was as simple as removing this binary from the Release-folder.

This GDB log is really a lifesaver sometimes!

Karsten

I just created yet another class with some instance variables and so missed the functionality of creating accessor methods for these instvars automatically. As I never really looked into the Refactorings of Xcode 3 I didn’t notice that they provide an encapsulation refactoring. Using this on an instvar nicely generates accessor methods. You have to apply it to all your instvars separately, but still it’s a great gain.

One thing they should improve though: why is the refactor command no submenu which shows all the available refactorings? This way the refactoring could be chosen much simpler.

Karsten

I think I’ll be in Chicago tomorrow evening. I’d really love to join in for PSIG, but I don’t have any idea on how to get there best, can anyone tell me how to get there? I’ll arrive in Chicago at 5pm and I’ll stay in Downtown near Harrison-Station at the Grand Park. I guess I can’t make it to PSIG in time, but I guess you guys don’t meet up just 5 minutes 😉

Karsten

There have been quite a lot of news about blocks in C recently. What I wonder however is: will there be a Objective-C block object that wraps such a new C block?

Thing is: You can’t send messages to C-Blocks, they’re just as primitiv as an int, or a float, even if they’re more complex. In Obj-C you also have string literals like @”a string”, which you can send messages to. Why not also have literal blocks like @[:arg | arg doSomething]? I think that would really make live a bit easier sometimes.

@[:arg | arg doSomething] might look a bit too smalltalkish for some people, but on the other hand the selectors in Obj-C also look just as cool as in Smalltalk.

Anyway, looking forward to seeing blocks in Cocoa.

Karsten

Yesterday at Esug Conference’s Social Event the winners of this year’s Innovation Award were announced. At Georg Heeg eK I worked on seaBreeze for the last half year. I’m proud to say that our project seaBreeze won the second price. The third price was given to iSqueak, a Squeak implementation for i-devices. The first price went to Dr. Geo, a tool for schools where they teach geografie.

seaBreeze is an Interface Builder like web-application to create websites using the Smalltalk based web application framework Seaside. It is either possible to start from scratch or to scaffold a user interface and take this as a basis to start in seaBreeze.

seaBreeze is soon to be available in the Cincom Public Repository. It’s licensed under MIT License so go and try it yourself! There’s also a commercial license, in case you need warranty and support.

Karsten