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

I understand this, but I know you've already implemented a lot of stuff you don't have any use for in response to other requests, and I think in this case, it benefits a lot of people, since it provides a framework for developers to implement things that people want, ultimately reducing the number of times you'll be asked to put something into Hijack.

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

Agreed... With that in mind, let me throw in my $0.026 CAD on the scheme you've outlined.

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.

Sounds great!

This implies that two apps cannot share a common display screen, unless somebody writes a third app that manages this on their behalf.

Hmm... How would this theoretical app (akin to a "window manager" or "display server" I guess) get access to the display buffers of other apps so it can present them on the screen at the same time?

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?

Starting out with the player's screen seems best, we can always clear out the buffer if we want a blank screen.

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.

This works fine for me, though this still leaves background apps without a way of putting anything on the screen. My thinking was that a background app could claim a section of the screen and then that would be mixed in with the player's display buffer, so that if a foreground app wanted to overlay on top of the player's contents, it could also have a background app displayed in sort of an "iconified" state. Something like this, maybe:

1. GPSApp is running in the foreground, updating its display buffer, handling input, etc.
2. User selects an option in GPSapp's menu like "iconify" or "minimize" or something.
3. GPSApp selects a window geometry in the corner, sends itself to the "background" (gives up button presses and its primary display buffer), and starts writing to the player's display buffer (the one you're copying into each of the user app's buffers so they can overlay.)
4. Another app (say, emphatic) receives the "bring to foreground" button code. When it goes to overlay on top of the player's display buffer, the contents of the GPSApp window are already there in a corner of the display.

This would also allow for other cool functionality, like the RDS info being displayed while the player is active (someone asked for this so they can display temperature) or even an app that pops up reminders on the screen at designated times (I could modify my alarm clock app to do this.).

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.

Sounds great to me.

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

I like this idea a lot.

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, I look forward to seeing how this shapes up.

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.

Sounds perfect to me.

Anyway, do you think it'll be possible to make this whole scheme backward-compatible with the existing API's? It'd suck if people had to have to rewrite their existing apps to take advantage of the new functionality, but I'm also not sure how much can be done without tweaking the behavior of the existing calls. Any thoughts?

Finally, thanks for considering this, I really think it'll make people more likely to take advantage of the apps people have written.