Free launchers software for linux

USB Launcher project is a couple of basic programs to drive the M&S USB Missile Launcher.
ctlmissile does all the actual work. Youll need libusb installed to compile it, but assuming you have that typing "make" should do the trick. You can then
do:
ctlmissile up
ctlmissile down
ctlmissile left
ctlmissile right
ctlmissile fire
ctlmissile stop
to do all the things youd expect. Note youll need to be root to use it. I
havent figured out a nice way to use libusb yet as a user. Anyone got some pointers?
Oh, and youll need to not have usbhid installed or itll claim the device itself (I think I can add support so that it gets automatically disconnected from the device, so Ill have a look at that).
usblauncher is a Perl program that uses GTK2 to provide a basic interface for controlling the launcher. It uses ctlmissile. Currently Ive made ctlmissile suid root so I can run usblauncher as my normal user id, but Im not sure about this long term.
Enhancements:
- Added support for Dream Cheeky USB missile launcher from James Puderer.

Game Launcher project is a universal front end for emulators.
The main goal is to provide a user interface that is easy to use and attractive, yet does not look like a traditional user interface with windows and such.
Game Launcher should work with any emulator, but it has been known to work with MAME, Nesticle, RockNES, zSNES, snes9x, Callus, Stella, z26, and Versions are available for Unix, DOS, and Windows.
Main features:
- Very flexible. It should run with any command line emulator.
- Simple and easy to use interface.
- Plays music in the background (MP3s or an audio CD).
- Displays screenshots (PNG, PCX, BMP, and JPEG).
- Customizable font.
- Customizable screen resolution.
- Support for vertical (rotated) monitors.
- Slight menu animations.
- Support for PC joysticks.

Gnome Terminal Launcher applet reads the profiles from GConf and creates the corresponding menu entry to invoke the gnome-terminal command and its arguments.

If you are a system administrator, perhaps a command line junkie, and you deal with a large number of servers on a daily basis, you may have already created profiles to define the connection characteristics of each server.

Ive also experienced an improvement in usability assigning a different color and icon to a server or group of servers. After a while, you can quicly identify which server are you connected to with just a glimpse of the screen.

But this has a drawback, the only way to open a terminal is from another terminal unless youve already created launchers for the specific profiles.

To provide a cleaner solution. Ive create the gnome-terminal-launcher applet that reads the profiles from GConf and creates the corresponding menu entry to invoke the gnome-terminal command and its arguments.

Panelizer project is a memory efficient desktop panel.
It works by holding all applets within the panel process itself.
Typical memory usage is currently around 1MB with 10 applets loaded.
Applets are provided by dynamically-loaded shared libraries, and new ones can be easily written using an easy C ABI.
Configuration is stored as XML and each applet has its own configuration data.
Here are some currently implemented applets of "Panelizer":
- launch menu (uses Open Desktop compatible entries)
- clock
- CPU instant load bar
- mail notifier (biff)
- removable drive mounter and ejecter
- network traffic monitor and (limited) launcher
- memory monitor
- audio mute

Better Weather contains a couple of scripts using normal KDE and Linux tools to provide better display of weather info than KDEs weather applet. It downloads the information from the US national weather service and maps from weather.com. Two launchers on the main menubar bring up the window separately. Full details and instructions are in the readme.

This is a solution that worked for me, not being a coder. You have to make it work for you. Its an idea and a set of tools. Its also US-centric, but someone may take the idea and make it work just as well anywhere. I hope someone finds it as useful as I do.

WHAT IT DOES

The tools I wrote are two *very* simple bash scripts. The script, localwx.sh, invokes the python weather utility, and downloads the current weather conditions and forecast in text format from the weather service. It stores the information temporarily in a text file (I chose the desktop as the directory in which to save it.) It then "reads" the text file into a kdialog box. When the "ok" button is clicked, the temporary file is deleted.

The other script, wxmap.sh, downloads a current local weather map image using wget, saves it temporarily to the desktop, and calls Kview to display it. When Kview closes, the temporary image file is deleted.

HOW I DID IT

The man pages for "weather," "kdialog," and "wget" were useful for determining which options to use. The script for weather forecasts has to be edited to receive the data for the users current location. My nearest airport is PDK, so my ID was "KPDK." The rest is straightforward enough. To make the weather map script work, you can go to weather.com or your local tv station website and copy the image location for the weather map they use. It can be pasted into the script.

Once the scripts were edited to suit, I made them executable (chmod +x filename), copied them to /usr/local/bin, and created a launcher for each in my main menubar. Describing the process is a lot more difficult than actually doing the work!

autopackage allows developers to produce "install anywhere" packages for 3rd party Linux software. The resulting packages support both graphical and terminal frontends, support dependency checking and resolution, and use deep desktop integration.
Additionally, tools to enhance the packaged software such as binreloc and relaytool are provided. By providing an autopackage, developers can ensure their users always have an easy way of installing the latest release of their software.
autopackage is stable, tested software that has been deployed by high profile projects. It has a strong commitment to backwards compatibility: your packages will continue to install as we add new features, although you may need to recompile them to get the new functionality.
Version 1.0 can build, install, verify and uninstall fairly complex packages (mplayer, gaim, inkscape etc), and promises backwards compatibility from this point forward.
Autopackage can resolve dependencies either from local files or from remote servers. It currently has simple support for package updates. It does not support integration with the native package manager although these features are planned for after the 1.0 release.
Main features:
- Build packages that will install on many different distros
- Multiple front ends: best is automatically chosen so GUI users get a graphical front end, and command line users get a text based interface
- Multiple language support (both in tools and for your own packages)
- Automatically verifies and resolves dependencies no matter how the software was installed. This means you dont have to use autopackage for all your software, or even any of it, for packages to succesfully install.
Enhancements:
- KDE not finding the hidden .desktop that associates x-autopackage -> autopackage-launcher-gtk on Fedora Core 3/KDE 3.3 - change Category to Categories in autopackage-launcher-gtk.desktop
- Package did not install with apkg-installer after executing .package with -d function stripDupedItems was updated to pass unit test autopackage RPM requires autopackage-gtk RPM function safeSed mishandled language detection for in-place editing
- Two desktop files were being generated - not correctly detecting if the Gnome version installed supports XDG .desktop locations
- Working directories were not being deleted makepackage checks for sealed packages not being included