There are lots of opinions aired about the iPad; I share a lot of them, but disagree with some of them as well. 

Now, I could picture you great vistas of what the next two years will bring to the iPad. I will skip that: Yes, I find those things interesting too, and I have some pretty strong opinions about those, but lets lay down the impressions.

Read the rest of this post »

Hoa v. Dinh, in a rather unsuspicious tweet, announced the 1.0 release of libEtPan!, an open source e-mail client library.

In a like-wise unassuming e-mail, Hoa introduced his effort to build a library to replace c-client, back in 2002. As far as my archive goes:

On Tue, Feb 26, 2002 at 01:24:28PM +0100, Alfons Hoogervorst wrote:
> At 01:16 PM 2/26/02 +0100, DINH V. Hoa wrote:
> >I have almost finished all implementation of protocol
> >in libetpan. Local mail file access may be improved.
>
> Did not look at the code yet, but I'm all in for separating network
> specific stuff from sylpheed's ui code.
>
> What about thread safety?

Now 8 years later, release 1.0 is out, and what's the deal?

Read the rest of this post »

Craig Hockenberry has some interesting numbers on the iPad, but this part is interesting:

Amazing. However...

Read the rest of this post »

Jeff LaMarche wrote a nice iPhone devel posting about detecting hits in irregularly shaped buttons. It reminded me a bit how we solved hit testing in games, way back in the days.

I checked Jeff's code, which works pretty fine. The only thing that crossed my mind was that Jeff's hit testing allocates ARGB date for every hit test. There are a couple of simplifications possible, as I wrote here. First of all we only need the transparency information, and maybe it's better to store or cache the alpha mask. The reason: less data is being allocated. (Which may be moot, if your irregularly shaped images are small; and you have plenty of memory to burn on that iPad).

UPDATE: Jeff posted an update to his code, which you can find here. 

Read the rest of this post »

Rigth now, only certain Apple "certified" objects and apps can play
video over the TV-Out output. MPMoviePlayerController does not yet
support it.

Luckily the video player started by the web browser component
UIWebView has TV-Out enabled. What we do is the following:

* we create a view controller with a UIWebView
(probably defined in an xib). This controller's view is
entirely transparent, and the webview is hidden in the left corner;

* we fade out/in, and then present the controller as a modal view controller;

* the view controller's loading code passes the video stream URL to the
webview. Like magic, the webview detects it's a video stream and
launches the browser based video player on top of the controller.

The only real problem is detecting when the video player window
disappears. And this is the really tricky part, because you have to be
aware how different OS versions work with main windows and UIWindow
notifications.

The only reliable way to check for start and dismissal of the browser
based video player, is to:

1) wait for the main application window to resign its key window state

2) wait for the video player window to go into "hiding".

When the video player window hides, the key window is either nil (no
window is key), or it should be the controller window. In the OSes I
tested, the key window is always nil if the video player stops. This
is something that has been plaguing the MPMoviePlayerController for
ages, and it's good to see that the web browser based video player
suffers from the same problem.
If any newer OS is going to fix it, and transfer key state to the
original application window, we've got that covered: We explicitly
check for the key window to be nil, or if it's the application window.

Tachistoscope consisting of three software controlled hi-speed beamers. Up to 120 fps, synched on VBlank across three NVidia Vipers and custom made timer logic hooked on LPT.
Subjects were primed to different sets of, uhm, interesting imagery.