1 post tagged “technical”
Since my Developer Docs have gone fubar, and I sincerely hope the September '06 ADC update will fix this, I have quite a bit of time before I can start again working for Afloat as the docs get redownloaded from Developer Connection (sigh). So I'm going to blog about Afloat's internal structure.
Afloat is clearly divided in two parts: a preference pane and an injector. The pane is the one the user interacts with; it manages the preferences (which currently include only "is Afloat on or off?"), and turns the injector on or off. The injector, instead, adds ("injects") Afloat's code into any and all apps.
So, to get to the titular question, I'm going to tell you exactly how the injector works. The current injector is an InputManager, a kind of system-wide plug-in that should be used to give the user tools to write in hard-to-write languages; for example, OS X supplies an InputManager that gives Japanese users a way to easily write kanji, hiragana and katakana (different kinds of Japanese characters), or another one that shows a keyboard onscreen (the Keyboard Visor). Usually, InputManagers live in the keyboard language selector menu (which you can enable in the International System Preferences pane).
However, sneaky programs like Afloat can exploit a property of InputManager that makes them very interesting: IMs are loaded in every application that requests advanced text services. With "in", I mean inside the app's address space — which means we can modify the application as it runs, more or less at will. Afloat, when enabled, simply tells the system to load the injector in each application as it would with a regular InputManager (by placing a symlink -- a kind of alias -- in your Library's InputManagers folder; previously, I was simply using SIMBL, that exploits the same mechanism). Once the system loads Afloat inside the application, it injects itself in key places to intercept any interesting operations and adds its menu items to the Window menu.
So what?
The problem in supporting Carbon has two facets. The first and more obvious one is that InputManagers are written using Cocoa, and they're only loaded by Cocoa apps and (it seems) by Carbon apps that use advanced text services (of which there aren't many); this means that Afloat simply never gets to add its code to many popular Carbon apps. Secondarily, the internals of a Carbon app are similar in conceptual structure, but completely different in execution, than the internals of a Cocoa app — events "flow" in different places and are responded to in a fashion that Afloat currently does not know how to hijack (for the techheads out there, this translates to: I use method swizzling on NSApplication and NSWindow); also, windows created by Carbon can't be seen easily by Cocoa code, and vice versa. Since Afloat is designed to work with Cocoa-created windows, and I don't want to duplicate code (that is, I want things to work the same on all kinds of applications without having to recreate Afloat features twice), things are veeery messy on that front. There are techniques that can be used by Afloat to let my Cocoa-using code work on Carbon applications, but unfortunately method swizzling, one of the main tricks I use, is Cocoa-only: it does not deviate the flow of events for Carbon apps, which kills a few things (like for example window moving with command-control down).
Long story short: I'll be working on it, but it'll require a number of changes that I'm not sure I'll be able to make easily. So, for now, I'm simply cleaning things up; but know that I'm working for it. After all, I also want to buy an EyeTV — the siren of digital TV recording has lured me too :p.
