Hello Chronic Logic developers! I bought Bridge Construction Set in the recent MacZOT thingy. It's good clean fun, but I have a few criticisms, the first of which is relevant to JCH's post. I'm probably going to come off as arrogant for posting this much, even though I'm trying to be helpful! But anyway...
I notice that BCS stores the user's settings and bridge files inside its .app bundle. This is a rather bad idea. In my opinion the simplest adequate solution would be to change BCS to store these things in the user's Library folder under, for example, ~/Library/Application Support/Bridge Construction Set.
If you wanted to be a bit more flexible you could perhaps allow the user to customise the path BCS writes files to. That would naturally require you to store the path in a known location, such as a settings file like ~/Library/Preferences/com.chroniclogic.bcs.txt (Apple recommends using reverse domain names like com.chroniclogic to avoid name-space clashes with any other programs called BCS).
You could even use proper open and save dialogues--but I don't want to bore people with the obvious. The point of this post is that applications should not put settings files in the application bundle because it causes several problems, including the following:
Usability - From an everyday user's perspective, a bundle is just a file; one that they double-click to start a program. They shouldn't need to know that there's a special way to open it that lets them mess with the executable files and resources inside, as with
http://www.pontifex2.com/smf/index.php/topic,1106.0.htmlMultiple users - By storing the user's personal files inside Bridge Construction Set.app (or any folder like the main /Applications folder that isn't personal) you compel each user to keep their own copy of it their personal ~/Applications folder. This makes it easy to accidentally skip over a copy of it when updating to the latest version.
Privacy & security - The alternative to keeping multiple copies of BCS is to keep one copy and set its permissions so that everybody can read and write the relevant files. This causes much bigger problems than it solves: Now anyone can mess up the program for everyone else, even accidentally! (That's what personal logins are supposed to avoid.) I don't recommend opening up the permissions of BCS even if you know which files to do it to.
Installing updates - This is supposed to be easy: The user drags the new version of BCS to where the old one is, then they agree that they want to replace the old one -- except that they've just erased all their progress in BCS! BCS is the only program I've used that has quite such a dramatic design flaw. Because of it, you have to instruct your users in tediously and carefully replacing all copies of the program, as with Gish:
http://www.pontifex2.com/smf/index.php/topic,989.0.html (I hope they keep backups!)
Signed code - Mac OS X uses cryptographic signatures to ensure that each program is the program it claims to be when it tries to access something security-sensitive such as the Internet or the Keychain. BCS accesses neither, so this is not currently a problem. But it's worth considering that BCS's self-modifying antics could make it appear to be a different program each time it runs, thus defeating the point of signed code.
I do not know the specifics of signed code but I thought this potential issue was worth mentioning just in case. Anyway, please fix the underlying issue and signed code probably won't be a problem. The underlying issue, as you know, is the separation of executable and personal data. I urge the Chronic Logic developers to improve their software as such. Thank you!
Author