C3D Buddy 2.0 in action — built in an evening using node-webkit
C3D Buddy 2.0 in action — built in an evening using node-webkit

I don’t do very much desktop software development these days, and I’ve become increasingly frustrated with Realbasic (now Xojo), so the prospect of forking out $500 for an upgrade that may or may not be usable did not fill me with glee. Furthermore, as the years roll on, there’s more and more functionality tied to the web that desktop-centric development tools struggle to work with.

I was dimly interested in a thread on Hacker News this morning concerning a workflow for developing desktop applications with node. Turns out that the workflow was mostly to do with things like angular and jade, which I’m not especially keen on, and not so much with the actual desktop stuff — the heavy lifting for which is all done by node-webkit. So I started looking into node-webkit.

I like a tool which has you up-and-running in about three paragraphs.

It goes something like this:

Download an appropriate node-webkit binary. (Disappointingly, the Mac version is restricted to 32-bit.)

  • Write an index.html file. (The sample “hello world” app calls node inline.)
  • Write a package.json file. (The documentation suggests it’s like a “manifest” file, but really it’s more like a configuration file.)
  • Zip this stuff into a file into an archive whose name ends in .nw.
  • Double-click the archive.
  • Voila, your app works.

After working on this for about fifteen minutes, I knocked up a bash script (which I turned into a .command file, allowing me to double-click it in Finder) which does the archiving and then launches the file in one step. (It does leave dead terminal windows lying around, and it doesn’t quit the app if it’s still running. I think I may build an app for building apps if I do much more of this.)

And to build a distributable application you can simply put the archive in the application bundle (on the Mac) renaming it “app.nw” or name the file package.nw and put it in the same directory as the application (for those benighted platforms that don’t have bundles). One minor annoyance is that it’s not clear exactly what needs to be changed in the Info.plist file to fully customize your application.

So what is node-webkit? It’s essentially a version of Chromium that puts node.js alongside the DOM in your web pages, along with a few custom HTML and DOM extensions that let you do things like handle platform-native file requesters).

I should note that it’s a potential security nightmare as it stands. There’s no sandboxing (that’s kind of the point), so deploying an app that loads your banking website and then watches you press keys is totally doable. That said, it’s a desktop app so it can also delete all your files or encrypt them and hold them hostage.

Anyway, I had a lot of fun this evening rewriting a utility application I originally wrote in Realbasic a few years ago. It probably took me about twice as long to write it as it took me to do it in Realbasic. Part of that is I know (or knew) Realbasic very well, and I don’t know node very well. Another part of it is that Realbasic is almost always synchronous while node is almost always asynchronous. Writing code that spelunks a directory tree asynchronously is a lot more complex both conceptually and in practice than doing so in linear fashion, but the payoff is quite impressive — despite running an “interpreted” language, a task that took significant time in Realbasic (loading and displaying hundreds of thumbnails) happens in the blink of an eye.

One of the things that’s especially intriguing about node-webkit is that it gives you control over the browser you normally don’t have (e.g. window placement, file system access) — these are a constant usability sore-point in the project I am currently working on (which is a web app that is replacing a suite of desktop apps). It would be so much easier to get a lot of the things we want to do working smoothly using a hybrid desktop application built on top of something like node-webkit — it’s kind of a lemma of Alan Kay’s observation that anyone who wants to write really good software needs to build hardware — anyone who wants to write really good web apps really needs to build the browser.

The github repo for my project is here. It’s not a very general-purpose application; if you don’t use Cheetah 3D it’s completely useless.

A Little Privacy

Securing data from prying eyes is pretty much a solved problem. PGP is just as good as ever. So all you need to do to receive communications securely from another person is to create a PGP Private/Public key pair, broadcast your public key (hint — it’s shorter) to anyone who might want to contact you, and then decrypt incoming messages using your private key on the way in.

This only addresses security. Authentication is a separate issue, possibly just as important, and if anything harder to address (because it involves trusting third parties), and I won’t deal with this. Privacy is plenty to deal with right now.

So we’ve heard that secure communications providers are shutting down or destroying their servers rather than surrender to demands from the US government (NSA, FBI, CIA? We don’t know which branch or branches because they’re not allowed to say — lovely, huh?). What demands might these service providers be concerned about?

  • Surrender private keys (why would they even have these)
  • Install malware on their servers or on users’ machines (why would a secure email provider install any software on its users’ machines?)
  • Help surveil users (e.g. notify government agency when a specific user addresses his/her mail)
  • Monitor metadata (e.g. while the body of an email might be encrypted, the header information has to be plaintext).

Can you think of other things?

There’s a recent thriller (you probably haven’t heard of it — it tanked at the box office) starring John Cusack called Numbers Station. The idea is that the CIA maintains a network of shortwave broadcast stations that send out encrypted messages to sleeper agents. To do this they need a specially trained cryptographer and a network of highly fortified shortwave transmitters. Or something. It’s a stupid, stupid premise. (But not as bad as 2012.)

Let’s suppose we want to communicate with field agents securely. Well, before leaving HQ our field agent creates a private/public key pair and leaves the public key behind. He/she secretes the private key on his/her person (committing it to memory is probably impossible, so it might be in a tiny subcutaneous LED projector!) and then goes on his/her merry way, having told his/her handlers to post messages on usenet using his/her public key. There’s no other step required.

Now, how do we handle authentication? Hey, I said this wasn’t about authentication! In any event, same way we handle it using any other less secure communication channel. Perhaps authentic messages are agreed to end with “Signed Bob” or “The peanut walks by night”. Doesn’t matter — we’re talking about security not authentication.

How does Double Secret Agent VII find the publicly posted messages on usenet? Any number of ways. Perhaps they’re in messages entitled “but I like wesley” on alt.wesley.crusher.die.die.die. Perhaps they’re embedded in the comment tags of PNG images posted on It doesn’t matter.

Heck, you could just use mailinator. Want to email Double Secret Agent VII? Send an email to [email protected] and use the correct key. Done.

The beauty of the usenet example is that thousands of people will be downloading the message accidentally as a matter of course, and the message will be automatically distributed to thousands of servers whether anyone reads it or not. I really don’t know how PRISM, et al, would help against a determined, competent opponent communicating this way. This is probably why PGP had the US Government so riled up back in the 90s.

So, what about losing track of Agent VII? Simple. You’re Control (or whatever). If a communications channel is compromised (e.g. Kaos figures out you’re posting messages as EXIF data in pornographic images and deletes them or posts confusing spam) then Agent VII can use the Control’s public key to phone home. It’s not complicated.

So, here’s my modest suggestion for creating a secure replacement for email that everyone can use, and which can be gradually migrated to.

  1. set up a standard mail server.
  2. configure it to bounce any email that appears not to be encrypted using PGP with a message saying “if you want to contact [email protected] then use [email protected]’s public key to encrypt the message and provide your own public key so a secure response can be sent” and provide a link to a web page for securely sending such emails if the person doesn’t want to.
  3. outgoing emails are decorated with a public key for securely replying to the sender.
  4. account holders can have any number of handles (“email addresses”) associated with a given public key. They can access their email simply by asking for it. (Either there’s no passwords or everyone has the same password.)
  5. the server holds public keys so it can send the messages in item 2 (and provide a convenient system for sending the messages).
  6. Provide a simple to use web-based client for the service (which does all its encryption / decryption client-side) and provide links to a number of alternative open source clients. Make all the clients as transparent as possible.
  7. Provide a web-based client that deals only in encrypted data. (I.e. requires the user to manually extract and decrypt incoming messages, and encrypt outgoing messages.)
  8. Pay for all of this by charging a small amount (say $0.01) for each message sent to a user. (This is Bill Gates’s proposed solution to spam from way back, and if we’re going to migrate off email, we might as well cash in that idea.) Any profits could be donated to MSF, or the campaign to drown Jenny McCarthy in cat vomit.

Now, practically speaking, we could use passwords simply to prevent nuisance denial of service attacks, but we’d have absolutely no problem giving those passwords to anyone who showed up to our office in a sufficiently impressive suit, or driving a big enough SUV.

So, this gives us a pretty secure email system that is fairly interoperable with existing email systems (modulo requiring users “outside” the system to opt into using it, at least to contact its users) and which doesn’t hold any private information or keys at all. Heck, it can simply expose all of its data to Google. (Indeed, it could keep its code repositories exposed so that suspicious users could review changes to its codebase.) Now, it can’t be used with idiotic services that send you your login details, but you can either use another email service (e.g. gmail or mailinator) for those or implement a cryptographic bridge (e.g. if you subscribe using an email address prefixed with “insecure-” then it might do the encryption serverside for you.

Note that as described, the system doesn’t conceal metadata. So if [email protected] sends [email protected] orders to assassinate that pesky reporter, the fact that such a communication occurred (if not its content) is stored on the server. Of course, you could use the web client to anonymously send and/or receive the message, and use Tor to avoid leaving too much of a trace of having done that, but it’s kind of inconvenient, so normal people won’t do it very often. A normal person wants an email client that Just Works (this can provide that) and to exchange email with other people (this can get you there).

The proposed system provides end-to-end encryption of message content without the server needing to store any private keys and would allow all key components of the system to run in the browser (and thus have openly inspectable runtime code that could be monitored for changes). But it won’t stop the NSA from hitting you with a $5 wrench until you tell them where you keep your private key.

The GIMP Revisited

GIMP in Single-Window Mode
GIMP in Single-Window Mode

As part of my quest to replace Adobe’s Creative Suite with less expensive alternatives, I revisited The GIMP (“The GNU Image Manipulation Program”) the best-known open-source Photoshop clone. Earlier versions of GIMP were both hard to install and required X11 (they also tended to come with non-standard fonts) as well as having a confusing multi-window interface. All of these issues have been addressed as of August 2012 (yes, I’m late to the party).

(Inkscape still requires X11, and since there are plenty of inexpensive Illustrator alternatives that do not require X11, I am ignoring it for now.)

The version of GIMP I played with is the one that emphasizes Python scriptability. I didn’t actually try scripting it, but I’ll assume that the Python stuff is there and works ( scriptability is generally the most robust feature of open source projects).

First the good:

  • It’s free and open source.
  • Supports Photoshop’s pair-kerning shortcuts (option-left/right-arrow).
  • You no longer need to install X11 or jump through hoops to get a Mac version of GIMP. You can go straight to the main download page and get a .dmg.
  • The user interface is much improved over earlier versions. In many respects just as refined as Photoshop’s (and just as cluttered).
  • Single window mode.
  • Photoshop files are reasonably well supported (layers come out pre-rendered, but that’s about as much as you get from anything other than Adobe’s applications).
  • Native fonts are supported.

There are some warts:

  • The cross-platform imaging code is clearly not nearly as performant as Apple’s Core Image stuff — filters and even simple screen redraws are quite sluggish compared with any Core Image based editor (or Photoline for that matter).
  • There’s no >32bpp color support, which means it does not replace Photoshop for HDR work. I could not open .hdr files.
  • There are no layer effects.
  • The online help did not work (I tried the “Read Online” option and got a weird error message).
  • The windows, including file pickers, while quite attractively laid out are non-native, which can make simple things (like accessing non-boot-drives) a little annoying (you need to type in paths to get to things — luckily you can shortcut them once you get there).
  • The UI has some quirks, including palettes that float above dialogs and a funky “no document is open” document window that when closed quits the application.
  • Key filters copied from Photoshop are notably less useful (e.g. the difference cloud filter doesn’t create tiling fractals).

In a nutshell, GIMP is free and very capable, but lacks the non-destructive filters / layer effects of Acorn. Compared with Photoline, it’s scriptable but lacks non-destructive filters and >32bpp support. Compared with Pixelmator, it has a less refined user interface and lacks Core Image support.

The GIMP ★★★★★ (relative to the other Photoshop alternatives) — and note that I do not consider price in my ratings.

Creating UI Atlases in Photoshop Automagically

A little over a year ago I was working on a game engine for a successful toy company. The project never ended up being finished (long, nasty story which I’ll happily tell over beers), but one of the interesting things I did for this project was build a Photoshop-to-Unity automatic UI workflow. The basic idea was:

  1. Create UI layout in Photoshop, with one “root level” layer or layer group corresponding to a control.
  2. Name the groups according to a fairly complicated naming convention (which encapsulated both behavior and functionality, e.g. how a button might change its appearance when hovered or clicked and what clicking it would do).
  3. Press a button.
  4. Select a target folder (which could be inside a Unity project’s “Resources” folder, of course).
  5. And point a script at the folder.

This worked amazingly well and allowed me to adjust to changing client requirements (e.g. random UI redesigns) very rapidly. But along the way I decided there were significant design issues with the concept, one of them being that the images needed to be texture-atlases (b) for performance reasons, but more importantly (a) because you needed to adjust import settings for each image (you can’t even select multiple images and change their import settings all at once — maybe this is fixed in Unity 4).

Another obvious problem was the embedding of behavior in names — it was convenient if you got it right the first time, but a serious pain in the ass for iterative development (either change the name in Photoshop and re-export everything or change the name in Photoshop and then edit the metadata file, and… yuck).

Anyway, I’ve had the “perfect” successor bouncing around in my head for a while and then the other day it struck me that someone probably has written a Photoshop image atlas tool already, and I might be able to rip that off and integrate it with my script.

Turns out that (a) someone has written an image atlas tool for Photoshop and (b) that the key component of that tool was a rectangle packer someone else (sadly the link is defunct) had written, implementing an algorithm documented here.

So that’s what I spent New Year’s Eve doing, and the result — Layer Group Atlas — is now availble on github.

Screen Shot 2013-01-01 at 7.00.46 PM

For the more visually-minded, you start with a UI design in Photoshop. (Stuff can overlap, you can have multiple states set up for controls, etc.) The key thing is each “root level” group/layer corresponds to an image in the final atlas (and yes, transparency/alpha will be supported, if a group/layer’s name starts with a period then it is ignored (as per UNIX “invisible files”) while a group/layer with an underscore will only have its metadata exported.

Screen Shot 2013-01-01 at 7.02.47 PM

For every layer (other than those which were ignored) metadata about the layer is stored in a JSON file. (One of the reasons I didn’t take this approach with my original tool was the lack of solid JSON support in Unity. I — cough — addressed that with another little project over the holiday break.) The JSON data is intended to be sufficient to rebuild the original Photoshop layout from the atlas, so it includes both the information as to where each element is in the atlas, but where it was in the original layout.

Screen Shot 2013-01-01 at 7.01.36 PM

Finally, the script creates and saves the atlas itself (as a PNG file, of course).

Aside from the CSS sprite support I mention in the comments in a TODO — an obvious thing for this tool to be able to do would be to export a bunch of CSS styles allowing the images in the atlas to be used as CSS sprites — there’s one more missing thing: a Unity UI library that consumes the JSON/atlas combination and produces a UI.

That’s my project for tonight.

Nexus 7

Nexus 7, iPhone 4, and Kindle Fire
Nexus 7, iPhone 4, and Kindle Fire

My Nexus 7 (16GB) showed up yesterday — two business days after I ordered it. Shortly after activation I received my $25 of Google Play credit which kind of nullified the non-free shipping (insofar as $25 Google Play credit can be considered to be worth $25).

Cutting to the chase: I like it. Overall, I like it better than the (nearly one year old) Kindle Fire. (I like the Kindle Fire a lot more now than when I got it because of significant improvements to the OS, including password protection for purchases.)

My wife and I recently changed jobs, as a result of which we both had to give up employer-provided iPad 2s, and we’re now using our old iPads when the girls let us. So the contrast in performance between the iPads and the newer Android (ish) devices couldn’t be made more stark, and by-and-large it’s not terribly stark. In flat out performance (e.g. loading complex web pages) the newer devices are noticeably faster, but in general use the iPads are more fluid and pleasant, which seems to indicate to me that there are fundamental architectural issues in Android which are never going to be fully addressed (much as Flash sucked in ways Adobe simply couldn’t fix).

Seven Inches

I find both the Kindle Fire and the Nexus 7 to be totally usable for reading, web surfing, and watching video. If anything, I would suggest they are — overall — slightly superior devices to the iPad for those purposes for the simple reason that smaller size, lower weight, and better performance trump display size.

As soon as it comes to use as a computer substitute, the iPad simply wins. I have bought Sketchbook for all three devices (I have the cheaper phone-centric version on the Kindle Fire). I am a huge sketchbook pro user and I find the 7″ version to be frustrating at best (at least the Kindle OS has been improved such that it’s not horribly jerky any more).

Android v. iOS

As alluded to before, based on the jerkiness of Android 4.1.1 (insert dessert name) on the Nexus 7, Android’s UI/graphics subsystem is significantly behind iOS and it’s not going to catch up. But aside from the niceties of UX animation, I’m not sure that matters. If UX mattered that much, Microsoft wouldn’t have been worth more in 1999 — in inflation-adjusted terms — than Apple is today. Yes, these are different times, but give most people a 30% discount and make their UX clunkier and less tasteful and they’ll say “why yes, I will buy a new PC”. (As Don Norman mentions in the Design of Everyday Things, even his family is not immune — opting for price or features over aesthetics and usability when purchasing things like stovetops.)

Icons: one area where the Nexus 7 is seriously (but trivially) handicapped is aesthetics. While the system as a whole looks quite nice, there are some truly horrible icons. For example, the “Applications” icon — a white circle with six small white squares in it — which manages to be unintuitive, ugly, impossible to remove or replace (as far as I can tell — I’m sure it can be replaced) and locked to the center of the “dock”. There are plenty of butt-ugly icons — the music app is a pair of orange headphones that look like an escapee from Program Manager circa 1994, and the book reader is a blue book cracked open to face away from the user.

System: I find the basic Android “launchpad”, at least for the Nexus 7, to be pretty confusing. The Kindle Fire was pretty bad, but I’ve gotten used to it, and find it quite pleasant now. That said, once I figured my way around there are some ways in which the Nexus 7’s UI is markedly superior to both iOS and (as I understand it not having used it for more than a few seconds) Windows Phone 7. In essence, “widgets” (which are provided by apps) allows you to allocate a subgrid of icons in the launcher screens to be a small panel owned by an app. E.g. a mail widget might display a small inbox.

If there were one feature of the Nexus 7 / Android which I would like to see Apple copy into iOS it would be widgets. On the screen of my Nexus 7 in the photo you can make out the Gmail widget, an analog clock widget (sigh), a calendar widget, and a Flipboard widget.

Applications: iOS is ahead but the gap is definitely closing. Angry Birds — yes. Sketchbook Pro — yes. Tiny Wings — no. Grand Theft Auto Chinatown Wars — no. And, notably, when you try to search for games like Infinity Blade the name autocompletes (it’s a common search) but you get nothing but crapware. Perhaps more importantly, Pages — no. iMovie — no. Apple itself makes nicer software than Google and this has follow-on effects on the ecology that don’t change (just look at how Microsoft’s poor and inconsistent application design degrades the entire Windows ecosystem, or how Apple’s worst missteps — metal! — have been imitated slavishly).

One area where Android excels compared to iOS is its openness. I’ve got Firefox and could easily install one of a number of programming environments that don’t have any of Apple’s restrictions (e.g. Codea on the iPad won’t let you share your code with anyone else, short of email and copy-and-paste). The fact that there are no compelling development tools on Android (that I can see) is pretty telling.

Installing Apps: when I first tried to install an app I got mysterious errors which turned out to be quite common (the solution was to turn Gmail syncing off and on). Once I got it working I found installing new apps markedly quicker and more painless than achieving the same thing in iOS (and I appreciate having automatic update as an option, although I’d prefer it to be on a per-app basis). (Also — hint to Apple — I’d like to be able to delete an app instead of update it.)

Silos: why is there a Message app and a Talk app? Why is there a Gmail app and an Email app? And why a navigation app and a Maps app? If Apple’s insistence on dividing communication into silos based on the medium is annoying, Google’s rises to mystifying. At least on my iPhone I can see email from Gmail, Exchange, and vanilla POP and IMAP in one place.

3D Game Performance: I know that the Nexus 7 should be running rings around the iPad (and iPhone 4) but from my brief experiments with 3d games (I tried Pocket Legends and Space Legends, both from the same vendor, which may be telling) I found games to run more choppily on the Nexus 7. In any event the difference wasn’t marked, so I call it a wash.

Notifications: Android fans make a lot hay over the superiority of Android notifications. Thus far, I’d call it a wash (perhaps Android’s the weird little icons in the sometimes-visible “menubar” will prove to be helpful).

Content Offerings: Google’s Play store is ubiquitous but a tad confusing. On the one hand they offer you the option to get everything from magazines to apps to movies in one place, on the other hand there are a ton of different storefronts that are all slightly different. One thing I found pretty annoying is that it’s not made clear whether the “price” of a movie is purchase or rent (or what resolution is being sold to you). And, in the end, it just seems to be the same stuff sliced up differently (insert joke about Taco Bell’s menu options). In the end, Kindle, Netflix, and Hulu+ all run dandy on the Nexus 7 (I noticed Super 8 was available via Netflix streaming and watched it last night).


None really. I like the Nexus 7, and I think it’s a worthy competitor to the iPad in a Windows vs. Mac kind of way (i.e. it’s not as good, but has some nice things I wish the iPad had, and the price is right). Unlike the Windows vs. Mac comparison, the ecosystem is squarely on Apple’s side (for the time being, at least) — the iPad has a significantly better game selection. Notably, in key areas Android still hasn’t caught up with the original iPad. My Kindle Fire languished largely unused for about six months (I’ve been using it quite a bit since having to return my iPad 2) — I might have more definite conclusions after the rumored iPad mini ships or doesn’t ship.