One thing that seems to annoy people about NSImage is the fact that although
you can get TIFF data by using the -TIFFRepresentation method,
there is no obvious way to turn one directly into a PDF. This seems like an
odd omission when you consider that Quartz directly supports PDF…
anyway, I thought I’d rectify the situation by posting some code that
implements a -PDFRepresentation< method.
If you want to take a look, it’s in my mercurial repository.
Older programs (and older programmers) sometimes use octal (base-8) to represent characters, so I added some additional numbering on the chart to help you out if you’re given (or want) an octal representation of an ASCII character. I’ve put the revised version of my ASCII chart where the original was.
Another useful thing to have if you’re a C programmer is an ASCII chart; sadly there aren’t very many readily-available charts that contain all the information you might want, so, in the immortal words of Blue Peter, “here’s one I made earlier”.
Far too many people don’t know how the operator precedence works for C, Objective C or C++, which means they write code that would scare even a Lisp programmer (i.e., far, far too many parentheses [that’s brackets, for those that don’t know]). This isn’t helped by the fact that it’s hard to find a precedence table; even the specification doesn’t contain one (the precedence information is encoded in the grammar rules in the spec.).
Anyway, here’s a precedence table that I’ve written based on the C99 spec.
Well, it’s nearly the end of August and I’m still bashing away at the keys trying to get my program to a state where I can sell it. There have been some interesting challenges so far and I can see a few more lurking on the horizon; still, it shouldn’t be too long now.
I’m just hoping that people will want to buy it when I’ve finished. On the plus side, I’ve had a few more ideas whilst I’ve been working on this project, so I’ve certainly got some interesting work ahead of me :–)
What a cool game :–) Unfortunately, the install program doesn’t seem to be very reliable… I don’t think it’s setting the file date stamps correctly, which caused me problems when I tried to upgrade to version 1.31 using the patch MacSoft just released.
If only MacSoft had followed Apple’s guidelines and made it a drag-n-drop installation. Still, never mind. If you’re having the same problem with the 1.31 patch that I was, then go to the terminal and enter
cd /Applications/Neverwinter\ Nights
touch -d "May 8 2003" dialog.tlk
touch -d "Feb 7 2003" patch.key
touch -d "Feb 7 2003" data/patch.bif
then run the update installer. In my case, it thought it had finished after updating just patch.bif; if this happens to you, just run it again (or click “Continue”). If all goes well, it should have updated the files listed here. The dates on the dialog.tlk and patch.key files were still wrong when I’d finished, but it seems to have updated them.
Just in case you want to check, here are the MD5 sums of the files I have after installing the patch:
9b40bc477714600a831a2f0db2767715 dialog.tlk
444ea264c54ea15e7b031d59e924b710 patch.key
f24fb1f20ec999c9d97d90d8ceac2f82 data/patch.bif
6df328b791e9fbc07da90554a29fcc76 nwm/Chapter1.nwm
4c5f6d019937aeb17edc376687662a87 nwm/Chapter1E.nwm
061baea94ecbbc1301a3e742e2fba6ca nwm/Chapter2.nwm
b43ad6564420c63925fe3d07d0e37060 nwm/Chapter2E.nwm
a4072a057de87d5f9dc6d708611e5d4f nwm/Chapter3.nwm
3b715869b19d3063713f85f7c113233b nwm/Chapter4.nwm
1ec243edaf6201f622bc3cae61d64a76 nwm/Prelude.nwm
0784fde7c6413a441436c435c8e6b394 Dedicated Server.app/Contents/MacOS/Dedicated Server
6f57f2764b8833f30c5a0992b4a5f559 Neverwinter Nights.app/Contents/MacOS/Neverwinter Nights
You can generate a similar list by entering
md5 -r dialog.tlk patch.key data/patch.bif nwm/Chapter[1-4]* nwm/Prelude.nwm Dedicated\ Server.app/Contents/MacOS/Dedicated\ Server Neverwinter\ Nights.app/Contents/MacOS/Neverwinter\ Nights
at a Terminal prompt.
My project, which shall for the moment remain nameless and therefore shrouded in a certain degree of mystery, seems to be going OK. Cocoa is making it refreshingly easy to work on the GUI itself, and the back-end code pretty much writes itself. Pretty neat, really. It’s quite cool already, and although it doesn’t do much yet it is beginning to look like an application rather than just a toy.
Of course, I still have some way to go before shipping the first version (or even a Beta for that matter), but progress so far has been reasonable. Another thing that I’m quite pleased about is that I haven’t been slacking too much, which was always a worry starting to work for myself.
It’s surprising how difficult it is to design a good user interface. I mean a really great user interface, not like the rubbish most programmers come up with when asked to design a UI. They just don’t think about how things are going to be used. (Apple can, of course, pat themselves firmly on the back for being good at this, but most other companies should take a look and see why their interfaces are so bad).
As for me, I’ve spent a great deal of time recently thinking about UI issues; my current dilemma is something of a horizontal vs. vertical problem… I have two user interface elements, one of which would look best horizontal, and the other of which would look best vertical (because it is a list of items, so a vertical layout will provide more space for the items’ information). Unfortunately for me, they both have to have the same orientation (because of the way they interact). At the moment I’m leaning towards vertical, but we’ll see.
I’ve just packaged-up anacron and put it on my site so that people don’t have to figure-out how to install it themselves.
Anacron is no longer required on Mac OS X; launchd’s StartCalendarInterval
functionality is equivalent and doesn’t require any third-party software.
This has been frustrating me all day. I wanted to get the icons for a set of disks attached to my Mac, so I could display them in a dialog box. How hard could it be, I thought?
Finding the name of the icon file was OK; you just use the IORegistry functions, from which you can obtain a CFDictionary containing the name of the file and the bundle’s identifier. And there’s the sticking point. You can’t (normally) get from an identifier to a bundle, unless the bundle is already loaded in your application…
After a lot of hunting around, I started searching through the IOKit headers and finally found KextManagerCreateURLForBundleIdentifier(), which lets you obtain an NSURL (or CFURL) directly from a bundle identifier. Just to see whether I had blindly wandered straight past the right bit of Apple’s documentation, I queried Google for this function, and I got (wait for it) Mac OS X 10.2 release notes (useless), and one (yes, one) reference in Apple’s documentation, buried in the “Displaying Localized Information About Drivers” section of Apple’s IOKit documentation.
The only thing wrong with Cocoa is the documentation.