Infincia

Codepoints 1.0.4

Thu, 02 Aug 2012 17:49:47 UTC

The release of Mountain Lion brought an interesting bug in Codepoints to the surface that for some reason had never occurred on Lion.

In certain cases, the background for some rows were being drawn transparent (technically zero height, but the end result is transparency).

Details of the problem are below, but an update has already been submitted to the App Store to deal with this and an updated Retina icon has been included as well.

The problem: caching & assumptions

Each row in Codepoints has a gradient background drawn in code (forgive the formatting):

-(void)drawBackgroundInRect:(NSRect)dirtyRect { 
    // if cellBackground does not exist, create it
    if (!cellBackground) {
        // NSImage ivar 
        cellBackground = [[NSImage alloc] initWithSize:dirtyRect.size];
        [cellBackground lockFocus];
        //cellGradient created elsewhere, just a basic gradient
        [cellGradient drawInRect:dirtyRect angle:270];
        [cellBackground unlockFocus];
    }
    // now actually draw the NSImage into the background rect
    [cellBackground drawInRect:dirtyRect 
                      fromRect:NSZeroRect 
                     operation:NSCompositeCopy 
                      fraction:1.0];    
}

There is an assumption being made about the size of dirtyRect here, one that didn’t seem to cause a problem on Lion for whatever reason.

If this code were simply generating a new background image gradient every time the background needed to be drawn in a row, there would be no problem here as far as correctness, it would always work.

But for performance reasons, it’s caching that NSImage in an instance variable, and at times the cached version is not full height because dirtyRect is not always the full size of the row, occasionally it will be partial or zero height (likely when the row being drawn isn’t on-screen yet). So a partial or zero height background image was being drawn into a fully visible row.

The result was that some rows appeared transparent (a zero height background is essentially no background), which then caused scroll and click events to pass through the transparent area to whatever was under it, causing issues with scrolling and clicking.

Instead the code now creates the background image ahead of time when each row view is created, using the actual size of the row, and then draws that into dirtyRect when the background needs to be drawn. This seems to have solved the problem :)

The Mac App Store Sandbox deadline, Mi-Fi Monitor, and Codepoints

Fri, 01 Jun 2012 19:12:28 UTC

Today, June 1st, is Sandbox day. From now on, all new submissions to the Mac App Store must be sandboxed.

Developers with non-sandboxed applications already on the store have a choice to make in the near future if they haven’t acted already, they can either implement sandboxing, submit only bugfix updates (no new features), or pull out of the Mac App Store entirely in favor of selling direct to customers over the web, which is a viable option in some cases as the Mac is still a very open platform compared to iOS.

For me, today isn’t much of a deadline however, as both of the Mac software utilities I've published on the store are already sandboxed and don’t require any special behaviors that would conflict with Apple’s restrictions.

Codepoints

Codepoints for Mac is the simpler of the two utilities already on the store, it requires no “entitlements” of any kind. In addition, none of the features that are currently being added to it will run afoul of the sandbox rules either.

Here’s the sandbox config for it in Xcode:

It is essentially a happy resident of the Sandbox and has been there since it was released a few months ago.

Mi-Fi Monitor

Mi-Fi Monitor for Mac is also sandboxed, but does require one entitlement: Outgoing Network Connections.

Here’s the sandbox config for it in Xcode:

As Mi-Fi Monitor is essentially a display for the status API available on Novatel’s Mi-Fi, it must be able to communicate with it over the network. Specifically, it must make periodic HTTP requests to a CGI script running on the Mi-Fi itself.

In addition there is a feature buried in the preferences area of Mi-Fi Monitor that allows users to manually submit debug information to me if something isn’t working properly, and that also occurs with an HTTP POST connection to a special Google App Engine system I created for it.

This is all standard behavior for most applications though, so merely ticking the box to request that entitlement gives it everything it needs to do its job.

Hotkeys in Codepoints and the Mac App Store

Thu, 17 May 2012 19:23:04 UTC

Update: Crisis averted :)

Earlier today Erica Sadun at TUAW posted an article about Apple potentially rejecting applications from the Mac App Store that use “global hotkeys”.

As Codepoints for Mac makes good use of global hotkeys, and ships on the Mac App Store, naturally I'm a bit concerned about how to handle the situation, if true.

Codepoints uses an optional global hotkey so you can access it from anywhere, even if you're typing in a word processor or writing code in an IDE, or writing an email. The alternative (or one of them, see end) is to use the mouse and manually hit the Menu Bar icon each time.

Codepoints doesn’t set this hotkey on its own, it ships with the hotkey disabled and presents the user with a message in a small box noting this capability:

Apple’s Sandbox

The assumption being made is that this potential change is related to the Sandbox, due to become mandatory on June 1st.

However, Codepoints is already sandboxed, and has been since the day it became available on the store, so that doesn’t make much sense to me unless Apple simply hadn’t got around to excluding this public API (see below) from being used by sandboxed apps.

More likely, if true, Apple just doesn’t want Mac App Store software to let users override the keyboard commands of other applications or system actions. For instance the default keyboard commands for copy and paste are cmd-C and cmd-V, respectively. However, applications that allow the user to set global hotkeys can override both of those actions if the user accidentally picks those key sequences to do something else, which may cause confusion.

Global hotkeys can also conflict with local hotkeys, those that have a specific action attached to them within an application. For instance, Sparrow uses cmd-N to open a new mail dialog, however if cmd-N is set to be a global hotkey elsewhere, that action is the one that will actually take place when the user presses that key sequence, even if Sparrow has focus.

It’s also possible that Apple simply doesn’t want Mac App Store software altering global behavior of the system, and global hotkeys definitely qualify there.

Global Hotkeys in OS X

If you don’t know what global hotkeys are, they allow an application and the person using it to designate a specific key sequence that can be attached to a specific action in that application, which works even when the application isn’t in focus. OS X also allows you to set global hotkeys for some OS level actions, you can see those in System Preferences under the Keyboard area.

Global hotkeys aren’t new on OS X, nor are they part of a private Apple API. The one Codepoints uses for this purpose is part of Carbon and is specifically made available in the public header files, which note that it has been there through the entire life of OS X, from 10.0 forward:

extern OSStatus 
RegisterEventHotKey(
  UInt32            inHotKeyCode,
  UInt32            inHotKeyModifiers,
  EventHotKeyID     inHotKeyID,
  EventTargetRef    inTarget,
  OptionBits        inOptions,
  EventHotKeyRef *  outRef) 
AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;

As this API is part of Carbon, my guess is this functionality predates OS X entirely and was available in Mac OS 9 and earlier.

The API is not deprecated in Lion, and so far as I know it isn’t deprecated in Mountain Lion either, but it seems if Erica is correct, Apple does not want Mac App Store applications to use it anymore going forward.

Codepoints

As for Codepoints, it’s likely that it will remain on the Mac App Store and I can still issue bugfixes, but the first time I go to add a feature, Apple is likely to reject the update until I remove that global hotkey box.

There may be alternatives I can look in to, other APIs to use that don’t strictly involve setting a global hotkey but still provide the same functionality, I'll certainly check and update Codepoints if I find a good solution.

About font rendering in Codepoints

Thu, 26 Apr 2012 19:14:37 UTC

Earlier today I got a support email from a customer who found a bug few people are likely to hit in Codepoints, causing it to render characters small and in black:

Both of those font rendering characteristics, size and color, are actually hardcoded in the app to be fairly large and white, which led me to believe there was something funny about the fonts on the system.

As it turns out, the issue is caused by a font that was intentionally disabled by the user, and by chance it was the one font that Codepoints (and OS X itself) relies on to render a large number of Unicode glyphs, because it is the only one that ships with OS X that can render many of them: Arial Unicode MS.

I'm preparing to update Codepoints to deal with situations like that, but I thought I would write a little about how font rendering in OS X actually works, and how Codepoints handles it.

The Unicode 6.1 specification has 24,428 records in the database, however no single preinstalled font on OS X can render all of them. In fact, even when taken as a whole, OS X does not have font glyphs to render them all, and installing a 3rd party Unicode font is needed to get full coverage (GNU Unifont is common and free).

To deal with this, most operating systems use fallback behavior, they first try to render a character with the default or user selected font, and then cycle through other installed fonts until they either find a suitable glyph, or use the Last Resort font, or give up entirely, which tends to look like a question mark or a black box.

(Codepoints actually detects when the Last Resort font is about to be used and explicitly rejects it on a case by case basis, because most of the time the glyph returned by Last Resort is simply not useful as a preview)

When automatic font selection is turned on in Codepoints, what the app does as of 1.0.2 is select Arial Unicode MS as the font to render things with, but will allow OS X to use the standard fallback mechanisms to render characters when Arial can’t. This has the side effect of ensuring that most previews are rendered by the same font, giving at least some visual consistency to the list when scrolling.

Selecting a specific font in the drop down menu is when things get interesting, instead of merely asking OS X to render a character with a specific font (which would trigger fallback behavior), Codepoints actually takes upon itself the job of determining whether or not the selected font can render a specific character, and by doing this it becomes possible to completely disable the fallback behavior. If you select Helvetica, you will not see any character at all if Helvetica cannot render it.

The goal there is to not have the interface “lying” to the user, if you select a specific font, but then Codepoints allows a character to be rendered by something else, it would be misleading.

If you want to know the reason a specific character was rendered or not rendered, you can mouse over the right side of the row and a tooltip will appear. Most of the time this tooltip is accurate, however there are some edge cases where a font claims to be able to render a character and Codepoints trusts it, but then the font doesn’t actually return a glyph. You can sometimes see this in the higher Emoji range when the Apple Color Emoji font gets a little overzealous, but also with some obscure symbols in the lower range.

I haven’t decided whether or not to actually switch the default font yet, as I need to do some testing to see what exactly happens when you disable major fonts like this, however I do plan to deal with it in 1.0.x :)

Mi-Fi Monitor 1.4.1

Mon, 09 Apr 2012 05:03:07 UTC

Mi-Fi Monitor 1.4.1 should be making its way out to both App Stores right now, the primary changes are minor cosmetic/alignment bugs fixed, but a few of the core 3rd party libraries (CorePlot being the big one) have been updated too.

I'm also finishing up the GPS support which will probably roll out on iOS first, though I'm working on the Mac component separately.

Codepoints 1.0.2

Fri, 03 Feb 2012 20:02:39 UTC

I've submitted an update for Codepoints to the App Store, which fixes 2 critical issues that affect certain users:

Codepoints now carefully checks 3rd party fonts and ignore any that aren’t usable (caused odd crashes)
Resolve a rare timing issue where the app would appear empty after launching

Both of those issues have been fixed and the update is simply waiting for approval, which on the Mac App Store tends to happen fast.

Codepoints 1.0.1

Thu, 02 Feb 2012 20:21:22 UTC

I've submitted (and Apple has already approved) Codepoints 1.0.1, which should be making its way in to the Mac App Store right now.

The only change is that Unicode 6.1 data is included with the update.

A future Codepoints update will probably include the ability to update Unicode data automatically when new versions of the standard are announced.

Codepoints 1.0

Thu, 02 Feb 2012 15:42:55 UTC

Codepoints for Mac is now available on the Mac App Store :)

Since this is the first release I thought I'd give a little background on why I wrote it.

When I started working on Mi-Fi Monitor back in 2010, I quickly discovered that the API for those little devices spits out a string of key=value pairs separated by an invisible character (escape). I remember having to google “escape character” repeatedly so I could copy it into the clipboard.

That was not my first encounter with string encoding and parsing, but it was one of the first times I noticed how difficult it is to use characters that aren’t easily accessible from the keyboard, particularly the control characters which have no width or visible representation.

There are of couse ways for dealing with those invisible characters, in certain situations you can type \0 for null or \n for linefeed, but that doesn’t apply everywhere.

But ok, those are invisible control characters, nobody but a programmer should have to care about them anyway, right?

Right. I and most other programmers eventually pick up on those and remember the few that we need, problem solved…… if you only care about invisible ASCII control characters.

Now toss Unicode into the mix, with ~24,000 assigned codepoints. Any hope of even remembering the numbers so you can use them in one of the few places a Unicode escape sequence will work, goes right out the window.

What’s the Unicode escape sequence for the Euro currency symbol? Or any of the various musical note symbols? What about the Greek Omega? Or the Copyright symbol? Registered trademark?

Should programmers have to remember all these? Or just some? Should you even have to be a programmer or know what an escape sequence is to use them?

I don’t think you should, so I wrote Codepoints for Mac.

My goal with Codepoints was to make it easily accessible from anywhere on your Mac, very fast, and to make it disappear immediately once it is no longer needed.

As a result, Codepoints is a Menu Bar app that can be accessed at any time with a single click (or global keyboard shortcut).

Once the popup opens, you can search by typing immediately (no mouse work required), scroll the list using your mouse or arrow keys, and double click a row or select it and hit enter. This copies the character into your clipboard, closes Codepoints and returns focus to your previous application.

I've got some interesting things to add to Codepoints soon, and I plan to keep it in sync with the newest Unicode standard, which was 6.0 when Codepoints was submitted to the App Store but has since been updated to 6.1. An update should be due out soon with that.

Mi-Fi Monitor 1.4

Mon, 23 Jan 2012 04:43:53 UTC

Mi-Fi Monitor 1.4 is waiting for approval in both app stores.

The primary change on Mac is the ability to selectively enable the signal, battery, or both icons in the menu bar. New icons are also included, I heard from more than one person that the old ones were too big so I started from scratch and made Mi-Fi Monitor draw them on-the-fly in code (using bezier paths and a ton of math :)

On iOS and Mac the graph is now marked clearly with a time frame (45 seconds), and on iOS the graphs are back to being bubbles, the full screen graph was just too big especially on the iPad.

I've also removed the password field on both platforms since it isn’t used anymore.

I've also fixed a minor memory leak in the Mac version. It was only a KB every few seconds but over the course of a few hours or more it could (and in one case did) add up to quite a bit of memory use.

In the process of fixing that memory leak I decided to just take the time and convert Mi-Fi Monitor on all platforms to use ARC, which should help prevent leaks in the future and make the entire codebase more maintainable.

The switch to using ARC means 32-bit Macs can’t be supported anymore because ARC doesn’t work on 32-bit machines. Everyone on Lion has a 64-bit machine, but there are probably still a few 32-bit Snow Leopard users around.

Mi-Fi Monitor 1.3.3

Thu, 15 Dec 2011 04:26:50 UTC

I've submitted an update for Mi-Fi Monitor to both app stores, the primary change is the option to select a specific Novatel Mi-Fi model. This should make it more clear which devices are supported, and 2 of the settings handle specific cases for AT&T and WiMAX devices that have slightly different behavior.

I've also made the Mac version Snow Leopard compatible and updated the Growl SDK

Mi-Fi Monitor for Mac approved

Sat, 10 Dec 2011 04:26:50 UTC

Today the Mac version of Mi-Fi Monitor was approved and released for sale on the App Store.

Though the version number is 1.3.2, this is only because Mi-Fi Monitor is a universal app across iPod, iPhone, iPad and Mac, they all share about 80% of the same codebase with platform-specific interfaces built on top.

The Mac UI is relatively new and may need to be refined a bit, but the core functionality should be very stable.

Mi-Fi Monitor 1.3.2

Tue, 06 Dec 2011 04:26:50 UTC

Mi-Fi Monitor for iOS 1.3.2 is in review right now:

Fixed a rare bug where attempting to open the support form right after installing the app (before letting it try to connect to the Mi-Fi) would cause a crash
Fixed the incorrect version number in settings

Mi-Fi Monitor for Mac is at the stage where I'm comfortable releasing it on the Mac App Store, so 1.3.2 will be the first version there when it is approved.

I'm still working on the GPS stuff for 2.0, and plan to add some requested features to 1.4 in the meantime. The signal graph is probably going to revert back to its previous look but offer a button to expand it to fill the screen. I'm also adding a slider to the settings area so you can set how often you want the app to check your Mi-Fi for battery and signal status.