I vote for a way to make an ir_translation that would open a certain userland app registered in the hijack menu. It would be nice to open GPSApp or other apps without all the fuss.

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.

and most of Hijack development is geared solely towards what I need on my players.

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

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".

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.

Okay, how about: An app can request via ioctl() that it be placed in the foreground. This just sets an "activate me" bit in a data structure within Hijack. A similar ioctl() will exist to clear this bit, forcing the app to the background (or cancelling any prior request to be foregrounded).

The ioctl() always completes (returns) immediately, and Hijack will at some point attempt to "foreground" the app. When an app eventually DOES transition to foreground or background, it will receive a virtual button event indicating such.

And with site exec already in the works, this will make installing said apps much, much easier. Thanks, Mark!

In reply to:
> This wish can be done already today.

I'm glad it was easy for you. Any clues on how to do it? I've done a fair amount of searching.. maybe I missed some ir_translate command..

Not an end-user thing. But apps can probably achieve this behaviour with the interface that already exists. Or not.