Well, SITE EXEC and it's offspring are at the top of my own list, so that chunk of functionality will appear first.

After that, I probably will tackle the crazy apps question, but the thing that holds me back there is that I personally do not use any of the add-on apps, and most of Hijack development is geared solely towards what I need on my players.

But.. here's how it will work. "Foreground" means the app has access to the physical display and buttons, "background" means it does not have access.

The way I see this happening is that each app will have it's own screen buffer within Hijack, 100% exclusive of all other apps. This implies that two apps cannot share a common display screen, unless somebody writes a third app that manages this on their behalf.

The baseline content of each app's screen will be the current pixel output of the Empeg player app, on which user apps can overlay as they see fit when active. So any single app can show the player's data with their own overlay when they are in the foreground. Or, alternatively, we could just give each app a blank screen, and access to the player's screen, and let the app do its own overlay. Preference?

When in the background, a user app's screen does not show, and the app does not "see" any buttons being pressed/released. In the foreground, the app's screen is what shows on the physical display, and all button presses can be intercepted by the app.

A foreground app is fed (most) button events as they happen, and can choose whether to modify or delete them from the player's input stream, but only on a 1:1 or 1:0 basis. That is, it can do a 1:1 substitution, or simply "eat" a button event (not pass it on to the player). A background app doesn't see any button presses, and so cannot affect the button stream at all.

Hijack will provide some virtual button codes which bring individual apps to the foreground, replacing whatever (app, player) was previously in the foreground. These will be dynamic strings that match the app name, like "GPSapp", "Asteroids", and "PacMan".

There will also be an ioctl() by which a background app can request to become the foreground app (if not already in the foreground). Hijack will do it's best to respect this, but the app cannot actually tell the difference.. This way Hijack could defer such actions when the user is in the midst of player menu navigation, for example.

User apps can be launched from config.ini, and/or on-demand from the Hijack menu (courtesy of the EXEC stuff that comes first). This area might still be a little hairy, so initially I think apps may ONLY launch from the Hijack menu, rather than during the preinit phase from config.ini. We'll see.

Coding this is easy (for me).. it's agreeing on the details that's the tough part.