Mark has indicated that he's going to be getting back into hijack development once the cold weather sets in. In preparation, I wanted to summarize some of the wishes I've seen flying by over the summer, since I doubt Mark's kept up with the boards much.

These are kinda biased towards userland app interface enhancements, since those are the ones I tend to notice as a wanna-be programmer. If I'm leaving out your favorite wish, please feel free to respond. Just keep in mind that the tendency is to keep as many things out of the kernel as possible unless they can't be implemented as a user application.

Anyway, here's the top 3 wishes I've seen, in no particluar order:

1. Audio device access to 3rd party applications, possibly via the audio overlay patch. (Thread: 1.)

Kim Salo surprisingly released this to the world, and genixia and I have been working out a few kinks in it. I think it's just about Hijack-worthy.

2. Allow background apps to write to the display. (Threads: 1, 2, 3.)

Sounds self-explanatory, but the way to implement it might be non-trivial, given that the current interface requires user apps to block on the WAITMENU ioctl(). There are many apps that could benefit from being able to bind to the Hijack menu, but continue to run in the background and write to a small section of the screen in overlay-mode. Having a little mini GPS window on-screen when gpsapp is backgrounded would be neat, and I've been asked to have my alarm clock program display a little on-screen clock in the corner, independent of the player's info mode and timecode settings. With the way the userland application framework currently works, there's no way to do that.

3. Painless startup of user apps (Thread: 1.)

Preinit and Launcher have made the process of starting apps easier, whether on startup or on demand from the hijack menu. But I don't think they're the ideal solution. Not to take anything away from the efforts of canuckInLA and wfaulk, but Mark's idea sounds simpler. Instead of having launcher do the binding, the kernel could do it directly.

This not only reduces the number of things one has to install, but more importantly, could allow for "instant" application access, where items are always available in Hijack menu, whether they're running or not. Then, one menu selection could bring the application up, and it could either stay backgrounded or exit when the user leaves it. No need to explicitly bring the app up and then go into the menu a second time to select it. Maybe just mark "running" apps with a little icon or something. I think this one would let a lot of people who haven't taken the plunge on preinit and/or launcher run some of the apps more easily. And it'd probably save some RAM too.



So, anyway, I just wanted to collect some of the ideas in one place so we're all reminded of them, and also to give the community a chance to suggest any other wishes. Again, feel free to comment on what you'd like to see.

I see that you even linked my description of the userland-app-launcher. Thank you, my doppelganger.

Kim Salo surprisingly released this to the world, and genixia and I have been working out a few kinks in it. I think it's just about Hijack-worthy.

Why is it surprising? You may be bitter that he kept his GPS software to himself, and I'll admit that it didn't make me happy either, but it was his software, and his right to do so. Releasing this seems consistent: it's "base functionality" which other software could make use of. The GPS software was more or less a self-contained addon which could be sold separately.

Why is it surprising? You may be bitter that he kept his GPS software to himself, and I'll admit that it didn't make me happy either, but it was his software, and his right to do so. Releasing this seems consistent: it's "base functionality" which other software could make use of. The GPS software was more or less a self-contained addon which could be sold separately.

Hey, I'm totally on board with a programmer's right to do whatever they want with their own work. Believe me, I write software for a living. It just surprised me considering he had planned on selling his GPS thing closed source.

Having thought about it a little more, he would have had to release the kernel source anyway due to GPL restrictions, so I guess it's not so surprising after all.

Anyway, this is neither here nor there. Let's keep this thread focused on Hijack v3xx improvements.

I'm interested in IrDA. While still a minority, I have seen some growing interest in using other IrDA enabled devices to talk to the player.

Leaving any specific features up to userland apps to impliment, I think the only piece needed in hijack is the IrDA driver (thanks for posting one with that compiled in, Tony).

I don't know how much of a concern kernel bloat is... are we getting close some size restriction? If so, then maybe module support would be a better solution. People could compile their own kernel modules and get the add-ons they're interested in without bloating the mainstream hijack. Then again, if nobody else has modules they want to load, there's no point in doing it for just IrDA.

I'll second IrDA. My thoughts are a stripped down jempeg for Palm or PocketPC to allow playlist creation when away from network resources.

-Zeke

Well building for IrDA requires no special support for Hijack, it just needs the kernel to be built with the appropriate configuration. I'll be happy to post IrDA-equipped Hijack kernels on occasion for you guys if you don't have the ability to build kernels.

I just posted to Wish List about my desired use of IrDA. Thanks for the offer, but not having a shred of programming knowledge, I couldn't use it without other folk's contributions.

-Zeke

I'd be interested in this - Hijack seems nicely stable at v300, and I'd like a version with IrDA included to play around with. Would it prevent any other features from working?

A.

When I was back in Oz I had made a start on 3 and even had a exec= line working in the config.ini but it needed some tidying up beyond where I had got to as it didn't work consistently from kftpd (which I was trying to make work using the same code)...

If anyone wants the code I had worked on to keep going with it feel free... my old work webpage still seems to be in existence for the moment http://www.ned.dem.csiro.au/unrestricted/people/CovilKim/empeg/

I haven't had the time to work on anything empeg related since getting to the UK and starting work as a contractor. Hopefully I will get a chance to get back into it in the New Year.

Cheers

Kim

Good to see you stopping by, Kim. Your tuner detection patch was a real help for me while my power connector was flaking out.

Hopefully we can make the exec patch part of Hijack soon. The only thing that seems to be missing (based on my brief skim through the patch) would be the part where Hijack would have menu items for programs that are started up on-demand. But that wouldn't seem to be too difficult based on a quick look at your patch... Just add a new config.ini option like "exec_ondemand=" or something and have the Hijack menu call hijack_exec when that menu option is selected. Hmm, maybe I could even handle that... naaaaah.

Yn0t_'s Holiday Wish List:

1. Audio device access to 3rd party applications, possibly via the audio overlay patch.
   Done, Hijack-v301 released today.
   

2. Allow background apps to write to the display.
   This will likely be done when (3) below is implemented.
   

3. Painless startup of user apps.
   I will endeavor to work on this while stranded at the in-laws again this Christmas.
   

Cheers

-ml

Of course, all of you app-writers do realize that this will very likely necessitate some rework before existing userland apps will function purely under the new launch scheme. Initially, I'll have a compatibility mode for old apps, but memory constraints dictate that it be torn asunder before too long..

Cheers

Santa does exist, kids, and he knows Linux.

Thanks, Santa.

Santa,

I'm resurrecting this thread to see if you still have designs on reworking some of the user app stuff, particularly, numbers 2 and 3 in "yn0t_'s Holiday Wish List." I know you've been busy in your workshop building docking stations for good girls and boys, but I know you occasionally sneak in some Hijack work as well.

I anticipate having some time to work on emphatic soon, and could provide some beta-testing of any such improvements that would be made to Hijack's userland interface. I know you've got climbing season coming up in the not-too-distant future, and was just wondering if you think these userland improvements are in the cards, particularly as the dock queue grows.

I believe this necessitates a window manager for the Empeg, so that we can switch between having the buttons/display dedicated to (1) player, (2) Hijack menu, (3) app1, (4) app2, ...

Proposals everyone?

I believe so too.

I have been thinking about this a bit, and believe that the hijack menu is logically the 'kvm switch'. Holding the volume button should always jump 'back' to the hijack menu. I want to change this in gpsapp, which currently uses the play/pause button for this functionality. But whenever I think about it I always end up in this quagmire of how to deal with apps that want to slumber in the background and pop up into the player's display, or just 'monitor' a single button and pass it on if it turns out that we really didn't want it.

Perhaps an eventqueue similar to what palmpilots use. Apps can hook into the chain at some priority and pass on anything they can't handle. If no app dealt with a button press dump it in the player's lap. But then how to deal with the display. Assume well behaved applications and whenever the player updates the display copy all current 'clips' over it. That way gpsapp could pop up directions even while empacman is running.

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.

The idea that's forming right now is to have the "active" apps show up at the top of the Hijack menu (separate from their launcher entries), and to be able to select them and thus switch to them from the menu. The Player would also be on said menu, possibly as "just another app".

Button presses go ONLY to the currently displayed app.

Each app is given a mmap'd display buffer, which they can update anytime and as often as they like (or possibly two such buffers), and Hijack displays only the data for whichever app is supposed to be displayed.

I suppose we MIGHT want an option for an app to overlay the player, but this could get very messy very quickly, so I'm not so sure. An app could just do it's own "overlay", by reading the player's display buffer and merging data from that into it's own. Still messy.

-ml

And we'd keep something like the current button handling whereby a displayed app can elect to pass some buttons through to the player, or even feed virtual button presses through to the player.

-ml

Hmm.. How about a special combination of buttons, so to speak?

I mean, say I got the player, hijack, and APP1 running.

APP1 only uses the ">>" and "<<" buttons.
HiJack uses everything, as does the player.

Default, the player gets all commands, after being intreperted by Hijack's IRtranslate.

I want to switch that, and send one ">>" to APP1. Som on the remote I hit "Select mode", and then "1". Hijack sees this, and the next button(s?) I press is sent to APP1. After that, control defaults back to Player.

The only small oopsie I see with this is if I want "Select mode" to GO to the player. There might be a small (2 sec?) delay, as Hijack realizes we're *NOT* changing 'modes'..

Since I don't run many (well, any? That may change, tho.) apps in the background that would write to the screen, I can't really think, other than a menu selecting process that would work.. :/

Me.

Button presses go ONLY to the currently displayed app.

Well, so, assume I have gpsapp running but I want to skip to the next song. It seems sort of silly to have to background gpsapp, foreground the player, ffwd, background the player and foreground gpsapp again.

Or are you not counting remote buttons in with this?

Edit: yeah, this doesn't apply, but I don't like deleting posts. See my next message.

And we'd keep something like the current button handling whereby a displayed app can elect to pass some buttons through to the player, or even feed virtual button presses through to the player.

Guess I should read new messages backwards. Oh well

An app could just do it's own "overlay", by reading the player's display buffer and merging data from that into it's own.

Wouldn't that require the app doing the overlay to be in the foreground? It seems like there are a lot of scenarios where a background app should be able to take over all or a portion of the screen without user interaction. Emphatic being able to jump to the foreground when a song with lyrics tags plays or gpsapp doing a popup to warn about a turn even if you are doing something else for example.

-Mike

How about getting Palatir (Palm OS) support built into HiJack?

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!

Lots of good ideas on buttons, but very very weak on arbitrating the display. What do we do about two apps that fight over it? It's not acceptable to simply kill one of them (or fail it, almost the same thing). If both apps are "well behaved", then there should be a logical way for this to work for both of them.

I'm still leaning towards input_focus == display_focus. .

But I haven't really got a handle on overlaid displays yet --> there we would have multiple apps with display_focus, and fighting like cats and dogs over input_focus.

Not that I should care, since I have NEVER yet run any app on my player. Ever.

But I do care, because when it screws up, I'm the point man. I'll see 20 emails for every one that an app writer sees. This eats into my time. So I care.

Cheers

What do we do about two apps that fight over it?

Something tells me I'm a little over my head here, but couldn't Hijack act as a "middleman"? Like, could apps "bind" to the display via an ioctl (without actually opening the display itself) and tell Hijack "hey, I'm here, please give me a buffer to write to." Instead of the apps having to have the display open, they could write to that buffer, and Hijack would merge the buffers as needed. I'm assuming by "fight over it" you mean there'd be some contention for the display device itself. So why not have Hijack control the display device, and just mix in each of the application's own virtual display buffers?

But I haven't really got a handle on overlaid displays yet --> there we would have multiple apps with display_focus, and fighting like cats and dogs over input_focus.

Not sure if you got the gist of my hastily-written design above, but the way I'm imaging it, apps wouldn't be able to fight over input_focus. Hijack would do the passing of the conch shell, so to speak. No app would grab or release input focus, the kernel would do that. Apps would simply wait for focus events or sleep until they're focused again. Or am I not understanding what you mean by "fighting" over the input focus? My very shallow knowledge of how this might actually get implemented in the kernel is probably causing a bit of a communication gap here...

The reason I think separating input and display focus is a good idea is that input focus absolutely *needs* to be controlled because of the very limited number of buttons available, especially on the front panel. I didn't really have a concept of "display focus" in my design above, rather, the app with input focus would be drawn on top of the others, assuming it's using the display.

Not that I should care, since I have NEVER yet run any app on my player. Ever.

But I do care, because when it screws up, I'm the point man. I'll see 20 emails for every one that an app writer sees. This eats into my time. So I care.

If all of this is more than you want to deal with, then I'm reasonably happy with what's there today. There just seems to be a bit of interest in a new more flexible system for handling >1 userland application, and I figured I'd ask. Anyway, I'd hope people would have the sense to recognize that you're one busy dude, and would direct most questions to the BBS instead of your personal email.

Well, I go out for a few hours and come back to discover this!

Lots of good ideas. I'll make the following observations;

I don't like the idea of global focus. Whilst in the ideal world every app would be well-behaved, we know that in the real world some apps will have problems, and these could be harder to pinpoint with global focus. I have predictions of posts along the lines of, "App A not working properly, the left button doesn't work", leading to a month long delay until the developer of App A gets to look at it (this is a hobby right?), whereapon it is discovered that the problem is caused by App B whose developer is MIA. It opens the potential for frustration and applications that are mutually exclusive (at least until fixed). And in the meantime we all know who is going to hear the most about it...Mark.
I think that a major requirement for these hijack mods should be that a mis-behaving app cannot affect the operation of any other app. If we see an issue with one app, we know that it is that app that has the problem. Hijack issues should also be easier to find and eliminate.

So that basically leaves us with 'input focus' = 'display focus'.

I like the idea of abstracting the player itself into a generalised hijack application. (I guess that really means abstracting the init process?)
Obviously hijack itself would need to bind the buttons for the player. If it were possible to also abstract the existing hijack menu structure into something compatible, then I'd like to see a long press bring up a root menu, initially; {Player, Hijack}, that then gets further populated by applications, {Player, Hijack, gpsapp, emphatic, empetc}.
Each entry in this menu gets to bind buttons (except knob.L, and IR_MENUBUTTON.L) and gets a display buffer assigned, and only the currently selected item receives button codes. Timing out from this menu always reverts to the player, as does using the top button. If we could 'skip through' this root menu straight to the hijack menu when there aren't any additional apps bound then that's fine. Then those people who never use 3rd party apps wouldn't see any difference between the new scheme and the existing hijack menu scheme.

As you have observed, it is useful for some apps to sit in the background but still receive selected button codes. I wonder if it'd be possible to then add a LISTEN_BUTTON ioctl that allows the application to receive button codes that the player application receives (and only the player). So (eg) emphatic would BIND_BUTTON all the buttons that it needs during foreground use, and additionally LISTEN_BUTTON those it needs during background use. Since we abstracted the player, the player no longer receives codes when eg gpsapp is active. So pressing the right button on gpsapp would not result in emphatic receiving a button_right code either.

It's just occurred to me that the 'Select Mode' button is hardly ever used in the empeg. AFAIK it's only used when in a player submenu (eg search) or when in transient info mode to redisplay the current song title. I wonder if we could use this to switch rapidly between applications?

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

Would 5.1 still be required if we had a fast method of switching between the player and applications (as hinted at above)?

I'm of the opinion that UI consistency is a wonderful thing, and if we can avoid this then we should.

First off, I like your ideas for the operation of the Hijack menu. On to other comments:

I don't like the idea of global focus. Whilst in the ideal world every app would be well-behaved, we know that in the real world some apps will have problems, and these could be harder to pinpoint with global focus. I

First off, if we made the default would be local focus, a lot of this could be averted. Global focus would be for special uses, and if we document that fact, it'd be used sparingly. After all, we're all here, and the source is almost always open right? If the developer binds buttons locally, it'd be easy to tell who's to blame, because you'd know which app you had selected to get input focus.

I know I'm pushing really hard on this input focus != button focus point, and it's for one reason: multiple overlay windows! Let's pretend for a moment that the empeg display has an X11 window manager on it. Let's say you've got a desktop and two windowed applications. The desktop is analagous to the player app, because it's in the "background" in terms of display -- you almost always want it to be hanging around behind anything else that's displaying in an overlay mode. And let's pretend the two windowed apps in our window manager example are two empeg apps that wish to show overlays.

Okay, so emphatic wants to scroll lyrics while GPSapp shows heading, directions, or whatever. On an X11 desktop, you'd have emphatic and gpsapp each having their windows on the screen at once. Both have "display focus" as both are displayed on the screen, and can update their own section of the display. But by using your mouse (or Alt-Tab, or whatever) you can put the input focus on one of those apps. Typing a key while emphatic is selected doesn't affect gpsapp. That's "local input focus" which would be far and away the most commonly used technique.

Getting back to reality, and away from the X11 example, giving input focus to an empeg app could be as easy as a reserved button code, or opening up the hijack menu and selecting the app from the running apps list.

How would multiple overlay apps be handled if display focus == input focus?

It's just occurred to me that the 'Select Mode' button is hardly ever used in the empeg. AFAIK it's only used when in a player submenu (eg search) or when in transient info mode to redisplay the current song title. I wonder if we could use this to switch rapidly between applications?

That's great for those who use remotes all the time... Not so good for those who would want to use the front panel buttons. Hmm. I think back in the Single Digit Hijack Version Number days, Mark actually had "chords" of front panel buttons that could do stuff. Like, if you pressed the BOTTOM and LEFT buttons at approximately the same time, it brought up Pong. If that kind of functionality were brought back, maybe that's the quick switch Alt-Tab like thing we want?

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.
.
Userspace ir-translate. No display, but capture/modify the input event stream.

Doesn't sound reasonable to me. Does *anyone* still use userspace IR? If so, then they probably don't have Hijack installed. Moot point, or is it?