I am SO glad someone has been working on this!

I was actually surprised that it hadn't already been done. I noticed that once I started writing it, I also started nervously checking the board hoping that someone else hasn't already posted a similar app.

I'll have to look through it soon and rewrite my apps (well, except the alarm clock, you kinda want that guy running in the background.)

Guess I'll just have to have them unbind from the menu when they're done, right?

I think it would depend on how they operate. For an app like emptris, or empacman, they never need to bind to the menu at all. An app like the alarm clock might not work that well with launcher, since you want an existing process to restart and attach to the display again. Under hijack, that's no problem, because the original process remains bound to the menu. Launcher doesn't currently allow for that behaviour -- it just forks a new process with an execlp(), while the parent sits around with a waitpid().

It might be possible to add a signal handler to your alarm clock, so that if you were to send it, say SIGHUP, it would wake up and grab the display again (think of the possibility -- you can finally give your alarm a taste of its own medicine). Then you'd have a wrapper script that can detect if the daemon is running or not, and either start it or send it the appropriate signal. You'd use the wrapper script in the launcher menu, instead of the actual binary, like I've done for the telnetd daemon.

Or you could get into socket programming...

A