Category: Coding (Page 3 of 3)

Well, I just wasted about 5 hours of my life trying to figure out a problem I was having with frameworks, bundles, and my new app. There is a nice way to embed frameworks into an application, as shown in an excellent video tutorial by Jonathan “Wolf” Rentzsch. The problem comes when embedding a framework into a plug-in bundle. I went through the tutorial, except embedding the framework code into my bundle. Things compiled fine, but when I went to run my app, it choked and complained that it could not find a method in a class within the framework.

Unfortunately the debugger was kind of flaking out on me…it was stepping at blank lines without any code and returning out of functions early. This led me to believe that maybe the debugger wasn’t looking at the right code. I couldn’t for the life of me figure out what was going on though. I tried doing a clean build of everything, making sure the frameworks were being included in the bundle, and that the bundle was in the Plugins directory of the app. Everything checked out fine. So if the structure was set up fine, why wasn’t the correct code being executed? I ended up finding the problem was two-fold.

First, I had an old version of the framework I was trying to embed in my ~/Library/Frameworks directory. The old version contained the class I was trying to use, but the class didn’t have the method I was calling yet. I removed that file, and tried running the app again only to find that it couldn’t find the Framework it was looking for. Aha! That explains why the debugger was acting funky….but why isn’t it finding the framework that is included in the bundle?

After poking around a bit more, I came to the point where I set the installation path to “@executable_path/../Frameworks”. Apparently, when embedding a bundle, the @executable_path is set to the application path and not the bundle path. I suppose this makes sense, after all the bundle isn’t the primary executable…it’s just a dynamically loaded library. However, there is no linker definition for @bundle_path or something similar, so unless the bundle is always at a hard-coded path, there is no way to embed a framework into a bundle.

The work-around I ended up doing was just to embed all the frameworks I need directly into the application. This bothers me though, because I know some of the frameworks will only be used in a single bundle, so it doesn’t make sense for them to be embedded in the app and not the bundle.

Anyway, I’m posting this here in the hopes that I can save someone else hours of confusion. 🙂 If anyone knows of another way to embed frameworks into a bundle without hard-coded paths, send me an email.

For awhile now, people have been requesting that I put something in XRG’s interface to allow them to turn off the UI Elements, such as having the XRG icon shown in the dock. There has always been kind of a hack to do this, by adding the following text to the app Contents/Info.plist file:

<key>NSUIElement</key>
<true/>

This is fine, but in Panther it got a little bit more difficult. Panther now caches these Info.plist files. This is great…the more caching the better, especially for things like Info.plist files that don’t change often. The bad thing is that the cache doesn’t check the last modified date of the plist file. Instead, it checks if the modification date for the .app directory has been changed. I’m not sure why they would do this, as it seems to me that checking the plist file modification date would be just as easy, and that way they know they have a copy of the latest file.

Some people have remarked here that if you move the application to a different directory and back, that the cache gets updated and all is well. This is fine, if a user is changing this value by hand and using the Finder to do it, but it leaves a little to be desired if you are trying to change this value programmatically. I thought of just moving the .app to “X Resource Graph 1.app” and then back real quick, but that doesn’t seem like a nice way of doing things. So that got me thinking, and I found a much easier way to do it using the simple Unix executable, “touch”. I was very pleased to find that making the change manually and touching the application worked just fine. Since it’s very easy to run a quick system command from code, this shouldn’t be a problem at all, so it should be in the next version of XRG.

Anyway, so if anyone is trying to do this same thing from code, hopefully this will help. Now all I need to do is find a way for the change to take effect without having to restart the app. Maybe some kind of hack on the Dock like the one other coders use to add rogue menu extras.

Brent Simmons, the author of NetNewsWire has set up a Yahoo Groups mailing list for people interested in setting up their own Mac software company. Since I’m very interested in starting my own shareware company, I signed up for the list. Hopefully the list will generate a strong community of smaller software developers.

Along the same lines, Slashdot posted an article today on the same topic, but not specific to the Mac platform.

MacShareware.net today released an SDK to help save Mac software developers time when releasing their applications. If you have released a piece of software before, you know it is a ton of work. I usually spend a couple of hours writing something up, and posting it to all kinds of web sites. With MacPAD, it will be a lot easier. From their site, it sounds like Windows developers already have something similar to this…

Basically, how it works is you create a PAD file with information about your application release. This has a short description, long description, release notes, etc, all contained in an XML file. You then upload this file to your website and let other websites such as VersionTracker and MacUpdate know where your PAD file is. Then, all you have to do to release a new version is to simply update the PAD file at that URL. Other servers should pick up the change in a matter of hours.

I really hope that other software sites adopt this method of updating software, as it would make my life a lot easier when releasing XRG. The project is open source and has a page on SourceForge. You can find out more information about the MacPAD SDK here.

Jonathan Rentzsch has an interesting blog posting listing the top 10 things he loves about Objective C and the top 15 things that he hates about Objective C. If you are at all interested in Objective C, check it out.

I would have to say that categories is my favorite Objective C feature. In case you don’t know, categories allow you to add methods to a class definition without changing the original class. This means that you can add functionality to classes that you don’t even have the code for. In the past, to accomplish something like this, I would create a subclass of the original and add my method there. Categories are much more useful because any object of the type that is being categorized automatically obtains the new functionality without any changes in code.

For me, coding at work and coding at home have always been different. When I started my job at Ephibian, I learned a lot about web and database programming, but at home, my personal site never really improved, or changed much at all. My take on it is that when I get home from work, I don’t really feel like doing anything involving web programming or database programming because I’ve been doing that all day.

I’m reminded of something an old friend said back when I knew him in high school. He was very bright when it came to anything having to do with computers. I asked him what profession he was planning on getting into after graduation, and he said he was interested in becoming a doctor. I asked him why not do something like CS, and he claimed that computers were for fun and enjoyment…he didn’t want to ever have computer related stuff turn into work. At the time, I thought he was kind of crazy, now I understand what he meant by that comment.

Now, I’m not saying that I don’t enjoy programming. Quite the contrary actually…I love to program in my spare time even though I do it all day at work. But recently I’ve been considering finding a job doing Macintosh-related development after my wife, Katrina, and I move next year. Ever since starting XRG development, I’ve really enjoyed developing for the Mac platform. Objective C is a nice language and Cocoa makes things easy to do. However, I don’t want to give up my hobby of developing Mac freeware/shareware, and I’m concerned if I get a job developing at a Mac software company, I will no longer have the desire to continue developing personal projects such as XRG.

For other developers out there, what do you think? Are there types of coding that you love doing so much that even though you code at work, you still have no problem coming home and coding something in a similar language or for a similar platform?