Solipsism Gradient

So, I’m just back from getting my WWDC badge. I’ve seen the famous banner and all icons on it are known – the only one I had doubts on (above the SpotLight icon) is supposedly from a Mac OS X Server utility. Even the 64-Bit icon was previously used when the G5 came out. Ah right, we now know what the Leopard “Big X” looks like – black with a white border. Drat, I need to change the XRay II icon to reflect that…

The relative sizes and positions give no hints. There are a few hardware icons. One iPod Nano. 3 iMacs, 2 laptops and one desktop – the latter one from the side, so the front may be different. Or the banner might just be there as a misdirection and may be changed on Thursday… the Xcode icon is very large – so large that one can read the small print on it, but then it’s a developer’s conference. On the other hand, people “in the know” did tell me to make sure not to miss the developer tools sessions.

Certainly a major release of Xcode is in the works. 2.5 or 3.0, it doesn’t matter, but my personal hunch is that the superannuated Interface Builder application will be phased out and integrated into Xcode. Let’s hope that connections like outlets and bindings will be easier to visualize and debug, and that the IBPalette interface is finally officialized so that we can write non-trivial palettes.

I’ll be under NDA for details – things announced at the keynote excepted – so these will be my final pre-WWDC speculations. On the hardware front, 64-Bits is of course guaranteed, with one of the new “Core 2 Duo” chips. A Mac Pro will certainly be out, although the name may not be exact, and the casing will probably be a minor variation on the current one. There’s a good Ars Technica writeup about the new Intel CPUs, and expectations are that the whole new range will fit nicely into the spectrum from MacBook Pros to the Mac Pros – possibly with a dual-core, dual-CPU at the top, although it might also be that Intel has been reserving their quad-core chip for Apple to announce. Intel Xserves might also appear.

I don’t expect a new iPod to be announced in a big way, except as a footnote to the usual summing-up of past sales; at a developer’s conference, it’ll be big news only if it had an official API for developers to extend its functionality, which might actually be a neat way for Apple start a new iPod generation in a privileged position; stranger things have happened.

I’m reasonably certain that we’ll each get a Leopard preview DVD. I’ve seen rumors of changes to applications, which I consider less interesting as they’re not really a part of the OS itself, at least from my developer’s standpoint. I use relatively few of the iApps every day – Safari and iChat are the ones I leave open, and my wishlist for those is small.

Real Leopard features I expect to see:

– RBSplitView adopted! Well, not likely, but it’d be nice… I’ve told Apple I’d gladly give them the code, anyway.

– A new UI theme, or at least a migration of the default windows theme to the new “cool gradient/smooth metal” look.

– Some new Cocoa widgets, especially the more successful ones from the Tiger iApps. I hope to see them do Brent Simmon’s “big time tabs control”; I need it badly for XRay II.

– A new Finder. I’ve mostly gotten used to the old one, but still…

– Resolution independence. We need to get away from the pre-rendered bitmap widgets. People are already starting to use object-based PDF files for that, but they’re a pain to make and don’t look good at all resolutions. My ideal solution here would be a new NSImageRep and corresponding file format that would do for images what the TrueType format did for fonts: resolution-independence with special hinting for small sizes.

– More extensions to Objective-C. Garbage collection should be a given. Unloading NSBundles is supposed to be in the works. Frameworks included inside applications can’t be easily updated and versioning is pretty much useless for practical purposes.

– Hopefully we’ll see expanded metadata capabilities and a more useable SpotLight. I hardly use it in Tiger because it’s so slow and limited. The ability to have additional named forks should go hand-in-hand with full NTFS support. Other file systems would also be nice (ZFS, anyone?).

– Virtualization. I’ve written about this several times. My personal opinion is that Apple should write a fully trusted hypervisor into the EFI (using the TPM) and run everything inside virtual machines, including Mac OS X for Intel itself. Booting some version of Windows into a second VM would be easy, then, and there wouldn’t be a full version of Mac OS X for Intel for people to run on standard PCs either. I don’t think dual-booting is a good solution, I believe Apple was just testing the waters with BootCamp. No idea what would happen to Parallels in this scenario; they might be bought out by Apple, or by Microsoft, I suppose. Here are more thoughts on virtualization from Daniel Jalkut and Paul Kafasis.

– 64-bit “cleanness”. Meaning, Carbon and Cocoa and everything else running in 64-bit apps. And very probably, also, on the G5s. However, I’m not sure (and no time to research at this moment) how mixing 32 and 64 bits works on the Intel CPUs. I remember reading somewhere that it’s not as easy as it is on the G5, where you can have 32-bit processes co-existing with 64-bit processes.

Unlikely or even impossible:

– A new kernel.

– iPhone, iPDA, iGame, iTablet. iAnything in fact. There are rumors about VoIP support and there might be some sort of hardware for that, but I can’t see Apple doing a me-too cellphone.

– Some goodie under the seat (like when the iSight was introduced, which I missed out on, argh!).

In the meantime, I’d better get back to my coding… more after the keynote!

Things are going well. I now have some confidence that I’ll be able to show a working alpha of XRay II at WWDC. Details later…

Also, I found this EgoSurf thingy on Mike Zornek’s blog. It’s some sort of link rank, so here it is without further warranties:

I’ve finally solved a vexing problem that has been affecting version checks for my software.

Basically, checking for updates inside of XRay and Zingg! asks my webserver for a .plist file which contains the latest versions of everything, along with a brief message. On the server, however, this is actually a PHP script which also stores the user’s system version – which is appended to the URL – into a small database.

Since I changed over to DreamHost, my server has been set to gzip everything it sends if the receiver is capable of decoding gzipped files. However, for some time – not sure when that changed – this has messed up my version checking, and users would get a “website was unreachable” error. I did get some reports about this every couple of months, but always had attributed it to a network glitch somewhere… until I tried it myself and got consistent errors.

I read the .plist file directly using +[NSDictionary dictionaryWithContentsOfURL:]. Some combination of Cocoa, php and server parameters now causes the result to be gzipped, and NSDictionary doesn’t understand that format. Anyway, once I figured it out, I had to find a way to turn gzipping off for this particular file only, as I can’t change all the old software versions that are out there.

So, for now, adding this statement at the front of the php part of the file solved it:

header('Content-Encoding: UTF-8');

Strangely enough, rfc2616 says:

The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens:

gzip…

compress…

deflate…

identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept- Encoding header, and SHOULD NOT be used in the Content-Encoding header.

…and that’s it. No “UTF-8” is mentioned, so why is it working now? I tried “identity” (before seeing the SHOULD NOT comment) and it had no effect at all. I suppose I should try to debug this on my local server adn see where the problem lies, but time is short…

I don’t plan to use this method in XRay II, so it’s not urgent. I’ll probably use Andy Matuschak‘s Sparkle, of which I’ve had good references.

Posted by gracion:
AppleScript – good! Yes, I’ve used SuiteModeler for a couple of projects and it’s invaluable.

How about a “Save changes as AppleScript” command? After setting a creator, permissions, etc in one file, this would create an AppleScript that is ready to use on a batch. You’d have to track the changes of course (maybe as part of your undo module), but this might be very useful.

For example, Stone Software’s terrific Create page layout software has this kind of command – You can actualy save a document as an AppleScript. I think that’s more useful (and easier to implement) than recordability.

The other thing that’s important is to have a good object model – it takes some study to grok this area of script support, but think of the extra endorphin kick from learning all that

Yes, AppleScript can be very frustrating to write in. It’s really not one language, it’s N languages, where N = the number of AppleScriptable apps you use. I pretty much have to find sample code to get terms and syntax (especially coersions) right.

Leonardo Burci wrote:

you might also want to take a look at:

http://homepage.mac.com/donbriggs/

Thanks Leonardo, the #macsb folks also directed me to that page, and I’ll be checking it out.

Now that XRay II’s file browser is working reasonably – some edge cases excepted – it’s time to refactor the GUI, and to worry about how this will affect the internal architecture.

I had an excellent discussion yesterday on #macsb about the possibility of adding AppleScript support. My interest about this was renewed by Daniel Jalkut’s discussion of adding minimal scriptability to a Cocoa application. Seems that the AppKit already has such support built-in, and you get it for free by turning on one option in the app’s .plist file. Daniel gave me some very good suggestions on #macsb, and I’m seriously investigating the possibilities at this time…

My previous experiences with AppleScript were not very good. The syntax itself is confusingly English-like: it sorta kinda looks like English – and verbs and whatever are chosen to make it even more so – but there’s no flexibility at all. The few times I had to write (or change) a portion of AppleScript took me hours with the manual opened in one window and the editor in another.

When I wrote the Aurélio Eletrônico – a Portuguese dictionary app – waay back in the Mac OS 8 days, at one point someone convinced me to build in AppleScript support. At the time, this was done by CodeWarrior’s PowerPlant classes and I seem to remember that most of it actually worked. However, I never got around to documenting what exactly had been implemented, and to the best of my knowledge, no user ever needed it for anything.

Adding scripting to XRay II would have advantages and disadvantages. My original plan was to pitch it as an exploratory sort of utility… a way to look closer into the innards of files and bundles, and to find out their structure. And, eventually, to edit some small part here and there. However, it seems that there’s serious demand to do batch processing; people want to add filetypes to all .mov files inside a certain folder, etc. Or, once a certain tweak to a file has been done, this tweak must be repeated periodically – from inside an Xcode build phase, for instance.

Allowing such functionality would of course expand XRay II’s uses enormously, but it also would make the responsibility much greater. It’s easy to completely bork up the system by running a buggy script, much more so if the scripted app can run with privileges. The internal structure would also be changed. I’d have to be more canonical in implementing the Model-View-Controller pattern and be careful to separate the user interface from actions on data; something I’ve been known to sacrifice, sometimes, for efficiency and code compactness.

At any rate, this offers an opportunity to learn something new, and to make XRay II even more powerful. Stay tuned for more news about this.

OK, time to confess all. (cue ominous background music…)

You see, I have this congenital high activity monoamine oxidase A syndrome. In other words, I’m a neophile (also called “neophiliac”). One of the subtypes, at least… apparently I get an endorphine kick when I learn something new. Since you’re reading this, you may be one too! Very useful for a programmer, I must say…

Found at Media Life via Gizmodo.

Maybe of the month. This is from Tricks of the Trade, by Matthew Baldwin (aka the Defective Yeti), my emphasis added:

Every year there seems to be a technical whatsit that management recognizes as the sexy-cool new thing but doesn’t really understand. This year, for instance, a programmer can always tack the phrase “and I’m thinking of incorporating some XML functionality” onto a project summary to explain why he’l need an extra week, account for a missed deadline, or impress a superior. In this respect, the gap between software engineers and birthday clowns is almost negligible.

Worth a read.