So I've decided to start a separate blog page for technology/computer related things. It's probably just going to be a collection of random links and or small entries, since most tech-related stuff that I'm going to spend time on are going to end up as articles on Apple-X. This also may serve as a place to divulge information about my software-related projects, what I'm doing with them, and maybe even some screenshots of upcoming releases.

Anyway, I've been wanting to post a link to a game simply called "n", which I think is pretty cool. It's reminiscent of Lode Runner, but all you have is the ability to run around and to "wall-jump" and "wall-slide" (or die, if you really want). It's really well made, and it's cross-platform, too. The only annoying thing about it is that it's written in Flash and everyone knows how Flash performance on the Mac is abysmal. Needless to say, it gets frustrating playing the game if you have any other apps trying to do something. It deserves to be downloaded if only because of this part of the story:

N, "the way of the ninja", is a highly advanced system of spiritual, cognitive, and physical training.

It emphasizes pacifism, humility, and the need to traverse a series of 5 rooms before the end of your lifetime; a feat known only as "beating an episode"

Ahahaha, that's great.

(Thanks to Dan Dickinson for pointing me to the game.)

Today's news flash: no, Apple did NOT rip off Konfabulator with Dashboard. Nor did it rip off LiteSwitch with Panther's Cmd-Tab feature, and it didn't even rip off Watson with Sherlock 3. This announcement was brought to you by the Obvious Things That Somehow Have To Be Explained Advisory Board. (And thanks to Arlo Rose's big mouth who made this announcement necessary.)

One other rant: one thing that I hate about being a software developer who creates utilities is that I have to clean up for everybody else's crap. Case in point: the Mozilla Foundation's absolutely IDIOTIC choices in regards to where they place their preference/supporting files and the format of their bookmark files. First, Mozilla and Netscape use the same exact place for pref files (which confuses some people). Second, the browser formerly known as Chimera used to have an XML bookmark file format and have prefs located in the ~/Library/Application Support/Chimera/ folder. Then when the name changed to Camino, they changed the prefs location to ~/Library/Application Support/Camino/ . And then later in the Camino releases, they changed the bookmarks file format to a plist format similar to Safari (but not exactly like Safari, nor similar to the bookmark format of any other Gecko browser). Then there's Firefox which was formerly known as Firebird which was formerly known as Phoenix. The prefs used to be located in ~/Library/Phoenix/ . Then it changed to ~/Library/Firebird , then to ~/Library/Firefox , and then with Firefox 0.9, they changed it to ~/Library/Application Support/Firefox/ .

Not only that, most Gecko browsers house their bookmark files deep in this root prefs folder. Most of the time, it's located inside the root prefs folder, inside the "Profiles" folder, inside the folder called "default", and inside a folder named "########.slt", where #s are random letters or numbers. So, for example, Chimera bookmarks used to be located in ~/Library/Application Support/Chimera/Profiles/default/########.slt/ . Of course, they have to change it all the time: with the latest Camino releases, they're simply housed in the folder ~/Library/Application Support/Camino/ , inside no folders with random letters.

For Firefox (versions before 0.9), it's similar: ~/Library/Firefox/Profiles/default/########.slt/ is the bookmark file's location. Of course, with Firefox 0.9, not only do they change the root prefs location to ~/Library/Application Support/Firefox/ , but they change the full bookmarks file path to ~/Library/Application Support/Firefox/Profiles/default.###/ , where #s are again random numbers or letters.

On top of all this, Firefox before 0.9, Firebird, and Phoenix accepted prefs files from previous locations. That means that some Firefox installations had a root prefs folder of ~/Library/Phoenix/ , some had ~/Library/Firefox/ , and some had ~/Library/Firebird . And then, of course, Firefox 0.9 forces the change to ~/Library/Application Support/Firefox .

This means that when developing SBE, I have to make a very complicated algorithm for detecting which folders exist and which don't for the Gecko browsers in order to find the correct location for the bookmarks file (since this location is automatically recommended in the Save panel when exporting bookmarks). It's VERY aggravating to have the location or the format of bookmark files change after literally each release of a Gecko browser.

To the people at the Mozilla Foundation: I like your browsers, but god damnit please stop changing the places and the format and the names of all your bookmarks. Make it standard across all Gecko browsers, and stick to it. I don't care if most of your releases are technically pre-releases simply because they have 0.x version numbers -- you should take a while to think about where the files should go, and then implement it and be done with it. (All Mac developers, please note: for future reference, you have one main preference file in ~/Library/Preferences/ , and all other pref files should go in ~/Library/Application Support/ .)

And then there's the OmniGroup. I usually love their products, but they made a similar boneheaded decision when deciding how to implement bookmarks in OmniWeb 5. They actually have two separate files, one called Favorites.html and one called Bookmarks.html . (If you immediately knew the difference between the two files, then you must be a genius.) Apparently, Favorites.html is for your favorite bookmarks (or, in IE terminology, your favorite favorites) -- that is, your toolbar bookmarks. Bookmarks.html is for all your other bookmarks. Very self-explanatory, eh?

Of course, they have a third file that defines how the bookmarks appear in their bookmarks manager. The problem is, the Groups.plist file doesn't automatically get updated if the Favorites.html and Bookmarks.html files get replaced, and (with the newer beta versions), the Groups.plist file doesn't even get automatically generated if it was deleted! With the current version of SBE (1.0.7), I was counting on that automatic regeneration fact so that I could simply delete the Groups.plist file after exporting bookmarks to OmniWeb 5. That way, the Groups.plist file would be automatically created by OmniWeb 5 on next launch, and the bookmarks would show up normally in the bookmarks manager. But no; that's way too easy. NOW I have to detect if the Groups.plist file exists or not, and if it doesn't, create my own based on the correct format of the file.

I guess one bookmark file doesn't cut it even though they were basically duplicating the bookmark structure of Safari.

Needless to say, I have to compensate for all these annoying aspects when developing SBE, and believe me, it's not fun. But it's necessary, otherwise I get a bunch of e-mails saying that SBE doesn't work with a particular browser. *sigh* Oh, well.