Entries Tagged 'OS X' ↓

So, lets say you are working in XCode 3, and you are trying to build a PyObjC app but for some reason the python code you wrote isn’t getting called.

If you are seeing weird errors in the console when you run the application (specifically “Could not connect the action <your_action> to target of class <your_AppDelgate_class>”), here’s what it probably is: In the AppDelegate python file that XCode creates it uses spaces to do the indentation of the methods.

I hail from a land where tabs are used for such tasks, and the use of spaces is look down upon in much the same way that pick ones nose in public is.

At any rate, what’s happening is when the code is compiled/run the python interpreter is not recognizing the new methods that I put in (using tabs to indent) and instead of giving me a warning about inconsistent indention, it fails somewhat silently in that it groans it can’t hook the action up to the class and that’s it. It wasn’t until I turned on the invisible characters that this occurred to me that it might be the root cause of my problems.

Once setting all of the indentions to be the same, I chose tabs, everything worked like a champ.

By the way, if you are looking for some tutorials for PyObjC in XCode 3 (there are a ton of XCode 2 tutorials out there, but things have changed ever so slightly in 3), be sure to check out these links:

• PyObjC Hello world for XCode 3
• PyObjC Resources

I just finished trying to use XCode 3’s built in support for Subversion. It did not end well.

For starters I created a new XCode project, ran it to make sure it could build, and then decided to check it in to svn so that I would have a “clean” starting point in case I ran into problems. This is how I normally work in other IDE’s, and I’ve never had a problem. Until today.

After setting up the repository in XCode I couldn’t find how to set the project so that XCode would “know” it was under version control (or SCM as XCode refers to it). If you look at the project’s properties, there is a drop down list the lists the available repositories (or it offers to let you set up a new one, which is a nice shortcut). However, the repository I just added is grayed out. After a half hour of trying various “obvious” things I gave up and googled around.

It turns out that XCode can’t create and then check in. The project has to be put into the repository, then checked out before XCode will recognize that it is under source control. Very unusual, but what ever, I decided to play along.  I used XCode’s svn browser (which isn’t half bad) to upload the code, then deleted the project and checked it out.

And right about then is when it became obvious that I was traveling the wrong way on a one way street. Here’s an executive summary of what I found so very, very, very wrong with XCode’s SCM integration:

1. I had to create the project, check it in, then check it out for XCode to realize that it was under version control.
2. Although XCode has an svn repository browser that allows me check in and out the code, it doesn’t seem to know anything about XCode projects as it checked in the build directory without asking. For me (and a lot of developers I know) the last thing I want in version control are files that are going to change constantly (i.e. object files). Checking in a finished version, fine. Checking in a ba-jillion intermediate files: fail.
3. After checking out the project, XCode began complaining about there not being a lock on a file in the build directory. The error message actually said “This might be a bug, please report it.” Sorry Apple, I’m a nice guy, but I’ve got limits. This seems like something that shouldn’t happen on a fresh project (i.e. all boilerplate code, I haven’t done a thing to the project yet).
4. Deciding that I might be slightly smarter than the computer, I decided to delete the build directory in the repository. I tried to refresh the project to let it know there was a change it might need to be aware of. Instead I was made aware of the fact that there doesn’t seem to be one central view of what’s changed for the project. The near-useless SCM menu item in the project reported that one file had change, and I could not seem to get it to even look at the project as a whole. Maybe I’m spoiled by the way Eclipse handles this situation (which provides a bunch of clues in different areas, but all of which lead to a pretty straightforward GUI for dealing with changes). Even TextMate handles this decently (just not as good looking as Eclipse).

By this time I just gave up. I removed the repository connection from the project settings, and decided to just go Command-line for doing my updates/commits. Life’s too short to be chasing my tail on stuff like this.

I’ve been messing around with Cocoa for a few weeks now, mostly trying to make an OpenGL program. I’ve been making good progress, but man, it does get tedious. I’m not an OpenGL expert, so I’m constantly needing to look things up to make sure I’m on the right track.

Last week at an Apple ADC Tech Talk I saw an example of Quartz Composer.  I had only vaguely heard of Quartz Composer before and hadn’t really looked into it. It turns out that it is a very useful tool for building a neat GUI quickly, and is available as part of the Xcode tools. After getting home from the talk I played around with it and was able to build lots of cool demo-type apps very quickly.

And then… I discovered that it can be integrated into Cocoa apps very easily. I mean, I found this great tutorial on the Apple Dev site, and within 5 minutes I had a Quartz Composer (QC) window running in my test app along side my OpenGL test window. And not a line of code was written. The absolute bets news is that you can expose the internals of the QC window to the Cocoa framework and then manipulate the QC object from your program!

That just rocks so hard. Now I can focus on the mechanics of my program instead of worrying about the mechanics of OpenGL. Of course, the QC isn’t 100% efficient as hand tuned code, but for most of what I want to do with it, its perfect! Thank you Apple!

As a side note, if you are interested in doing Mac development and you aren’t a member of the ADC (Apple Developer Connection), you really owe it to yourself to go sign up for one of their free accounts and check it out. Its a great resource for all things Mac and OS X.

There’s a bit of controversy going on about Mark’s post about full screen writing apps. Mark doesn’t quite see the point of the application (it basically is a word processor that takes up the whole screen) and makes some comments about how he doesn’t like this. His comments were a bit over-the-top, and of course, people took exception to this.

But this is nothing new. Emacs vs. vi, Whopper vs. The big Mac, Windows vs. Mac vs. Linux, Kirk vs. Picard. There have been many holy wars before, and there will be many more. And like most of them, this is one is over something seemingly small and insignificant.

For some people these apps are the best thing since sliced bread. Myself, I don’t really get the appeal of the application. If I want “full screen” editing, I usually just maximize the window, but I’m simple like that. To each his own I suppose, no one is forcing you to use the app.

But one thing I do get is the cool free publicity that these apps are getting! WriteRoom is the leading full screen editor for the Mac, and with Mark’s blog post making the front page of Reddit, I imagine that it is getting a lot new traffic which translates into new sales. At $24.95 a pop, even a dozen extra sales will mean a few extra hundred dollars for the developer.

That’s not too shabby. Hopefully this little flare up will result in the developer (Hog Bay Software) winning a few new customers. Mac Developers can use all the free attention they can get…

When working with a Cocoa project (in XCode), if you decide to add a .cpp file (and it’s .h file) to the project you might notice a problem when building. I banged my head into this for about an hour before figuring it out.

When I added the file(s), I did so by clicking on “New” and selecting a C++ file under “BSD” because it was the first option that I saw. It turns out when you do this, the Cocoa project settings will attempt to compile the files as Objective-C files (which they are not). This results in cryptic messages about a “parse error before” in you .h file.

The solution is to right click on the .cpp file, select info, then change the file type to “sourcecode.cpp.objcpp”. This tells XCode to use the Objective-C++ compiler to build the files, and from then on everything *seemed* to work ok. I’ve never worked with Objective-C (or Obj-C++), so I’m figuring this out as I go. If something bad seems to happen, I’ll post a follow up to let everyone know.

I had the Petit DosBox from OS X up and running a while ago, but today when I went to run it I kept getting an error about libSDL not being found.

Last year I had an “incident” that basically required me to re-run the 10.4 installation. I think when I did that it must have wiped out the symbolic link I had made to get Petit to run. If you are finding yourself in this situation, here’s what I did to get it up and running (Mac Mini running OS X10.4.5):

WARNING: Only attempt this if you are confident of your computer skills *and* you have backups of your important data. This is a fairly safe thing I’m describing, but you are doing it at your own risk. I’m merely pointing out what I did and how it worked for me. Your mileage may vary. Proceed at your own risk.

1. Open up a terminal window.
2. Type in cd /usr/local/lib and press return.
3. Type in ls and press return. Odds are there is nothing there.
4. If you don’t see anything that says SDL, type this in: sudo su and press return
5. Enter your system password. (Basically you are going to run as root for this next command)
6. Your prompt should now say “root”. Type in (or cut-n-paste) this line: ln -s /sw/lib/libSDL-1.2.0.dylib libSDL-1.2.0.dylib and press return.
7. Type in ls and press return. You should now see libSDL-1.2.0.dylib. At this point try running any Petit dos program. If it works, yaa! If not, you might be missing the SDL installation. I’m not sure if it comes with the Mac by default or ifI had installed it manually.

If you have success or failure with these instructions, please leave a message in the comments. I’ll try to help out if I can (but no guarantees).

Its out! If you are running a Mac, you need to run the Camino web browser. (Think of it as Firefox for the Mac.)

Go get it now!

Perhaps I was a bit hasty in my posting the other day when I claimed that Firefox was using less memory than Camino. After a day or two Firefox’s memory usage had climbed up quite a bit. So I’m going to amend my statement and say that they both seem to use a lot of memory over time.

If nothing else, Camino scored another point with me when Firefox crashed on me the other day. Plus using Firefox on the Mac isn’t as satisfying as I thought it would be. The Adblock plugin doesn’t work quite the same as it does in Windows, and that was a major disappointment. I’m sick of the flash based ads that are running everywhere that spike my CPU to 100% and make the whole system grind to a crawl. I was really hoping that Adblock would help with that, but I found it difficult to get it to mark a site as “needing to be blocked”. Another point for me was that Camino uses the native OS X buttons, where as Firefox uses the plain HTML web buttons.

On the bright side, Firefox does seem to handle flash better than Camino. The CPU only goes up to about 75% on the bad ads. *sigh*

What’s the lesson in this? For me its to make sure the next desktop computer I get has a minimum of 1GB of memory. Trying to skim by on 512MB in my Mac Mini was a bad idea.

I’ve been struggling to find a IDE to work with Python code on the Mac. I really really really wanted XCode and PyObjC to work, but there just isn’t enough of the goodies (code completion, etc.) with that combo to make me happy. I know, real programmers don’t need the extras, but I like using them to help me be more productive (especially when I’ve got limited time to code/play).

The other day I thought about Eclipse. I use Eclipse at work for Java development, and I’ve got to say I really like it. I decided to see if a)Eclipse runs on the Mac without looking like ass, and b)To see if there was a Python plugin that would allow Eclipse to recognize/work with Python code.

The answer to question a is: Yes, Eclipse runs on the Mac and so far (after an hour playing with it) it looks nice and runs pretty well.

The answer to question b is: Yes!Pydev brings a lot of the Java-mega-editor-goodness of Eclipse to the world of Python. It still needs a little bit of work, but so far it is looking pretty good!

Just as a bit of history (in case anyone cares) the editors I’ve tried to do Python development with on the Mac are: TextWrangler, XCode, XEmacs, and vi. These editors are all ok, most can color code the source with no problem, but none of them really brought everything I was looking for to the table. Its probably a moot point to even mention it though, I’m sure that in 6 months they will all have advanced in some way (like the usually do).

For now, it looks like Eclipse is my official IDE. Which makes me kinda sad, XEmacs isn’t moving forward with me like I thought it would. *sigh* Such is life I suppose.

The Drunken Blog is always a good place to catch up on news. ther other day while reading the site I saw this article: The dirge of NeoOffice.

I’ve been trying to use OpenOffice on my Mac for the last few weeks (specifically to do spreadsheet work) and it has been just downright painful. Apparently my transition to the “Mac Side” is complete, the thought of cranking up the X11 package makes my skin crawl.

I was thinking that NeoOffice might be a solution to my Office needs and allow me to have the pride of using OpenOffice (which I do like on Linux and Windows). But after reading this article, it sounds like I might be better off getting the MS Office package for the Mac.