Hi all,

I just got this to a stage that I think is releasable. If anyone out there wants to test it and give me feedback, that'd be swell. I'm hoping it might be the answer to having all these different apps attached to hijack that don't play well together. One downside is that most of the current apps available will need some minor modifications, but they are extremely minor compared to the benefits, I think.

The synopsis from the README file:

SYNOPSIS
Launcher is a user-land application for the empeg that launches other
user-land applications from a configurable system of menus. This
eliminates the need for other applications to idle in the background.

I am SO glad someone has been working on this! 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 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

Very cool program. Thanks for modifying the source of viewer so I don't have to change it myself

It looks to me like you can still bind to hijack buttons and such with this app? Very, very cool.

Hopefully others will follow and mod their programs to work with this

Thanks again -

Very cool program.

Thanks!

Thanks for modifying the source of viewer so I don't have to change it myself.

I had an ulterior motive... I was writing an app that I couldn't test otherwise , and since I was already using viewer, it seemed like a good choice.

It looks to me like you can still bind to hijack buttons and such with this app? Very, very cool.

Yes. The only differences are that they 1) don't have to be written as daemons, and 2) don't need to (and probably shouldn't) bind to the hijack menu itself. Other than that, it's business as usual.

A

Cool. I'll modify my apps to support your launcer prog in a bit. I'll probably have to make it use a command line arg to tell it to not use the WAITMENU ioctl so people that just use plain Hijack can still use it.

1 feature request though, can you add the Kenwood IR codes as well? Thanks

- Trevor

Cool. I'll modify my apps to support your launcer prog in a bit.

And the ball keeps rolling!

I'll probably have to make it use a command line arg to tell it to not use the WAITMENU ioctl so people that just use plain Hijack can still use it.

That's a good idea...

1 feature request though, can you add the Kenwood IR codes as well? Thanks

Sure! It's been added to my TODO list...

can you add the Kenwood IR codes as well?

Done, and attached. Note that I don't have a Kenwood remote, so I couldn't do any testing. I hope I got everything correct.

I maybe being a little stupid here but.. i can't
get this tar file to extract!

I am a bit of Linux newbie so i could be doing something
stupid.

I tried:

tar -xvf 108196-launcher-v1.1.tar.tar
but get -

sh-2.03# tar -xvf 108196-launcher-v1.1.tar.tar
tar: This does not look like a tar archive
tar: Skipping to next header
tar: 480 garbage bytes ignored at end of archive
tar: Error exit delayed from previous errors

I'm pretty sure i've not got a corrupted file (downloaded it
several times now), and get the same error with the v1 file!

What am i doing wrong?

Anyone help!?

RichC

I am a bit of Linux newbie so i could be doing something stupid.

It could be your web-browser that's doing something stupid, since...

tar -xvf 108196-launcher-v1.1.tar.tar

...it looks like the original .bz2 extension has been changed to a .tar extension.

I'm pretty sure i've not got a corrupted file (downloaded it several times now), and get the same error with the v1 file!

What am i doing wrong?

The file is compressed with bzip2. You'll need to bunzip2 it before it can be untarred. WinZip, or something like that should be able to handle it, since I don't think it's native on the empeg. (If everyone prefers, I can distribute it as a tar.Z image, since the version of tar on the empeg can handle those natively.)

Just a note, though, you may not want to untar it directly on the empeg, since the distribution contains source code and a few other non-essential files (not that I class the README as non-essential).

If you can't find anything to uncompress it, let me know,
and I'll roll an uncompressed version for you...

Cheers,

Thanks..

Downloaded a copy of bzip2 and extracted launcher no problem.
Bit strange that my browser would change the file extention..
oh well..

Rich

Yeah, I had that same problem.. on multiple computers.. I don't think it is a browser issue.. I'm using IE 6.0.26, how about you?

I haven't had a chance to check this out for myself so forgive my ignorance; but the N02telnetd preinit.d script that you included will still be activated on startup by preinit, correct? (or if not, how can I make it init on startup?) You just made it optional to be started / stopped / and restarted from menu options via command line params right?

- durden -

Yes, that's right. There's a line up at the top that says if no arguments were given, to pretend that it was told to start.

I think distributing it as a normal gzip file would be beneficial.. Seeing as the process I have to go through right now is horrendous to get it uncompressed.. Download the file from here, upload it to a linux server with bunzip2 on it, (rename the file because for some reason it always gets .tar.tar extension) download the files again, and upload them to my empeg.. blech..

- durden -

I agree.. a normal tar file would be better...
im using IE 6.0.26. as well..

Rich

Okay, then. I'll switch to using a gzipped tarball for versions > 1.3