Archive for the 'Cocoa' Category

Reminder: Picture Switcher sale ends soon

Just wanted to remind everyone that the $10.00 off sale for Picture Switcher ends tomorrow at 11:59 PM EDT.  Grab it before it’s too late!

Introducing Polish: A new framework

A month ago, Paul Kim over at Noodlesoft made a post about a proposal for a new way to install. In it, he described how it might be advantageous to display a dialog to the user asking them if they’d like to install the application if it were running from a disk image (or some other unwritable media).

As it so happens, I had already intended to write some code that checked that very thing, to fix a problem with Picture Switcher. I hesitate to call it a bug — it’s more like an unintended side effect. The problem was that in my last version, I decided to add in a dialog asking the user if they would like PS to run when they logged in. All fairly standard. What I hadn’t taken into account (and this would be a bug), was users running PS from the disk image. I should have put in a check for that. The unintended side effect is that, after having said yes to that dialog, every time they logged in the disk image would be mounted and run PS from there. I hadn’t even known the login items would do such a thing. Suffice to say, I’ve gotten some support emails about this issue.

So, I needed to write some code to both check if PS was running from a disk image and some code to fix the login item problem. I was working on another portion of PS when Paul made his proposal, but this past week I came back to fix up that section. The end result: a new framework.

Polish handles this and also handles login items. It will check if you are running from unwritable media OR running from the user’s download folder (for those of you using zip files or internet-enabled disk images), and if it is, will display a dialog asking the user if they’d like to copy the application to a different location. Polish can also check to see if the application is a login item, and if not display a dialog asking the user if they’d like it to run when they log in. You don’t have to check for either — you can check for whichever one suits your needs.

I wrote up my own code based loosely on the LoginItemsAE code for Polish, using NSAppleEventDescriptor (mostly — there are a few lower level AE calls that are still present). It does work. You can use Polish for the preferences section of your application, if you allow the user to add/remove it from the login items list. You’re not limited to just the check.

Here is the dialog presented to the user if they are running from some unwritable media or running from their download folder:
Polish's copy dialog

Note that I decided to use the term ‘copy’ rather than ‘install’ — I felt that had less of a psychological factor attached to it. ‘Install’ implies that more than just the application may be copied to the hard drive.

Here is the dialog presented to the user when asked if they’d like the application to run when they login:
Polish's login item dialog

The images are taken from the test application that comes with the framework. “Polish Test” will, of course, be replaced by your application’s name.

I can hear a few of you now: “Oh no, those dialogs are terrible! That won’t go with my application…” Well I actually thought of that. If you are using some sort of custom window scheme, or just don’t like they way the dialogs look, you can customize them or entirely replace them with your own window.

The download for the Polish framework contains a built version of the framework, a test application, the source to both of those, and documentation.

Head on over my Developer page to download it. The reference is also available there online, if you wish to look through it before downloading Polish.

For anyone curious as to why I named the framework “Polish” — well, I think the framework adds some polish to an application. But also, the Sparkle framework had a little influence, as well. ;)

Updated & New Code

For all of you developers who are using my code (all 3 of you), I’ve updated my DSClickableURLTextField and DSGeneralOutlineView classes, and added a new class, DSGeneralTableView. I’ve also written up some class references for these classes, so things are a little more documented now.

Jens Miltner emailed me some fixes to some subtle bugs with DSClickableURLTextField, and I added some functionality. Here’s the change list for it:

    Changes by Jens Miltner:

  • Fixed a problem with the text storage and the text field’s attributed string value having different lengths, causing range exceptions.
  • Added a delegate method allowing custom handling of URLs.
  • Tracks initially clicked URL at -mouseDown: to avoid situations where dragging would end up in a different URL at -mouseUp:, opening that URL. This includes situations where the user clicks on an empty area of the text field, drags the mouse, and ends up on top of a link, which would then erroneously open that link.
  • Fixed to allow string links to work as well as URL links.
    Changes by me:

  • Overrode -initWithCoder:, -initWithFrame:, and -awakeFromNib to explicitly set the text field to non-editable and non-selectable. Now you don’t need to remember to set this up, and the class will work correctly regardless.
  • Added in the ability for the user to copy URLs to the clipboard. Note that this is off by default.
  • Some code clean up.

I cleaned up the code a bit in DSGeneralOutlineView, and also added a new delegate method. Also of note, I added a parameter to the delegate method allowing you to create a custom drag image. If anyone is using this with DSGeneralOutlineView, you’ll need to update the delegate method to include the new parameter.

Here’s the change list for it:

  • Cleaned up the code a bit.
  • Added a new parameter to the delegate method that lets you create a custom drag image.
  • Added a new delegate method that will inform you of a failed drag.

DSGeneralTableView is a NSTableView subclass to go along with my DSGeneralOutlineView class. The two classes are almost identical, with the exception being one delegate method which calls with a row number for DSGeneralTableView rather than with an item with DSGeneralOutlineView.

The class references I wrote up are included in the download file for the respective classes, and are also available for viewing online:

DSClickableURLTextField Class Reference
DSGeneralOutlineView Class Reference
DSGeneralTableView Class Reference

Hope y’all enjoy the updates, and happy coding. :)

Yes, I’m still alive

Hey all, sorry for the lack of posts. I hadn’t intended to go two months without posting. I suppose this makes it more of a rocky start than a bumpy one.

I thought I’d give a status update on where I am with things:

An update to Picture Switcher is about 88% done.
An update to Web Control is about 60% done.
An update to Desktop Log is about 40% done.
An update to Pref Setter is about 10% done.

As you may guess from the above, I’m spending most of my time with Picture Switcher. It’s keeping me rather busy, which has contributed to the lack of posts (though I’ll be honest and say not totally).

If it helps any, my friends are all wondering where I’ve disappeared to as well. ;)

Of Kqueues and Max Open Files

Kqueues are a great thing. They let you keep an eye on files, sockets — anything that has a file descriptor. It takes very little code, and you don’t have to worry about manually polling or the like. Awesome stuff.

There is one thing you do have to worry about, though. Your app’s number of open files. I ran into this problem in a spectacularly bad way. When I first released my application Picture Switcher (it’s a status menu item, which you can use to switch your desktop picture(s)), I had it going through the file system and checking the modification dates of the folders containing the pictures Picture Switcher knows about — when the user clicked on the status menu. This was a Really Bad Way to do things — it made the menu take a while to actually show (and if the user had a lot of folders, it could show the SPOD). So, when I was working on version 1.1 I decided to use kqueues to watch the folders instead of going through them when the user opened the menu. It was great, I didn’t need to worry about manually looking through all the folders anymore.

I get that all fixed up, and release 1.1 into the wild. And the crash reports started pouring in. I was genuinely puzzled by the reports — it had Picture Switcher crashing while trying to load a system framework. After looking at the crash logs, I thought maybe I had some sort of incompatibility with some haxies. The users who were sending me the crash reports all had quite a few of them installed. So, I began installing haxies on my system. One after another after another. And I still couldn’t reproduce the crash. I finally decided to make up a version that logged quite a bit of debugging info to a file on the Desktop, and sent that to a few of the people who were trying to help me figure it all out. This was after a few weeks had gone by — yes, I probably should have tried that earlier. I began to see what was going on, though I still didn’t know why. I saw that it was failing to open some of the file descriptors for the files, and then crashing a bit later when it tried to load a system framework. Finally, I figured it out by meticulously reproducing a user’s folder hierarchy on my system — I was hitting the max number of file descriptors I could have open and Picture Switcher was crashing after that because it couldn’t load anymore. I came to find out that system frameworks and plugins and such count as open files, and then on top of that I was keeping a file descriptor open on the user’s folders.

It didn’t take me long to search and find out how to raise the number of file descriptors I could have open. A simple call to setrlimit() would up my max number from the default 256 to the system defined max number of file descriptors an app can have open (by default, it’s at 10240 right now). And so finally, I implemented that and released version 1.1.1 (almost a month after the previous release). My users were happy, I was happy, and I learned it was a Really Good Idea to do a bit more testing before releasing, especially on something variable like this.

Do any of y’all see the flaw there? If not, don’t feel bad — I didn’t either until just recently. Or rather had it come back at me.

A few weeks ago, a user emailed me to tell me that Picture Switcher was crashing on launch. I didn’t get a crash report with it, but immediately I thought “Hmm, this seems like the max open files crashing bug.” So I emailed him back, asking if he was using the current version and asking for the crash report. He emailed me back, letting me know that he was indeed using the latest version, and also attached the crash log. Looking at it, it seemed at first that it was a different bug — the code was crashing in a method where I get the display names. So I whipped up a test version to make sure I didn’t have a bug there, and asked him to run it and send me the console log. He did, and lo and behold, there in the console output, were a few messages letting me know that it was indeed the max open files bug. I had added a log message that output an error letting me know it couldn’t open any more file descriptors when I was debugging this and had forgotten to take it out — a good thing in this case.

My immediate response to that was “Ack, it’s the specter of the max open files raising its ugly head at me again!” At first, I thought that maybe the setrlimit() call was failing on his machine for some reason, and sent him another test version that logged it. But no, it was working fine. This, of course, made me realize that I hadn’t totally thought things through the last time. 10240 file descriptors seems like a lot, but obviously it is a limit and I should have thought about that during the last release. All I can say to that is mea culpa — I had worked a month trying to figure it out and just wanted to get the fix out there. I’m sure some of y’all have been in that situation. But still: Bad programmer, bad!

I sat there for a while thinking through this. I realized this was a really bad thing from the get go. While I could raise the limit of open files, I really hadn’t thought what that might do to the system. The system has a max number of open files for the entire system — set at 12288. That’s only 2,048 files more than what I set. So, actually thinking that through, I realized that if someone had enough folders that Picture Switcher is watching, I could potentially greatly limit the rest of the system’s resources here. Doing things like that is something akin to using a sledge hammer to put a tack in the wall — way overkill, and potentially damaging. Not a nice thing to do. Bad programmer, again.

This time, I set down some ground rules for myself to follow. 1) Don’t raise my number of open files to the max, 2) figure out some way to know when I’m about to hit that number, and 3) bring back manual polling if I do go over that number. Just a bit better this time.

After doing a lot of searching, I found out it’s not trivial to know the number of open files you have. I then decided to download the source to lsof from the Darwin source code to see how it’s done. I have to admit, it was a bit beyond me. So I needed to figure something else out. Finally, I came up with a solution. It’s not 100% foolproof, but I did do a bit of coding to fix things up if it doesn’t work. Here’s my solution.

I raise the max file descriptors to the max per process divided by 10, plus 300. That puts me at 1340, by default. The added 300 is a bit of padding so that I have extra descriptors around when I need to open things, and for the system frameworks and plugins that are loaded. In my header file, I added an instance variable for maxFileDescriptor, then used this code in the init method of the class:

struct rlimit myLimit; int mib[2], maxOpenPerProc = 0; size_t inputSize = 0; mib[0] = CTL_KERN; mib[1] = KERN_MAXFILESPERPROC; inputSize = sizeof(maxOpenPerProc); sysctl(mib, 2, &maxOpenPerProc, &inputSize, NULL, 0); myLimit.rlim_cur = myLimit.rlim_max = (maxOpenPerProc / 10) + 300; setrlimit( RLIMIT_NOFILE, &myLimit ); maxFileDescriptor = getdtablesize(); maxFileDescriptor -= 300; if ( maxFileDescriptor < 0 )     maxFileDescriptor = 0;

In the method I call to add items to the kqueue, I test to see if maxFileDescriptor is a valid file descriptor. This is a sort of kludge, but it does work. It’s not 100% foolproof, as I mentioned before, because there’s a possibility that there were more than 300 system frameworks and plugins that got loaded, which don’t get a file descriptor and hence this test would report a false negative. This is a slight possibility, but I’m not taking chances this time.

if ( isatty( maxFileDescriptor) || errno == ENOTTY ) {     /* Code to add it to a manual poll method */ } else {     /* Add it to the kqueue */ }

What isatty() does is check to see if maxFileDescriptor is a TTY. This isn’t ever going to be the case with Picture Switcher, but isatty() will set the global errno to ENOTTY if the file descriptor is valid but not a TTY (otherwise, it sets errno to EBADF).

If the check reports a negative, but I can’t open the file descriptor, I do a bit of cleaning — I add it to the manual poll method, then I remove a few of the items from the kqueue and add those to the manual poll method as well to free up a few file descriptors.

So for any of y’all out there using kqueues, do keep an eye on your open files count (you can do this with lsof in Terminal, or with Activity Monitor). If you’re even coming close to the max open files you have set (256 by default, if you haven’t changed it), you may well want to do something similar in your code.