Glad you asked!

I have had some thoughts about this. Since emphatic works so intimitely with the existing interface to do tricky things like act as a "skin" in front of the player, a lot of random ideas for improvement have popped into my head.

First, let me respond to this question:

I would like to hear of a plausible and reasonable example of when a "background" app (not on the display) needs to intercept button presses.

I guess this gets into what exactly is "backgrounded." Your definition is "not on the display." But in the perfect world, the display could show the player screen, and also small windows of one or two apps in kind of an "iconified" or "minimized" state.

Let's take a hypothetical scenario where we've got the player app, gpsapp, and emphatic running. I'm picking these because each has slightly different needs in this scenario:

• The player app is, obviously, the main focus of the empeg. You usually want most button presses to go to it, and unless another app is running full-screen, the player app is always going to be at least partially visible.
• gpsapp would run full-screen at times, intercepting several buttons. It would also want the ability to run in a small overlay window (as the current API supports) except, from what I gather from Jan's post, there may be one or two button codes that it wants to trap. Jan may or may not be interested in taking advantage of the ability to completely "background" itself from any display or button presses.
• emphatic also makes use full-screen modes and overlay modes. Right now it also has certain occasions where it "minimizes" itself entirely to show the entire player screen, but still takes button presses. This is done by taking a very small overlay window in the bottom left. Ideally, a mode would be available where apps like emphatic can unbind from the display entirely, but still intercept buttons.
  

So, clearly, different apps have different needs. Here's my ideal Hijack architecture:

1. Hijack has a pre-configured list of programs (along with their command lines) that can be launched from the Hijack menu.
1.1. When user apps are launched, they must "bind to Hijack", but unlike WAITMENU, instead of blocking, they just get hooked into the Hijack "menu rotation" and the call returns. (e.g. BINDMENU)
1.2. The app can then run in the background as it wishes.
2. Hijack has the concept of "input focus" similiar to UNIX window managers.
2.1. Selecting an app from the Hijack menu's list of running apps gives that app input focus, but does not change its display mode. Display mode changes will be left to the applications.
2.2. Hijack has a blocking ioctl() which will let the app sleep until it's got input focus. (e.g. WAITFOCUS)
2.3. Hijack has a blocking ioctl() which will let the app sleep until it's lost input focus (e.g. WAITUNFOCUS)
2.4. Hijack has a non-blocking ioctl() which will let the app know if it's received or lost input focus since the last call. (e.g. POLLFOCUS)
2.5. Hijack can be configured to have certain button presses act to switch focus backward or forward in the chain (think Alt-Tab in Windows)
2.6. Hijack can be configured to have certain button presses give input focus to a specific application.
3. Apps can bind to buttons in two different modes: local or global
3.1. With local binding, the binding app only receives those button presses when it has input focus.
3.1.1. The same button can be bound locally by any number of apps.
3.1.2. Apps which are not focused will not receive button presses to which they have bound locally.
3.2. With global binding, the binding app, and only the binding app, receives that button code at all times, regardless of whether it has input focus or not.
3.2.1. The first app that binds a button globally keeps it until it unbinds from that button or binds to it locally. Attempts by other apps to bind globally to that button will fail.
3.3. Regardless of binding scope (local or global) the binding app is free to re-inject the button to the player via the existing INJECTBUTTONS ioctl().
4. Apps can choose between no display, overlay display, or full-screen display. (null geometry, partial geometry, or fullscreen geometry)
4.1. Apps are free to change geometries whenever they wish.
4.2. Apps can use the aforementioned WAITFOCUS, WAITUNFOCUS, or POLLFOCUS as a means of intelligently switching between display modes when appropriate.
4.3. The app which has input focus is guaranteed to be "on top" of the display.
4.3.1. If it's a fullscreen app, it's drawn in front of all other apps.
4.3.2. If it's an overlay app, it's drawn in front of the player's display, and in front of any other overlay apps which have that section of the display.
4.3.2.1. Other overlay apps (without input focus) will continue to draw, but behind the focused app.
5. Hijack keeps the existing long-press to go to the Hijack menu by default.
5.1. User apps are allowed to override the long-press if they wish.
5.2. Hijack provides an ioct to programatically switch to the Hijack menu (so that apps which have chosen to override the long-press can provide a means to get back to the Hijack menu.)

There's a lot to this rough design, and there may be flaws in it. It's just something I have in my mind. The underlying principles are to have all apps be able to run in the background, to separate the binding of buttons from the app's display mode, and to allow multiple overlay apps on the screen at once. Additionally, the "global binding" of buttons allows flexibility for cases where you want an app to always get a particular button.

So, does the above make ANY sense to anyone except me? I can clarify if I haven't explained something right.. And if you see a hole in the design, please comment!