Broken iCal – Application Needed to fix it

After my calendar didn’t sync today using BusySync, I started poking around. The BusySync log gave a Google error saying that I had exceeded my quota. I’m not sure what it was pushing or pulling, but I took the opportunity to clean up my calendars. I had events back to 2002 in it that I didn’t need. In iCal, I selected the option to delete events older than 60 days. I quit iCal and restarted it a few times. That didn’t help. Next a tip said to search for ‘a’ or ‘e’ and then delete items in the results. Well, that was tedious as iCal kept crashing and freezing when I did that, but I managed to delete a lot of events. Then I went back through my calendars and looked to see that old events were still there (most had an ‘a’ or ‘e’ in it). I deleted those. Before all this I exported my calendar and then re-imported it. That didn’t help. My calendar was so screwed up after years of using iSync, trying to sync to Google and lots of testing, that some events were duplicated 50+ times.

Someone needs to write an app that goes through and cleans up the calendar with options like, delete items older than x days and delete duplicates (you can key off the title and date and time for a duplicate). Of course, this is a one time or infrequently used app, so the demo mode would have to be quite limited or no one would buy. I would write it, but I already wasted my time fixing it by hand. I should file a bug with Apple that the delete events item doesn’t work.

Does beta mean anything anymore?

I’m currently testing ReceiptWallet 2.0 beta and have been getting reports from people that say they’re using ReceiptWallet 2.0 (not saying beta) and are mad that they have problems. While I can understand being mad about having problems, but that’s why it is in beta so that people test it. I have several warnings indicating that the software is not finished and to backup data, but people seem to ignore those warnings. In my preferences, I have “Look for Beta Versions and Releases” as an option; I’m not sure people understand what Beta means, so I’ve changed it to “Look for Untested Versions and Releases”. Could that be clearer? When my website is redone, I’ll also make sure that any references to beta also indicate “untested”.

I think that developers have diluted the term beta by just throwing stuff out there and getting people to try it; for instance, look on VersionTracker for items that are beta versions. They are just mixed in with everything else and the unsuspecting consumer, says “oh, a new version, let me get it.” without realizing that beta means “untested”. I don’t throw my beta versions on VersionTracker because I want people to make a conscious effort to get the versions.

Half baked PPP implementation

I love that Mac OS X is built on a UNIX core as I can use a command line to do stuff and write shell scripts. However, in some cases, Apple has wrapped a pretty interface on top of some UNIX stuff and made a mess as such as with the case with Mac OS X server; I wrote about this awhile back. This is also the case with PPP. System Preferences (and under Tiger, Internet Connect) hides the underlying PPP implementation. For most people, this works OK, but the biggest problem is that if you enter your username and password (for providers that require it), unplug the modem and plug it into a different USB port, that information is no longer associated with that modem. This is because PPP tracks the modem based on UNIX /dev port, i.e. /dev/usbmodem1d11. Each USB port is uniquely identified and if you plug in a hub, it changes the /dev port as well. So this can be quite problematic and each time you plug in the device into a different port, you’ll get a different entry in Network Preferences. What a mess. To make matters worse, the PPP implementation uses the keychain sometimes and then sometimes picks the wrong entry in the keychain if there are 2 entries with the same account name.

So why would I care about PPP these days when most people connect over a broadband connection and have their Macs connected via AirPort or Ethernet? One of my clients manufactures cellular modems, so I have to write code to deal with switching ports. Dealing with the PPP password is a huge headache. This would be so much simpler if the wireless carriers used Mobile IP which doesn’t require a username and password (Sprint uses it in the US). Why carriers require a username and password, I have no idea. When the modem connects to the network, they know who is connecting based on the ESN (Electronic Serial Number) of the modem, so why not authenticate off that? It’s not like normal people can change the ESN (it’s illegal and the tools are not readily available).

I’m sure that Apple will continue to ignore PPP as it works most of the time for most people. They should be tracking the USB modem based on serial number or vendor ID and product ID; something that won’t change.

(Yes, this is beat on Apple week.)

Does anyone at Apple actually care about us developers?

I fired up ReceiptWallet beta on a Tiger machine today to check out a problem and it didn’t launch. Huh, I looked at the crash log and it said there was a problem with a symbol not found using the dynamic linker (I’m not sure why my testers on Tiger didn’t find this as it clearly doesn’t work). So, I look at my code and I have:

	[pictureTaker setValue:[NSNumber numberWithBool:NO]
		forKey: IKPictureTakerAllowsFileChoosingKey];

This code only executes on Leopard, so it should be fine. However, whoever decided to define this constant decided to define it as such:

	extern NSString *const IKPictureTakerAllowsFileChoosingKey;

instead of something smart like:

	#define IKPictureTakerAllowsFileChoosingKey	@"IKPictureTakerAllowsFileChoosingKey"

Why is the second one smarter? Because it allows people to compile in features that work on 10.5 while still supporting 10.4. I have checks in my code to not execute this chunk of code on Leopard, so that isn’t a problem. The problem with this is that while everything compiles and links, it crashes on Tiger.

Apple wants us to use new technology, but most of us can’t abandon Tiger users, so we compile against the 10.5 SDK with a Mac OS X Deployment Target of 10.4 as indicated we should do in the Core Data Release Notes.

Apple, please fix this!

Another set of bugs in Leopard

A number of weeks ago, I fought with Leopard to be able to use a magnetic stripe reader in one of my apps. The Apple sample code worked on Tiger, but broke on Leopard. OK, I reported that as a bug. Next, I looked at some new USB code in Leopard and that failed as well. After opening an Apple DTS incident, buying a magnetic stripe reader for them, and going round and round, they acknowledged the first bug and the second bug which was a workaround to the first one. DTS did send me code that finally did work.

This week, I fought with Leopard (or maybe it is Tiger) dealing with the Keychain. The Keychain (along with System Configuration) are some of the most confusing frameworks to write code. This weeks’ issue dealt with using the Keychain framework to get a password out of the System keychain (like for PPP passwords). If the user clicks on Always Allow, the method returns a -61 error which is a write permissions error. What’s the workaround? Well, if I get a -61 error, I put up the request again. While this gets me to the end goal, it really confuses the user.

Today was another bug dealing with the Image Capture. I wanted to add supporting Image Capture in addition to TWAIN as it might be more reliable. I got as far as implementing the UI and all the code, only to find out that if I scan once, when I close the scanner session, I get an error and then I can’t scan again. All that I’ve read indicates that the Image Capture Framework (ICA) doesn’t work properly when compiled against 10.5. This doesn’t surprise me as someone changed the TWAIN header files in Leopard so that UInt32s were changed to void * or vice versa. This, of course, causes lots of warnings that have to be typecasted. Scanning is one of those areas in the OS that doesn’t seem to get touched and no one seems to care. The scanner vendors write crappy drivers so they don’t complain and no one else is big enough to get Apple to care. Maybe things will change.

Can’t please everyone

Today, a very irate user sent me email complaining about the merging of ReceiptWallet and DocumentWallet. He wrote a very long email messages saying he felt ripped off and there is no mention of this on our website. Well, it isn’t mentioned on the website because it is in BETA and hasn’t been put into general release. There is no need to mention beta versions on our website (except for a small mention on how to get the cutting edge version).

As for being ripped off, shouldn’t people buy software for what it does today and not what it could do with an update tomorrow? Does the software stop working just because a new version comes out? Personally I think that the cost of ReceiptWallet and DocumentWallet at $44.93 (50% off the second program) is easily justified. If it saves a few hours of work, then it can be justified. I was originally going to charge $39.95 for ReceiptWallet alone, but decided to start at $29.95 and never got around to raising the price. I’ve always been clear that the products are similar and even have articles here and here explaining the differences. The products do serve different purposes when you can only have 1 library open at a time. However, with the upcoming ReceiptWallet 2.0.0, you can have more than 1 library open at a time, so the reasons I’ve given no longer apply. People have never been forced to buy both products.

I had one user that loves the beta so much that even before I decided to merge the two, but just by adding the multiple libraries, bought a second copy of the software just because he thought the product was that good. A person was willing to pay $60 for ReceiptWallet!

I’m very pleased with my decision to merge the two products and think that it will help me compete and have a better, more feature rich product.

Merging ReceiptWallet and DocumentWallet

After a bit of mental wrangling and taking some email to heart, I decided to merge ReceiptWallet and DocumentWallet. This means that ReceiptWallet can now open DocumentWallet libraries in addition to ReceiptWallet libraries. When you create a library, you choose for it to be a receipt or a document library. This now makes a lot more sense since multiple libraries can be open at once. The libraries still have a few things different (number stuff doesn’t make sense in a pure document library).

What does this mean for DocumentWallet? Well, DocumentWallet serial numbers will now work in the new version of ReceiptWallet. This will be a free update for all users. When this new version comes out, I will be raising the price as I have added a significant amount of functionality with the last few updates. My current price was meant to be an introductory price, but I never got around to raising it. Now is a good time to do so.

One kind of weird thing is that DocumentWallet users can’t automatically update to ReceiptWallet using the auto update mechanism because the applications are named differently and the application identifiers are different. So, users will have to download ReceiptWallet and update through that.

The new ReceiptWallet beta is available in the standard way.

SqueezeCenter and Apple TV Take 2

I decided to take the plunge today and install the Apple TV Take 2 update on my Apple TV and attempt to get the SqueezeBox software (now called SqueezeCenter) running on it. I previously had this running on Apple TV version 1.1, but I want the ability to rent movies, so I had to update my Apple TV and decided to install the new SqueezeCenter at the same time. Unfortunately this has been quite complicated. I almost have things working.

  1. Following the instructions in this thread, I created a PatchStick to install SSH on my updated Apple TV. Prior to updating the Apple TV, I copied all the necessary SSH files off my Apple TV
  2. Pick up the latest SqueezeCenter (7.0) and the XM Radio Plugin
  3. Create a folder on the Desktop called SlimServer
  4. In that folder create 2 files. The first is called StartupParameters.plist and it contains:
    {
      Description     = "SlimServer";
      Provides        = ("SlimServer");
      Requires        = ("Disks");
        Uses		= ("mDNSResponder", "Resolver", "DirectoryServices", "NFS", "Network Time");
        OrderPreference	= "Last";
        Messages =
        {
    	start = "Starting SlimServer";
    	stop = "Stopping SlimServer";
        };
    }
    

    The second is called SlimServer and it contains:

    #!/bin/sh
    . /etc/rc.common
    
    SERVER_RUNNING=`ps -axww | grep "slimp3.pl|slimp3d|slimserver.pl|slimserver" | grep -v grep | cat`
    
    StartService() {
    ConsoleMessage "Starting SlimServer"
    if [ z"$SERVER_RUNNING" = z ] ; then
    	pushd "/Users/frontrow/server"
        sudo -u frontrow "SqueezeCenter.app/Contents/Resources/start-server.sh"
        popd
    fi
    if [ z"$#" != z"0" ] ; then
        ConsoleMessage -S
    fi
    }
    
    StopService() {
    if [ z"$SERVER_RUNNING" != z ] ; then
        kill `echo $SERVER_RUNNING | sed -n 's/^[ ]*([0-9]*)[ ]*.*$/1/p'`
    fi
    }
    
    RunService "$1"
  5. Tar up the folder:
    cd ~/Desktop
    tar -cvf slim.tar SlimServer
    
  6. On a Tiger machine:
    cd /System/Library/Perl
    tar -cvf ~/Desktop/perl.tar 5.8.6
    
  7. Mount the SqueezeCenter dmg file that was downloaded above
  8. From the image, copy Install Files/SqueezeCenter.prefPane/Contents/server to your desktop
  9. Place the XMRadio plugin in ~/Destkop/server/Plugins
  10. Modify ~/Desktop/server/SqueezeCenter.app/Contents/Resources/start-server.sh to add
    HOME=/Users/frontrow; export HOME

    before the ./slimserver.pl lines

  11. Replace the mDNSResponderPosix with the one from the SlimServer 6.5.4 as the one for SqueezeCenter apparently is a PPC only app and the Apple TV doesn’t have Rosetta. The SqueezeCenter developers are going to fix this.
  12. Tar up the folder:
    cd ~/Desktop
    tar -cvf server.tar server
    
  13. sftp -1 frontrow@appletv.local

    (Password is frontrow)

    put slim.tar
    put server.tar
    put perl.tar
    
  14. Login via ssh using
    ssh -1 frontrow@appletv.local

    password is frontrow

  15. Change the root file system to read/write using
    sudo mount -uw /
  16. Uncompress the files
    tar -xvf perl.tar
    tar -xvf server.tar
    tar -xvf perl.tar
  17. Move the Perl modules into a good spot
    sudo mkdir /Library/Perl
    sudo mv 5.8.6 /Library/Perl
    
  18. Move the SlimServer folder using
    sudo mv /Users/frontrow/SlimServer /Library/StartupItems/
  19. Make the SlimServer file executable
    sudo chmod +x /Library/StartupItems/SlimServer/SlimServer
  20. Change the owner

    sudo chown -R root:wheel /Library/StartupItems/SlimServer
  21. Disable auto updating
    sudo bash -c 'echo "127.0.0.1       mesu.apple.com" >> /etc/hosts'
  22. Restart the AppleTV
    sudo reboot
  23. From Safari goto: http://appletv.local:9000/
  24. Change the music directory in the SlimServer prefs to /mnt/Media/Media Files
  25. Use iTunes to change the ID3 tags to version 2.2.0 and use that option to Reverse the Unicode strings to repair some issues with my database

I’m still trying to get the XM Radio plugin to allow 2 simultaneous connections, but other than that, I’m done. This has been a torturous process, but I figure by the next time I have to do this, I’ll be able to do it in minutes 🙂

Simple Google to Mac syncing

I’ve been longing to easily sync my calendar with Google so that my wife and I can keep our calendars in order. I just started using BusySync from BusyMac. Previously I was using another product, but lately it just seemed to take hours to sync and it bogged down my system. I’ve known the BusyMac folks for years and they used to write Palm software. So far, it works extremely well. Make a change on either side and within 5 minutes, the other side gets the update. It is fast and efficient. Nice job!

CoverFlow view in ReceiptWallet is now complete!

My last piece in the CoverFlow view in ReceiptWallet was to add a horizontal scrollbar. This is much easier said than done. So I managed to create my own NSControl and have it act like a scrollbar. It might be a little hard to tell in this screenshot, but look at the bottom of the view and look at the scrollbar. Coo!

ReceiptWalletScreenSnapz002.png

After a little more testing, ReceiptWallet 1.6.0 will be ready to go!