Programmers typically assume that a MouseUp() message won’t happen unless they had previously received a MouseDown()… and that these signals will come in precise pairs. Yet in almost every modern system that runs multiple applications at once, you will hit edge cases that send your program a MouseUp() when no MouseDown() ever happened—or two MouseDown() messages in a row.

There is no well-studied example of how to write your mouse handling code in a way that accounts for these cases. As a consequence, merely task-switching while still in the middle of a mouse operation will send a lot of applications into unexpected conditions! Many will crash or assert when you return… and those that don’t crash often do something bizarre. So I thought I would make a screencast of a prototype I made in 2002 which insulates programmers from these concerns. Even if you’re not a programmer and don’t want to read the whole article about the implementation, you might think the feature itself is unique, so check it out!

(Note: I use alt-tab to take the focus away in mid-mouse stroke, because that was easy to choreograph. But of course the technique is more compelling when an application in the background jumps forward and “steals” the focus. )

As you can see, my library took control of the mouse message pump and reduced the concerns of the programmer. If a mouse gesture was interrupted somehow I didn’t cancel the operation (nor did I just pretend the mouse button had been released and commit it). Instead, the library put the application into a suspended state with a placeholder icon at the last known mouse position. Clicking inside the placeholder restores your cursor to the previous coordinates and resumes the mouse operation, while pressing escape lets you abort.

Use Command objects that only run on MouseUp

In the past I’ve written about the importance of designing your program’s command processor in such a way that undo and redo operate consistently. One of the rules I mentioned was that your command processor shouldn’t be modifying the user’s document on MouseDown() or MouseMove(), but should accumulate the state in a Command object that is only submitted to your Undo/Redo queue when the MouseUp() is finally reached.

The good news is that if you’ve done that part right, then most of the necessary support work for this feature is already done!

A Command object not only makes things clearer for undo and redo—it also gives you a fantastic way of holding a mouse operation in “suspended animation”. The counterintuitive aspect is that pending commands must participate in the rendering process—since the document’s state alone is not enough to draw the view.

Build on Drag&Drop APIs, not mouse messages

One issue that I really had to grapple with was how to retain some control of the mouse cursor even when it had left my application. Sadly, running SetCapture() on Windows still means that the cursor will turn into the default arrow after the focus is lost. The way I found to work around this on Windows was with the Drag&Drop APIs—which turned out to be “tighter” than the default mouse API.

On Windows and other platforms, the Drag&Drop methods are precise analogues to the mouse messages we are familiar with:

1. DragStart() = MouseDown()
2. DragOver() = MouseMove()
3. Drop() = MouseUp()

(more…)

One of the key things that needs to be able to happen in order for open source projects to be aware of each other is some kind of database which the community can edit, linking related items together. The goal should be to help prevent someone from accidentally (or intentionally) obscuring the awareness of a competing effort. It could also be a tool for mitigating the effects of web scraping, by pointing to canonical versions of content direct from the author.

Wikipedia is actually serving this fairly well, and it’s one of the reasons why I tend to link to the Wikipedia page about products rather than (for instance) the download site or the corporate page. It may be true today that Ableton Live is the most outstanding audio software package on the market—but Ableton Inc. is unlikely to be linking to a formidable competitor’s homepage if that ever ceases to be the case. Users of Wikipedia have the opportunity to put in a “See Also” link.

Of course, search engines and review sites can do this—but often reviews are more stagnant than the corporate site. Still, something I tend to do when I’m investigating a new product or service is to type into a search engine the simple string “better than [PROGRAMNAME]”. This generates some possibilities to check out. But when I’m done, that information is lost, unless I write another review page.

This gave me the idea of creating something relatively simple—a small application which lets users express “A is better than B” relationships and upload those into a central database. Moreover, it would be able to track who holds those opinions and allow them to be lobbied to change their allegiances if new information comes to light. The concept is to create community pressure on the efforts that everyone thinks is inferior to (at minimum) place a notice on their web page informing visitors that there is another more popular option which is favored for particular reasons.

I imagine that the “better than” relationships could apply to nearly anything, though the intention is to compare things that are direct competitors. For instance, an MP3 file with a skip in it can be considered surpassed by an MP3 file that does not have a skip in it. By storing the Cryptographic Hashes of the items being compared (whether they be names of things or entire giant binary files) it would be possible to efficiently store these relationships in the database. A browser plugin would constantly hash downloaded content and URLs and give you tips when you were looking at something that had a better version.

The basics of this program is not necessarily difficult to write—but there are many details to be thought through in regards to the management of vandalous contributions or blatant falsehoods. A similar set of issues was brought up by the Mindpixel project—which was similarly trying to build up a repository of consensus knowledge using lots of tiny facts contributed and rated by various people.