Remote Remote for MythTV for iPhone

I've written a "toy app" for OS X Touch, a version of my Remote Remote GH for MythTV application which acts as a remote control over the wireless network to control a MythTV. It's a toy in the sense I am mainly using it to learn the iPhone SDK, and not to earn money, or even a large user base. I don't expect it will find a large following, I was just learning the ways of the iPhone.


Coding for the iPhone is different. Not so much in the GUI classes or the tools, but in the outlook it requires of the engineer. I was working in a resource starved environment; one in which I needed to take care not to run out of memory, not to use network unless needed, and not to spend a lot of time launching or quitting. An environment, where I had to justify every button on the remote control as space worthy. I leaned heavily on Apple's performance tools, much more than I would on a Mac. And, I refactored constantly. Every time I learned something new, I would change my code to work better and better fit the SDK way.


I also needed to use SQLite extensively, and felt compelled to adapt the QuickLite framework to both Objective-C 2.0 and the iPhone. If Tito Ciuro reads this, please send me an e-mail.


And finally, I'm quite proud of most of the artwork:

It's harder than it looks coming up with simple, thematically consistent, iconic graphics. Thanks to my wife for telling me try again after my original app icon design mashed together a picture of a widescreen TV with a remote drawn in perspective. I went with a simple rendering of navigation buttons, which I liked so much I made the buttons part of the actual GUI.

My Semi-Annual Rant about Compiling MythTV

So, I am testing a little iPhone app to control MythTV, and I decide I should upgrade to the current bleeding edge build. Which is bad enough, as I had Qt 3.3 installed on my Linux box and the bleeding edge is Qt 4 based; requiring figuring out what my PATH, QTDIR, QTMAKE, variables are required, and then ending up with an upgraded database making it hard to go back. And then finding out the the remote control interface is pretty severely broken in a couple places, which I either had to fix or cut back on the features of the app. And then finding out that the mythweb is pretty broken, and that live TV is not improved. Etc.

Bad enough, and then I had to upgrade the Mac frontend to match the new version of the MythTV protocol. As if it it never occurred to the guys at MythTV.org that standards should be flexible enough not to require constant changes. Ever notice that on top of every well formed XML file it says <?xml version="1.0" and that people have gotten along pretty well without changing the definition every 3.5 weeks. After a couple of hours of trying to get the frontend to compile on my MacBook, which has XCode 3.1, and an older version of Qt futzing things up I decided that the build scripts really didn't like llvm, and installed XCode 3.0 on the Mac Mini in the basement. Then it was a couple hours of fixing a few errors in the Mac specific code, and realizing the main configure file had to be made executable.

Then after it finally compiled, it was figuring out why I couldn't turn off pinging the database server (bad mysql.txt permissions), then why the frontend quit right away with the only clue being in the Console: "MythTV requires an updated schema". So the database schema had changed in the last 3 days, causing the frontend to quit without any warning. Classy.

And the playback is absolutely horrible on the Mini for some reason involving TOSLink passthrough or problems with linking in a library—I'm not sure. I really ought to buy another Mini, one which I can run as 100% OS X, and use EyeTV.

Vectored PICT to PDF conversion in your code

You should not be creating any PICT files, but longtime Mac users might have a large number of .pict or .pct files lying around, and some (all?) of the tools Apple provides to open such files and convert them to PDF do a horrid job of it. This applies only to vectored PICTs, as bitmapped PICTS will look bad regardless.


First I refer you to this screen capture of a simple AppleWorks drawing:

You will notice that it looks a little archaic with it's lack of anti-aliasing, but that's what people had in the day.

I copied and pasted this image into TextEdit.app, saved the document as RTFD and then used the "View Contents" item in the Finder contextual menu to get to an actual old fashioned .pict file. This is how hard it is these days to generate a PICT file.


Just to see how not to do this, open the .pict file in OS X Preview.app, zoom in a bit, and you will see that however Preview is rendering PICTs it is doing a pretty poor job of it. I'm guessing it is using QuickTime import to create a bitmapped version.

Tell Preview to save as a PDF and you get this mess:


The basic problem here is that Apple provides an API for rendering a PICT into a Quartz context (and thus into PDF) which preserves the vectored nature of the original and some applications do not use it. If you use this API, your onscreen representation of PICT files will be as good as they can be, and you will be able to export them to comparatively nice PDF files. This does not mean they will look as good as PDFs which had been created from the ground up as such; PICTs lack of support for transparency, Bezier curves, fractional coordinate systems and rotated text make that impossible. But it will look a lot nicer.


QDPictRef LoadPICTFromURL(const CFURLRef& pictFileLocation)
{// warning, I did not actually compile or test this code
QDPictRef result = 0;
CGDataProviderRef dataProvider = CGDataProviderCreateWithURL(pictFileLocation);
result = QDPictCreateWithProvider(dataProvider);
CFRelease(dataProvider);

return result;
}

Look around the header files for the QDPictToCGContext.h header and you will find:

QDPictDrawToCGContext( CGContextRef ctx, CGRect rect, QDPictRef pictRef);


Then you can use the resulting QDPictRef to draw into a Quartz context, and if that CGContextRef was created via a call to CGPDFContextCreate, then you have created as nice a copy of the original PICT as is possible as seen by this screen shot at 200% zoom:

and this PDF result:


Note that rotated text still looks horrible, as the only way to make QuickDraw draw rotated text onscreen was to draw into an offscreen bitmap and then rotate the pixels in the bitmap. It was possible, however, to insert a series of PicComments which inserted rotated text into a PICT. I've checked this out with PICTs created by a separate application, and the Apple PICT to PDF converter honors these comments. I guess AppleWorks just didn't bother to put them in. [Update: Paragraph rewritten to add extra info, and to hide temporary idiocy on my part.]

Also check out the little bump in the arrow heads, probably a glitch that went unnoticed in the non-antialiased original caused by drawing the shaft too long and not quite on center. Otherwise, the new antialiased version looks much nicer. And you can even select and copy the (non-rotated) text right here in the browser.

It's not unusual, but unfortunate that Apple is inconsistent in using its own API. Preview.app obviously does not, nor does the PICT CoverFlow plugin, but TextEdit.app appears to, resulting in the oddity of a PICT in a CoverFlowed RTFd document looking much better than the CoverFlow of the PICT file itself.

Regardless, I recommend that anybody with a large collection of vectored PICTs make PDF copies of them as there may come a version of Mac OS X which will not have any support for PICTs at all. For instance, I doubt you can view PICTs on an iPhone. Warning: see my other posts about how PDFs do not contain the extra data which allows the originating application to recreate the original document. So keep the originals around too.

[Update: I've corresponded with Thorsten Lemke, proprietor of LemkeSoft and creator of the well known Graphics Converter application. He immediately saw the value in incorporating improved Quickdraw picture processing and conversion in his product and version 6.11 and higher (including this morning's beta) will feature it. I envy the nimbleness of independent software vendors. I can't tell you how long my day job company takes getting a minor release out to our customers.]

[Update: here is the source for a simple automator plugin I threw together to make the conversion.

#import "QuickDrawPictureToPDFExporter.h"

QDPictRef LoadPICTFromURL(const CFURLRef pictFileLocation)
{
QDPictRef result = 0;
CGDataProviderRef dataProvider = CGDataProviderCreateWithURL(pictFileLocation);
result = QDPictCreateWithProvider(dataProvider);
CFRelease(dataProvider);
return result;
}

@implementation QuickDrawPictureToPDFExporter

CGContextRef CreatePDFContext(const CGRect mediaRect, CFMutableDataRef theData)
{
CGContextRef result = 0;
if(theData != 0)
{
CGDataConsumerRef theConsumer =CGDataConsumerCreateWithCFData(theData);
if(theConsumer != 0)
{
result = CGPDFContextCreate(theConsumer, &mediaRect, NULL);
CGDataConsumerRelease(theConsumer);
}
}
return result;
}

- (id)runWithInput:(id)input fromAction:(AMAction *)anAction error:(NSDictionary **)errorInfo
{
NSMutableArray* output = [NSMutableArray array];

if (![input isKindOfClass:[NSArray class]])
{
input = [NSArray arrayWithObject:input];
}

NSEnumerator *enumerator = [input objectEnumerator];
NSString* aPath =nil;

while (aPath = [enumerator nextObject])
{
NSURL *inputURL = [NSURL fileURLWithPath:aPath];
QDPictRef aPictRef = LoadPICTFromURL((CFURLRef) inputURL);
BOOL drawn = NO;
CFMutableDataRef theData = 0;
if(aPictRef)
{
CGRect mediaRect = QDPictGetBounds(aPictRef);

theData =CFDataCreateMutable(NULL, 0);
CGContextRef cgContext = CreatePDFContext(mediaRect, theData);
if(cgContext != 0)
{
CGContextBeginPage(cgContext, &mediaRect);
CGContextSaveGState(cgContext);
QDPictDrawToCGContext(cgContext,mediaRect,aPictRef);

CGContextEndPage(cgContext);
CGContextRestoreGState(cgContext);
CGContextFlush(cgContext);
drawn = YES;
CGContextRelease(cgContext);
}
QDPictRelease(aPictRef);
}
else
{
NSString *errorString = NSLocalizedString(@"Picture to PDF could not read the input file as a PICT.",
@"Could not read input file");
*errorInfo = [NSDictionary dictionaryWithObjectsAndKeys: [errorString autorelease],
NSAppleScriptErrorMessage, nil];
}
if(drawn && theData)
{
NSString* outputPath = [[aPath stringByDeletingPathExtension] stringByAppendingPathExtension:@"pdf"];

if (![(NSData*)theData writeToFile:outputPath atomically:YES])
{
NSString *errorString = NSLocalizedString(@"Picture to PDF could not could not create output file.",@"Couldn't write data to file");
*errorInfo = [NSDictionary dictionaryWithObjectsAndKeys: [errorString autorelease], NSAppleScriptErrorMessage, nil];
}
else
{
[output addObject:outputPath];
}
}
else
{
NSString *errorString = NSLocalizedString(@"Picture to PDF could not draw the File.",
@"Could not draw output file");
*errorInfo = [NSDictionary dictionaryWithObjectsAndKeys:
[errorString autorelease], NSAppleScriptErrorMessage, nil];

}
if(theData)
{
CFRelease(theData);
theData = 0;
}
}
return output;
}

@end

]

Keep your Frameworks from Metastasising

Think Class Library, MacApp, PowerPlant. What do these frameworks have in common? They are all on my resume and they are all dead. Qt, Cocoa, AWT(?), Swing, MFC(?), .NET. What do these frameworks have in common? They are not dead, yet. The question mark indicates a framework in the zombie state of not being improved upon, but being used by too many people to be considered dead.

"It just so happens that your friend here is only MOSTLY dead. There's a big difference between mostly dead and all dead. Mostly dead is slightly alive." --Miracle Max in The Princess Bride

And, I am glad that frameworks die. I would rather not live in a world where 23 years later, MacApp was the best we could do. It was a pain to work with and I'm much happier with Cocoa or even Qt. People learned what was wrong with the old frameworks and made better ones. (If only this were true of MFC.) And, baring asteroid collision, people will come up with new frameworks in the future.


And that is the rub. Frameworks get you 2 ways. 1) they usually lock you into writing all your code in a particular language. If the next great application framework uses Python, and all your work is in C++, you're going to be awfully busy. 2) You drink the Kool-Aid, and use Framework classes everywhere. If you are a Qt user, half your methods take QStrings, and when the time comes when you want to switch from Qt to Cocoa, you will be re-factoring for weeks.


The language lockin is tough. I've known for years that C++ is not really a great application language; it may be a decent OS level language, but it is too fragile, too demanding, too static, and too complicated for making reliable desktop applications. But what else are you going to use for cross-platform apps? Maybe .NET will kill C++ as a cross-platform language. I don't know; it'll be a while. Hopefully, an appropriate cross-platform language will rise up to take its place. Which is part of my point, 10 years from now, we will not be using the same language on the same framework to do development. Something better will arise.


Getting back to the point of this entry, you want your code to last longer than any one framework. It's a matter of amortization. The longer your code lasts doing useful work, the higher the payoff for writing it. Over the 16 years I've been programming Macs, I've used 5 frameworks, and 3 of them are dead. I am not predicting the imminent death of Cocoa or Qt, far from it, but die they will, and I should have a backup plan. And here is the other rub, my backup plan 'til now has been to write cross-platform, pure C++ code using a lot of STL and boost, and try to keep the platform specific code from creeping into the general purpose code. But I just said, perhaps prematurely and wistfully, that C++ itself might fall out of favor with framework developers, which both makes cross-platform development more difficult without a Lingua Franca, and negates the hedge against your framework dying.


So I don't have a long term solution, but in the meantime do what has been good advice. Keep your use of frameworks limited to a thin GUI layer on top. Abstract the interfaces between your code and the framework. Abstract, abstract, abstract. To the extent practical, do not propagate framework classes into the meat of your codebase. If people had done this in the past, they could have skipped from MacApp to PowerPlant to Qt with a song in their heart instead of the crushing pain it was for most folks. Do not get locked in without a very good reason.


And know when it is time to scrap your live's work and move to a new language.

...watch the things you gave your life to, broken, And stoop and build 'em up with worn-out tools... --Kipling

Quartz to PDF, versus PS to PDF

I am ankle deep in Postscript code at my day job, so as a refresher I took an afternoon and hand encoded a business card for my wife, who is starting a side business arranging academic tours of China (for the Peking University Department of Philosophy and Religion). Obviously, most people would be better served creating a card in InDesign, or other vectored drawing editor, but this was a learning experience.


Here it is with the contact info scrubbed.



Postscript is not a friendly language, but it was simple enough creating a .ps file in my text editor—BBEdit—and just dragging and dropping the icon from the editor's title bar onto the OS X Preview application. Preview has the convenient feature of auto-magically converting Postscript files to PDF. Of course, compilation errors result in a cryptic failure dialog, but these were enough development tools for an afternoon's project. If I were to do this on a more regular basis, I'd compile a simple app which provided a message callback to the CGPSConverterCreate routine.


Consider how much easier it would be to create this file in Quartz, and how much better the output would look.

• Font handling is hard in Postscript, even if you don't have to embed descriptions of your fonts. Thus my use of standard Postscript fonts Times and Helvetica.
• Kerning is not automatic in Postscript. Yes, you can use kshow to manually set the spacing between pairs of characters. No, I'm not going to do that. Thus, the odd spacing between letters.
• If this file had included characters from non-Roman languages, complications would arise as Postscript only allows 256 characters per font encoding, potentially requiring multiple font definitions per face. None of the free Unicode support in Core Text/Quartz.
• I might have used a little transparency, but there's no such thing in Postscript.
• Postscript is hard to read and maintain. The extra syntax needed to keep the parameter stack organized, distracts the eye away from the actual algorithm being described. Postscript is certainly more compact in the editor, by an order of magnitude, than a series of Quartz API calls but much of that compactness is wasted pushing, popping, dup'ing, and rolling the parameter stack. I mean, just look at it: [Update: changed ATSUI to Core Text]
gsave
basefont [9 0 0 9 0 0] makefont setfont
(Nashua, NH 03061)
dup
stringwidth pop 2 div neg 0 rmoveto
show
grestore

The fact of the matter is that Apple has done a lot of heavy lifting for us either via proprietary extensions to PDF, or taking the extra effort of providing optimized support for font embedding. An afternoon spent trying to keep track of an unruly parameter stack was enough for me to appreciate how much power Quartz gives us, and how easy it is to call upon.

What does it mean when your app launches faster in Debug?

Ummm, maybe you forgot to uncheck "Open using Rosetta" in the release build?


I was enthusiastically awaiting how fast my day job application would launch now that I've eliminated the slowest thing. The debug build launched fast, the release build launched fast under instrumentation, the release build launched really slow from the Finder. What?? Was about to go up to bed, when it occurred to me I had switched on Rosetta for something months ago, and might have just forgotten to turn it off. Yep. Application launches quickly now. Users might even notice when this gets to them in a couple months.


By the way, when you are using Apple's Core Foundation XML Parser, you really really want to use CFTreeGetFirstChild followed by a series of CFTreeGetNextSibling calls to traverse the elements. You really don't want to call CFTreeGetChildAtIndex on anything approaching a large XML document.

iPhone App Ideas: A Target Rich Environment

I was watching a recent episode of Anthony Bourdain's: No Reservations on the Travel Channel this morning, and came up with an idea for an application.

Bourdain described the process in which orders are conveyed through a restaurant: customer tells waiter, waiter writes on order slip, waiter goes to waiter station and inputs order into terminal, order gets directed to the appropriate kitchen personnel. I was struck by how the input terminal involved bringing up a diagram of the appropriate table, and inputting the order for each chair around the circle. This seemed something easily transferable to an iPod Touch style interface.

I'm imagining a situation where the customer tells the waiter, the waiter touches on the table in a map of the restaurant, touches on the seat, is given a series of menu choices corresponding to things on the menu, touches complete, and the order is sent directly to the kitchen. Maybe the customer orders shrimp and the kitchen just ran out of shrimp, the software would show an alert.

In this scenario, the waiter only has to enter the data once, there is less chance of transcription errors, the restaurant does not have to set aside valuable floor space for the waiter station, and status information is more current. Presumably, the people best positioned to make such software is whoever makes the current restaurant terminals, but some enterprising types could get into the business right now while the going is good, by providing an entire Mac/iPod based solution which incorporated the whole system: data entry, accounting, kitchen display screens, etc. If anyone uses this idea, cash is always an appropriate gift.

It would be nice if Apple were to come up with an industrial version of the iPod Touch that was not worth stealing as a media player for specialized situations like this.

The iPhone and the End of Bloatware

You still see tables filling full page ads in computer magazines, a column of checks for the product being advertised, a column of blanks under the competitors. This was the game of the big company, the Microsofts of the world; organizations with large enough staffs to code solutions to any need or perceived need of any customer big or small. Every customer needs 10% of Microsoft Office, but every customer needs a different 10%. Smaller, more nimble companies have made better pure word processors, but they have all been relegated to niche markets, as the vast majority of customers know that somewhere in Office are the exact features they need, plus a bunch of features they might need someday for free. It's just a matter of finding them. And in a world of full keyboards, contextual menus, 24" monitors, gigabytes of RAM, terabytes of storage, multi-cores, and fast CPUs, there's always somewhere to tuck a feature.

Now comes the iPhone/iPod Touch with its 480x320 screen, no keyboard shortcuts, finite memory and demand for near instantaneous launch and quit times. Ponder this small subset of toolbars for Word 2003 on Windows:


and imagine that each icon was twice as big to accomodate the stubby adult forefinger. Imagine making even this small subset of functionality accessible somehow while still showing content. I've a good imagination, but it fails me here.

Anti-bloat features of the iPhone OS:

• Apps must launch quickly (in practice anything less than a second will seem intolerable), and quit as fast or faster
• Apps must be relaunched every time you move back from another app.
• There is a practical limit of 10 or so toolbar type icons per view, and 5 is more reasonable. This leads to a geometric decrease in accessible functionality versus a program on a PC. If you can fit 40 toolbar icons on your computer's monitor, and each opens a dialog with 40 items, and each dialog item invokes a subdialog with 40 features you have 40x40x40-40-40=63,920 accessible features versus 5x5x5-5-5=115 features 3 levels deep on an iPhone (well you could probably fit more than 5 items per view, but you get the idea)
• There are no contextual menus, much less multi-level contextual menu trees
• There are no keyboard shortcuts, eliminating the need for laminated keyboard shortcut hint sheets Scotch taped to the back of the iPhone
• There are gestures, but really, how many unique gestures can you expect a person to master: pinch, shake...?
• There is a finite amount of RAM, and telling the user to "just add more" is not an option
• Lack of both RAM and application interaction are a firewall against the metastasized bloatware which are "Office Suites," which have to at least pretend to work together

No, what we will get are mini-apps. Apps a single competent programmer will bang out and polish in 3 months or less. The functionality which makes up Office could be broken up into scores of such mini-apps: a mini-table creator, a mini-slide presenter,a separate mini-slide editor, a database client, a little drawing app. In fact, even these small apps will probably be too big, and will be streamlined for more specific task oriented, specialized purposes: a blog post word processor, a series of charting modules which each do one type of chart, a specialized Keynote which only has the tools needed to create presentations following a single corporations style—imagine all those exactly the same style presentations you see at Apple events. That would be doable on an app which could only show 5 toolbar icons at once, and which relied upon gestures, animation, templates and transparency to maximize what the user can see and do. And, lots of apps to help with one's location based social networking, whatever that is.

In the iPhone ecosystem, bloatware is non-adaptive. The big have no feature advantage over the small.

The experienced Cocoa programmer does have an advantage, however. I have been reading through the Apple example code, and it is made up of delightful exercises in object oriented minimalism. Actual, full blown apps written in this style will be incredibly light weight for the functionality delivered, with zippy launch times, and responsive interfaces. This seems to be how one masters a framework, and it is especially true of Cocoa, by learning how to do the most with the least code, which is again, the anti-thesis of the bloatware mentality, which seems to only care about churning as much code out as possible.

Re-imagining a Desktop Utility into Cocoa Touch

If anybody's starting up a business based around iPhone development, and need a chief engineer, I'm sure you can find my e-mail address.


Well the momentous day came, and the iPhone SDK is in our hands. I wish I were not so incredibly busy at my day job, or I would take a couple weeks off and learn the ins and outs. But, I've decided I should start small and port a little application I wrote, Remote Remote GH for MythTV, which I'm afraid I have not been properly maintaining, but has the advantage that it would be much more useful on an iPhone than on a laptop, and it only uses Cocoa and various Core Foundation routines. I'm going to go through the exercise here of paring the interface down to size and making it more in touch with the Touch's way of doing things. Then sometime in the next couple months, I'll take the time to actually do it.


Let's look at the original and see how we can get it down to 320x460 and 480x300 (which are about the available sizes once you discount the "status bar" region of the display). Not only do you have a smallish screen, there is inconvenient text entry, and any widget on screen should be at least 44x44 pixels to deal with the stubby fingers of adult humans. On the plus side, there is multi-touch and 3D movement via the accelerometer.

• Disconnect/Connect Button This should probably be done away with entirely, and the app should try to keep a connection up when visible.
• Show Keys Button This brings up a list of keyboard keys which are appropriate for the current state of the MythTV. The idea was for the user to control the MythTV with the same key presses used when sitting in front of the computer running the MythTV frontend. Keyboard input on the iPhone being discouraged, replacement with a series of contextually appropriate button panels is appropriate. (A panel for watching recordings, a panel for navigating, a panel for DVDs, etc.)
• Scrolling Status Console This was a area devoted to telling the user what has happened. This can be condensed into a 2 line status widget at the bottom of each screen.
• Navigation Buttons Live TV, DVD, etc., can be put into a standard navigation bar, to allow the user to jump to a common task, which I will pare to Live TV, Recordings and Video
• Recorded Programs Table This can be moved to its own panel, and condensed, with perhaps a sub-panel which the user can navigate to with more complete information for each recorded program.
• Big Scrub Bar I like the idea of making very long scrub bars to allow for fine control over where in a program the user can jump. This is a good candidate for a control which is always along the long axis regardless of the orientation of the device, and will only be visible in play back mode panels.

As I said, I have very little time on hand, but I was able to make a first step of compiling my network protocol classes, which compiled after a mere 5 code changes—removing #include "Cocoa/Cocoa.h", and replacing call to Carbon's NewPtr(...)/DisposePtr(...) with malloc(...)/free(...).

Then it was just a copy/paste job to make a stripped down version of my original application delegate, which just stuffed replies from the server into a simple UILabel in my main window. Amazingly, this worked on the second try, with a connection forming with the server, followed by periodic requests for status. If anything, the networking code is more solid than in the desktop application.

I'll update this later, as I start to build the GUI, and figure out how best to minimize my power usage (keeping the Wi-Fi unit off for extended periods).

On the Badness of Skins

I refer you to this posting on the product forum for the CoreAVC player application. An application which claims to have extremely efficient H.264 decoding.

Here is the company representative explaining why the Edit menu always comes first , instead of the File menu as Jobs intended it.

CoreUI, our skin layer, is not meant to hardcode things like "File". There are some apps that don't deal with any file and still require text editing. And we can't wild guess where they want the Edit menu. The thing we could do is add a special element in the skin that could place the Edit menu where you want it to be...


Now, I would very much like to see better efficiency in H.264 playback, especially on the 1.6 GHz Core Duo Mac Mini on my wife's desk. That would be a good thing. But here is a cross-platform application whose creators can't be bothered to put together a simple Cocoa shell application for their player, and believe me this would not be a lot of work for a semi-competent Mac guy to throw together. Instead, they've ported their skinning engine—which I'm sure they are quite proud of. The engine is extremely flexible, except in the sense that you can't put together a skin which doesn't make their programmers look clueless.

Let's see. How much time to put together a nice Cocoa application to host your player: X. How much time to port, and debug a "flexible" skinning engine: maybe 4X. So, precious development time which could be spent elsewhere is instead spent on skinning: a misfeature given to the world by WinAmp, and repeated by seemingly every other media player intent on letting skinless iTunes eat their lunch.


You want to know a big reason WinAmp, or MusicMatch (which I worked for) or whatever, couldn't keep up with Apple's iTune team? A big reason was skins, if you are spending 30% of your development time maintaining skins and the skins engine, and you start rejecting new features because they don't fit into the design of the engine, or because you have to add new artwork to 10 separate skins, and you have your best minds trying to figure out an abstract design for docking arbitrary subwindows, and your testing staff spends all day long looking at every permutation of new feature and skin, then it's going to be like you are fighting Apple with your arm tied to your leg, and your leg is bolted to the floor.

And for what? A feature that the vast majority of your user base is at most going to flip through once and forget exists.

BTW, CorePlayer, at the moment, is virtually useless on the Mac, as it lacks AC3 passthrough. You know an actual feature involving playing media. Maybe, if they hadn't spent all that time on their skinning engine, they'd have a product Mac users, like me, would like to buy.

We Need a PDF replacement for PicComment

I direct your attention to the very explicitly obsoleted documentation for the QuickDraw routine PicComment. With a call to PicComment, an application would insert whatever arbitrary data it liked into a PICT. It could then put the PICT on the system clipboard. The user could paste it into their favorite word processor. Days, weeks, femtoseconds later, the user could copy the same image back into the clipboard, and paste it back into the original application.


Without a PicComment, there was little the originating application could do, just treat the image as an uneditable graphic, floating lifelessly inside a document. With a PicComment, the application could retrieve enough information to recreate the original selection from which it came; perfectly without loss of quality. Users built up ad hoc workflows around the knowledge they didn't have to save original image documents, but could copy and paste images back from their word processor if they wished to revise.


With the gradual withering away of PICT support in OS X applications, it's well past time to look at getting round-trip clipboard support back. I hope Apple is thinking about this. The obvious solution is to:

• Extend the keys available to CGPDFContextCreate and other similar PDF creating APIs to include private vendor data. Presumably, you could provide a dictionary under a kCGPDFContextVendorPrivateData key, with a kCGPDFContextVendorID (like "com.genhelp.mygreatapp") and an XML fragment—or other convenient format—needed to recreate the original.
• Encourage application developers to preserve original PDF data whether received via file insertion, pasting or dragging. This would include Apple's own applications such as Preview and Text Edit. Often, applications will thoughtlessly re-render an image into PDF even when the source was PDF to begin with, heedlessly throwing away the original's auxiliary data.
• Add similar functionality to the TIFF flavor favored by image editing software.

Presumably, the host application wouldn't even need to save the whole original, just the contents of the vendor dictionary.

And users can leave the world where a copy/paste is a one way trip.

Microsoft Office Supports PDF on the Clipboard, And Why That is a Big Deal

For months, I've wanted to know whether Microsoft Office 2008 supported copying and pasting PDF data from the OS X clipboard. I couldn't find out, and it's not like I didn't ask. Two days ago, Office 2008 appeared on my chair, and the answer is yes.

Backing up a moment. When you copy content in one application and paste it in another, you are using a system service to transfer the data be it via the old style Carbon Clipboard manager, the Cocoa NSPasteboard class, or the newish Pasteboard framework available to the non-Objective C crowd. The two applications must agree on the format of the data exchanged, so typically only widespread standards are used. For text, as I've outlined before the RTF format is preferred. For bitmap images, a good choice is lossless TIFF. Vectored images, however, were a quandary.

Vectored images are pictures composed of individual drawing operations such as MoveTo, LineTo, AddToPath, FillPath, etc.. Because they are not limited in resolution like a bitmap, they look good on screen and tend to print out with lovely crisp lines. They also tend to be smaller than bitmap files. Every application on Classic Mac OS used a convenient format called PICT which is basically a recording of the QuickDraw operations needed to generate the onscreen display. PICT is a primitive format, something more in tune with the computers of 1984 than 2008. Off the top of my head, it lacks fractional coordinates, paths, Bezier curves, gradient fills, pagination, is limited to QuickDraw fonts, has limited (to rotating text) coordinate matrix manipulations, poor support in Cocoa applications and its ugly. The only two good things I can say about it is it does allow for high quality printing via embedded PostScript, and you can squirrel away your own data in it in case the same PICT gets copied and pasted back into your application.

When OS X arrived, legacy Carbon applications kept on generating their PICT clipboards for both bitmap and vectored material even though the superior PDF format was available and universally used by newer Cocoa applications. QuickDraw became obsolete and onscreen drawing is most often done with Quartz calls, and yet applications still maintain ways to generate PICT clipboards at great expense of maintenance and design. Why?

Because Microsoft Office didn't support PDF, and if you want to sell business applications on the Mac, you have to share data with Office, and that content had better print nicely from within Office. I know from personal experience the aggravation of maintaining the portion of an application which renders content into QuickDraw PICTs; ugly, cludgy QuickDraw PICTs when I could be easily generating PDF clipboards; beautiful lightweight, lithe, PDF files.

To illustrate what I mean I created this pdf in an application which supports creating EPS files but not putting PDF on the clipboard. I opened it in the OS X Preview application (a Cocoa App):

Copied the image into TextEdit (another Cocoa App) from Preview:

TextEdit has a bug where it doesn't re-render embedded PDFs when it zooms.
Copied the image from TextEdit and pasted it back into Preview and zoomed in on a detail:

Now compare with a zoomed detail when using the PICT version from the clipboard of the original application (a Carbon app) (ignore the checkerboard) pasted into Preview:


Presumably, OS X could provide a service where it would extract embedded PostScript from PICTs (if available), and generate a pleasing PDF pasteboard, but it doesn't and I doubt that Apple wants to encourage developers to keep on using PICT.


Getting back to the big news, there was Office 2008 on my chair. Install. Draw a moon:

Copy. Launch Pasteboard Peeker and see this output (... means omitted content):
PasteboardRef: 1116096 ItemCount: 1
Index: 1 item ID: 1112493904
...
"com.adobe.pdf"
"Apple PDF pasteboard type"
'PDF ' P_____ 21056 PDF-1.3 4 0 obj << /Length 5 0 R /Filter /FlateDecode >> stream x

"com.apple.pict"
"Apple PICT pasteboard type"
'PICT' P_____ 409198 >n C 0 H
...


Yay.

And notice how svelte the PDF (21,056 bytes) is compared to the PICT (409,198 bytes). Rendering a gradient fill in QuickDraw is not pretty.

Go back to Word and add a star:

Copy and paste into Pasteboard Peeker and:
PasteboardRef: 1116096 ItemCount: 1
Index: 1 item ID: 1112493904
...
"com.adobe.pdf"
"Apple PDF pasteboard type"
'PDF ' P_____ 24935 PDF-1.3 4 0 obj << /Length 5 0 R /Filter /FlateDecode >> stream x

"com.apple.pict"
"Apple PICT pasteboard type"
'PICT' P_____ 498658 H
...
The PICT version bloats by 97K while the PDF gets a mere 4K. Not that size matters any more with RAM and hard prices the way they are.


Word in Office 2004 had a clipboard which looked like this:
PasteboardRef: 3323920 ItemCount: 1
Index: 1 item ID: 1112493904
...
"com.apple.pict"
"Apple PICT pasteboard type"
'PICT' P_____ 2222 U , , f
...


Open up the pasted PDF in Preview and Zoom:

Look at that beautiful shadow detail! Try to do that in a PICT!

Draw something in Sketch copy paste, yep, there it is, a PDF pasted into Word. Yay again.

But what does this all mean? It means that once Office 2008 sees widespread adoption, the rest of the Mac content creation software industry can rip out every last QuickDraw call in their application. It means we can build 64-bit versions of our applications. It means we had best start putting PDF on our own clipboards. It means Cocoa apps can generate content and with no extra effort have it look great inside Office apps. It means there will be a new, higher minimum quality for interchanged content. It means we can forget everything we ever knew about Classic Mac programming.

The future is finally here.
[Update: One fly in the ointment is that Word has a bug wherein if you paste a PDF graphic into a Word document, and subsequently copy and paste it from Word and into another application (such as Preview), it loses its vectored quality:


But while the graphic is still within Word, it scales, prints, and zooms beautifully, so presumably this is just a bug in the copy code and not a design flaw. The vectored PDF is being maintained internally in some vectored form.]

Space Heaters: Honeywell HZ-519 versus DeLonghi HHP 1500

I have an online account with Consumer Reports, which I've been quite pleased with; it's the first place I look for home appliance recommendations. The manufacturers of my washer, dryer, wet vac, space heaters, and lawn mower can all thank Consumer Reports for my purchase. However, sometimes, by sticking to objective measures, they get things wrong when problems crop up outside those objective measures. In my case, I feel their high recommendation of the Honeywell HZ-519 electric convection space heater was misguided, as compared to another heater they gave a not quite as high rating, the DeLonghi HHP 1500.

Problem 1: Physical Dimensions

You might notice that the HZ-519 is long and thin. Long and thin objects are delicate and require odd shipping boxes. As I, and at least one other Amazon reviewer found out, these things are easily bent in the middle during shipping as it is hard to protect, leaving me with some ugly and noisy bends in the metal. (The Amazon merchant did give me $24 back instead of taking the return). Also, while it has ample cord length, it is mounted at the right side, if your plugin happens to be to the left, the cord suddenly is no longer so long. Compare this with the squarish, solid HHP 1500 which fits in a box of normal dimensions, and whose cord can be used at a fair distance to the left and right.

Problem 2: Temperature Control

Consumer reports gives the HZ-519 high marks for its digital temperature control and timer, which are nice for a single use: set the temperature to maintain by pushing a few buttons, set the time to heat through a few more button presses. The HHP 1500 on the other hand has no way to set a temperature, you turn some knobs and it will try maintain a temperature: what temperature that is it doesn't say. You will have to futz with it over the course of a couple nights until you find a setting which is comfortable for you. But, and here is the big but, once you find a setting you like you are done. When you want to use the DeLonghi you come in flip the top knob on; with the Honeywell, you press the power button, press the "Temp/Timer" button to select temperature, hit a couple arrow keys; if you want automatically turn off the unit, that's more button presses. Every single session. There is no memory of the last setting. Yes, you do get a timer, which is nice, but you try setting the temperature on this thing in a darkened room, when all you want to do is crawl in bed. (There are versions of this heater with a display backlight, and with a remote control which would mitigate this annoyance.)

Problem 3: Being Nice to Your Fuses

The HHP 1500 has two main power settings. One draws about 7Amps when powering its element, the other around 13 Amps, which spikes at over 15 when turning on causing my Kill-a-Watt to make a warning beep. The HZ-519 has one mode which draws around 11 Amps. A typical household circuit is rated at 15Amps. Now imagine having two bedrooms which share an electrical circuit, each with their own space heater. If you installed two HHP 1500s, that's fine, just keep both of them at their 7 Amp setting, and it will just take longer to heat the rooms. If you have two HZ-519s, pop goes the circuit breaker. This assumes the rooms in question are small enough to be heated adequately at the lower setting.

Problem 4: Noise

OK, I shouldn't criticize the HZ-519 because mine has a lot of twisted metal from the shipping incident, but it is quite noisy as it expands and contracts. The HHP 1500 is dead quiet.

Problem 5: Flexibility of Placement

The HZ-519 is designed to be placed along a wall, while the HHP 1500 can be mounted on a wall or rolled into the middle of a room.

Energy Usage

Not a big problem here, and impossible for me to compare. The HZ-519 in one bedroom has been using about 6kWH (about a dollar) a night keeping the room at a comfy temp over the chilly temp I keep the rest of the house, while the HHP 1500 has been draining about the same. I would be happy with nice thick blankets, but my wife wants the children warm when they kick off their covers.

Safety

The HZ-519 does have such additional safety features as automatic switch-off when knocked over. You will have to judge how important this is for you.

In Conclusion

If you are in the market for an electric convection space heater, get the DeLonghi. Buy them in the summer when they are cheap, because they have really gone up in price since the cold weather set in. I paid $80 for a DeLonghi in late November, it's now mid-January and the same heater is $160.
[Updated with additional commentary after first posting]

Memories of RAM past

Pretending 1GB equals 1000 MB.


This is in the category of things that happen to everyone, but which should me remarked upon. Modern RAM capacities are amazing.


My first computer, a Mac Plus, purchased new from the University of North Dakota's bookstore, had .001 GB of RAM installed, which I upgraded first to .0025 GB, and then to its maximum .004 GB, at a cost, as I recall of about $150,000/GB.


I just purchased, at $15/GB (shipping included) a 2GB module for my MacBook, bringing it up to 3GB—and requiring me to dispose of an inconvenient 1GB module. So this means that my computer of today has 3000× the RAM of my 1988 computer, while the price per unit has dropped by 9,999/10,000^ths of what it once was. Imagine if cars were improving at the same rate.


Here's a chart of the final RAM capacities for all my previous computers. I've long meant to make up this chart, so bear with the irrelevance to your life:


Drive capacities have gone through a similar transition, from the .0008 GB floppy in my Plus to the 200 GB drive in my MacBook.


The scary thing is the idea that over the next 20 years from now, RAM might increase in typical capacity by another 3000 times, and what will we be doing with it?

[Update: For whatever reason, my MacBook does not like the Transcend TS256MSQ64V6U module in combination with any other module I have. It works by itself, but put in either of the pre-existing 1GB modules (or even a 256MB module from a Mac Mini, and it would not boot. So, I'm stuck at a mere 2GB.]

Cute Safari Tip: “Apple” to Apple Symbol 

The default Safari bookmark bar has a link to “Apple”, and another “Apple” labeled RSS feed of Mac news. You can save space by replacing the word “Apple” with the apple symbol: . (Anybody reading this on a non-Mac will likely see a question mark or an empty square instead of the symbol which is the apple with a bite out of it logo.) This symbol can be found in the Special Characters window as Unicode F8FF (decimal 63743), or generated by shift-option-K.




Other Mac specific symbols can be found at MacBiblioBlog.

[Updated: Had given the wrong key equivalent]

The Chaotic Nature Of Window's Menus

As part of my day job, I've recently become familiar with the creation, display, and destruction of menus on the Windows platform. In writing this entry, I hope not only to point out the esthetic and technical disaster which is the Win32 menu framework, but offer a caution against getting in the same sort of problems on the Mac.


From the users point of view, menus on Windows are a chaotic mix of styles. While, we Mac users are used to the menus of each application looking the same on any given OS version, Windows users are treated with menus of wildly varying style, depending on the artistic sensibility of the individual programmer. Here are just a few of the menus found on my wife's fairly vanilla Windows Vista install:










Note the random selection of:

• Highlight colors
• Separator graphics
• Highlight region shapes
• Margins
• Margin separators
• Root menu item shapes
• A ball icon where another application would use a check mark
• A "Ctrl-P instead of a "Ctrl+P"
• Minimum spacings between the title and the accelerator
• Sizing of the submenu triangle
• Drawing modes for greying out icons
• Degrees of fade for greyed out text
• Alignments of the accelerator text

Contrast this with a selection of applications on Mac OS X Leopard:






Although even Apple can't protect us from the attack of the ugly cross-platform icons:



Why the disparity? Because when programming to the Win32 API, Microsoft requires all but the simplest menus to be drawn by application code responding to simple window events: WM_DrawItem, WM_MeasureItem. The system doesn't make it obvious where to draw your text, how to highlight selections, what the margins are, etc. The only thing the system will do for you is erase the background. If all you want to do is draw an icon: perhaps the favicon for a website, you have to manually draw the whole menu item, and if you want any hope of having that menu item look like all the other menu items in that menu, then you have to draw all the items in that menu, and if you do that, you will want to draw all the menu items in all the menus. If you code using the MFC framework, you will end up using some 3rd party menu class, written by somebody in the same boat as you, having to emulate and approximate whatever style is used by their favorite Microsoft app on any particular OS. Future changes in appearance will not magically appear with a new OS, but require each application to be reprogrammed, or at least to have a dynamic library updated.


Again, the major reason Windows programmers draw their own menus is to add an icon to a handful of menu items—which is usually the idea of some marketing guy anyway. If Microsoft had only added the ability to provide a graphic, few people would have bothered to draw their own. Life is short. If they had done so, they could have added all sorts of cool wizbangery to Vista, and we Mac users would be reduced to complaining how they stole translucent menus from Apple.

And while it may seem like a minor thing, Microsoft does not provide separate routines to specify the text of a menu and its key equivalent accelerator. Even if you aren't drawing a menu yourself, you have to provide a string like "&Redo\tShift+Ctrl+Z".



Hopefully, .NET programmers have an easier time.


The net effect of all this is that Microsoft cannot:

• Upgrade the operating system and come up with a cool new appearance in which all the 3rd party applications (or even old Microsoft applications) magically share how their menus appear. Click on a menu and it's 1986 all over again.
• Have any kind of unified appearance.
• Replace those awful looking, English-centric, and space hogging accelerators with elegant Apple style meta key glyphs.
• Seamlessly move to *resolution independent GUIs. Apple's having trouble getting 3rd party applications to be resolution independent, but the fact that the OS draws the menus at least eliminates that as a problem.

* Resolution independence is the idea that in our future of ultra-high resolution monitors, a menubar for instance won't be 25 pixels tall, but will be 25 points (25/72nds of an inch) with very high quality text.

But.

While all this Microsoft bashing is fun, this is a morality tale of a sort. Apple in its wisdom has given Cocoa developers much more control over how menus are drawn in Leopard. You can in fact, draw anything you please in a menu now. Don't do it. It was bad enough when you could clutter up your menus with blocky little useless icons, now the user can innocently click on a menu and be confronted with the Gates of Hell. Don't do it. Resist the temptation. Put the NSView down. If you are porting a Windows app, do not let the pointy haired boss force you into porting the ugly menus. Tell him it can't be done. Tell him you would lose Tiger compatibility. Tell him anything, but don't mess with Mac menus.

"Just because we can do a thing does not mean we must do that thing." The Federation President in Star Trek: The Undiscovered Country

[Entry updated to point out more things wrong with the Windows menus and to add detail.]

Off Topic: The Perception of Time as I Age

2 observations:
1) The months pass faster than when I was younger.
2) I feel slower mentally. The ideas come at a markedly lower rate.

Is it possible that these two observations are sides of the same phenomenon? Perhaps my perception of time is based upon how fast I think. If my younger self had 1000 ideas a month, and my present self creates 500 ideas a month, then do I perceive 2 months as taking as long as 1 month used to take? It seems likely.

There Must Be a Cocoa iTunes Coming + Vista 64-bit iTunes?

[Update: Apple released iTunes 8, and whatever it is, it is not pure Cocoa]

[Update: Apple did release a version of iTunes for 64 Bit Vista. I don't know how it matches up with the below speculation. ]

This is entirely speculation on my part. If I had insider information, I would not betray it. This is just my uninformed opinion.


Fact 1: iTunes as we know it is a Carbon application on the Mac. It after all is the direct descendent of SoundJam, a short-lived MP3 player for Classic Mac OS. Open up its package in the Finder and see things like a .rsrc file.

Fact 2: iTunes makes heavy use of QuickTime and the Mac Toolbox emulation layer which QuickTime for Windows contains. This is what allowed the same codebase to be deployed on both OS X and Windows relatively quickly. (OK, this may not be a fact, not having access to the iTunes code, but it seems darn likely.)

Fact 3: There is no 64-bit C API to QuickTime on the Mac. There is only a 64-bit Cocoa interface.

Fact 4: Pretty much all of that Mac Toolbox being emulated on Windows is no longer available under 64-bit compiles on the Mac.

Fact 5: All new Macs are 64-bit. Apple is in a good position to start promoting themselves as The 64-bit Company, as their path to 64 purity seems easier than Microsoft's, but it will take getting all their apps there first, and convincing their major developers to follow. I assume it was easy getting their Cocoa applications there, but any residual Carbon applications would be a nightmare.

Extrapolation 1: Even Apple will not be able to make iTunes a 64-bit application without a major rewrite. After you remove QuickTime, all the old Classic Mac APIs which are not in the 64-bit frameworks, etc., there is little left. Maybe much of the task specific onscreen drawing on the Mac is now done with Quartz calls, and the networking calls are probably being done with CFNetwork calls on the Mac, and maybe they are using WebKit to do the store, and that can all be salvaged, and hopefully the code is factored such that system calls are not sprinkled all over the place, but they are going to have to bite the bullet and just write a from scratch Cocoa application and call it iTunes 8.

Extrapolation 2: If Apple is not going to extend the life of Classic Mac APIs and QuickTime C APIs for 64-bit Mac applications, what are the odds of them doing so for the emulation layer on 64-bit Vista. Pretty low. There is no obvious quick way to get iTunes as we know it on Windows to run as a 64-bit process. I guess they could if they really wanted to, but it seems a pretty hacky solution and would basically obligate them to maintain an entire OS's SDK just to run iTunes and QuickTime.

Extrapolation 3: I assume Apple cares about the future of QuickTime and iTunes on 64-bit Windows. This is not a big market now, but will only get bigger, and Windows user are not going to accept running multimedia software in 32-bit emulation mode in perpetuity. They can do two things. They can create a new framework which can play and edit QuickTime content, perhaps a set of .NET classes, and write a separate version of iTunes which makes use of these classes. Or, they can bring Cocoa to 64-bit Windows, and run the same source based iTunes as the Mac. I suspect Apple doesn't want to do either, but iPod sales are important to them. They wouldn't want those early adopter 64-bit users running to Zune.


A little Googling on "64-bit iTunes" came up with this revealing alert text in the current Windows iTunes "This iPod cannot be used because the required software is not installed. Run the itens installer and remove itunes, then install the 64-bit version of iTunes." That makes me wonder if all this is going to fall out sooner rather than later. Or maybe it's an aberration.

Anyway, that's my uninformed opinion, and we'll see if it has any relationship to reality.

[Update: See this article about how Adobe is not releasing a 64-bit version of Photoshop until they can do the major re-writing required to remove their Carbon code.]

The Future or Lack of It for Carbon

If you are tasked with maintaining a large, old—is there any other kind—Carbon application, here's an illuminating experiment. In XCode 3.0, under Build architecture, turn on 64 bit compilation for Intel. Now try to compile.


In my case, I see errors and lots of them:

error: '::FlushVol' has not been declared
error: 'HideCursor' was not declared in this scope
error: 'ShowCursor' was not declared in this scope
error: 'LMGetFractEnable' was not declared in this scope
error: 'GetOutlinePreferred' was not declared in this scope
error: 'GetPreserveGlyph' was not declared in this scope
error: 'GetWindowEventTarget' was not declared in this scope
error: 'SetFractEnable' was not declared in this scope
error: 'SetOutlinePreferred' was not declared in this scope
error: 'MoveWindow' was not declared in this scope
error: 'SetOutlinePreferred' was not declared in this scope
error: 'OpenCPicture' was not declared in this scope
error: 'SetControlPopupMenuHandle' was not declared in this scope
error: '::SetControlMaximum' has not been declared
error: '::DrawThemeMenuItem' has not been declared
error: 'GetIntlResource' was not declared in this scope
error: 'CompareString' was not declared in this scope
error: '::SetMenuWidth' has not been declared
error: 'IsWindowVisible' was not declared in this scope
error: '::GetPicture' has not been declared
error: '::DrawPicture' has not been declared
error: '::EraseRect' has not been declared
error: '::FindDialogItem' has not been declared
.... lots more errors ...

So, we have a litany straight out of Inside Macintosh Vol. 1-3: all of QuickDraw, much of the File Manager, the Control Manager, the Dialog Manager, the Window Manager, the Menu Manager, the Font Manager all gone, but surprisingly not the Resource Manager. Anything that uses Pascal strings or FSSpecs. Few of the API's which came from the Classic Mac OS survive a 64 bit compile.


I don't know in the short term, what the carrot is for getting independent developers to make 64-bit compiles. Unless you are doing something that really needs 6 GB of real RAM—very few applications—there seems to be little performance advantage for 64-bit. And, it's hard taking a Carbon application, ripping out the APIs behind its entire GUI, and putting it back together again. Lots of redesign and drudgery for little immediate payoff. In the long term, Apple will presumably stop supporting 32-bit applications, but that is in the very long term.


Plus, there are little bits of functionality in the Carbon APIs which are hard to replicate in the more modern APIs. One example is embedding one's private metadata in the PICT clipboard flavor. I'd very much like to know how to do that with the PDF API. Another example is the XOR drawing mode for doing tracking, stupid and old fashioned, yes, hard to replace, yes.


There's an Ars Technica article which goes into this in more detail.

HDHomerun Gets More And More Useful

[Update: check out Signal GH, an iPhone utility for monitoring the signal quality of an HDHomerun].

One of the best bits of tech I've bought over the last year is the HDHomerun networked digital HDTV tuner. I was reminded of this a couple of weeks ago, when I was going through the process of setting up a Mac Mini as a dual boot Leopard/Vista desktop.


The OEM copy of Vista Home Premium I picked up cheap at MicroCenter comes with Windows Media Center, which Silicon Dust supports for use with the HDHomeRun, so for no added cost, I get live TV watching with a guide, and recording. This is functionality I would not easily get otherwise, as there is no MythTV client for Vista, and I am not going to get an additional tuner for the Mini. It just happened I get all this for free because I happen to own an HDHomerun.


Not that I'm very impressed with Windows Media Center, at least not on the Mini. HD playback is a bit stuttery, unlike VLC on the same OS and hardware; and navigation is confusing. Also, there doesn't appear to be an integrated solution for using my Wiimote; Remote Buddy on the Mac spoils you for effortless couch potato style navigation. MCE does allow the same application to control both live TV viewing and DVD playback, whereas I have to switch off between EyeTV and Front Row on the Mac, but that is comparatively easy with Remote Buddy.


Another HDHomerun nicety is that EyeTV can Picture In Picture both HDHomerun tuners (again on the same hardware Vista MCE can barely decode 1 stream), allowing me to watch 2 HD football games simultaneously, which will be my preferred mode going forward. I like to watch football live, so EyeTV wins over MythTV, whose live TV support is always a bit cumbersome, and the PinP feature seals the deal.


Anyway, my main point is to emphasize the value one gets from a networked device. Because the HDHomerun is accessible from any computer in my house, any computer capable of decrypting an HD stream can use it. In my case, I have 3 computers (my MacBook, a Mac Mini, and my Linux server) and 3 operating systems (Leopard, Vista, Linux), each with their own strengths, sharing this resource.