Free build standalone applications software for linux

SOPE Application Server is an extensive set of frameworks (16 frameworks, ~1500 classes) which form a complete Web application server environment.
Besides the Apple WebObjects compatible appserver extended with Zope concepts, it contains a large set of reusable classes: XML processing (SAX2, DOM, XML-RPC), MIME/IMAP4 processing, LDAP connectivity, RDBMS connectivity, and iCalendar parsing.
The individual frameworks of the package can be used standalone (for example in Cocoa applications) and do not require the application server itself.
For MacOSX developers, the package includes SOPE:X, which contains special Xcode and Cocoa support for SOPE.
Enhancements:
- This release fixes a set of minor bugs.
- It improves the vCard parser, the IMAP4 client library, the MySQL adaptor, and BSD packaging.

ASNMTAP::Asnmtap::Applications is a Perl module that provides a nice object oriented interface for ASNMTAP Applications.

ASNMTAP::Asnmtap::Applications Subclass of ASNMTAP::Asnmtap

This version is still the old ASNMTAP Applications v3.000.001 addapted for using with the new ASNMTAP::Asnmtap, ASNMTAP::Asnmtap::Plugins and ASNMTAP::Asnmtap::Plugins::Nagios plugins.

We are working onto an new Object Oriented version for the ASNMTAP Applications

OpenPlugin::Application is a subclass of CGI::Application, meant to help you create reusable web applications.

SYNOPSIS

# Example from OpenThoughts Demo.pm

package Demo;
use base "OpenPlugin::Application";
sub setup {
my $self = shift;
$self->run_modes(
mode1 => init_demo,
mode2 => get_os_list,
mode3 => get_os_info,
);
$self->start_mode( mode1 );
$self->mode_param(run_mode);
}
sub init_demo { ... }
sub get_os_list { ... }
sub get_os_info { ... }
1;

# Example from OpenThoughts demo.pl

#!/usr/bin/perl -wT
use strict;
my $r = shift;
my $demo = Demo->new( PARAMS => {
config => { src => "/path/to/OpenPlugin.conf" },
request => { apache => $r },
});

$demo->run();

OpenPlugin::Application is built on Jesse Erlbaums popular CGI::Application module. OpenPlugin::Application is simply a subclass of CGI::Application. Jesse says the following about CGI::Application:

"CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve."

How does it do this? Jesse goes on to say:

"The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of "Run-Modes." Each Run-Mode is roughly analogous to a single screen (a form, some output, etc.). All the Run-Modes are managed by a single "Application Module" which is a Perl module. In your web servers document space there is an "Instance Script" which is called by the web server"

The biggest difference between CGI::Application and OpenPlugin::Application is that query object they both use; one is designed to use CGI.pm, the other OpenPlugin. Generally speaking, everything in the still applies. Any differences will be noted in this document.
It is not necessary to use OpenPlugin::Application in order to build web applications using OpenPlugin. This plugin is meant to be for your convenience -- to help you structure your web applications in a manner which makes sense, and is reusable.

Virtual Appliances are nano-sized virtual machines with Web user interfaces for deploying instant infrastructure and applications. They are Gentoo Linux based and optimized for use in VMware and Xen.
Virtual Appliances are free to download and use, and you can choose from a simple Web server, an Apache Tomcat server, a MySQL server, and a PostgreSQL server.
Enhancements:
- This Virtual Appliance server runs Cacti, which is a network graphing solution based on RDDTool.
- It is used to provide real-time and historical visualization of network activities.
- The Cacti Server includes onboard MySQL and PHPmyAdmin in a 40MB download package to run under any VMWare product or VirtualPC.
- As with other Virtual Appliances, this Cacti Server can use Virtual Hard drives automatically, which allows for a database of any practical size.

CGI::Application::Generator is a Perl module with dynamically build CGI::Application modules.

SYNOPSIS

use CGI::Application::Generator;

# Required methods
my $cat = CGI::Application::Generator->new();
$cat->package_name(My::Widget::Browser);
$cat->start_mode(list_widgets);
$cat->run_modes(qw/
list_widgets
add_widget
insert_widget
edit_widget
update_widget
delete_widget
/);


# Optional methods
$cat->base_module(My::CGI::Application);
$cat->use_modules(qw/My::DBICreds My::Utilities/);
$cat->new_dbh_method(My::DBICreds->new_dbh());
$cat->tmpl_path(Path/To/My/Templates/);


# Output-related methods
$cat->app_module_tmpl(my_standard_cgiapp.tmpl);
$cat->output_app_module();

CGI::Application::Generator provides a means by which a CGI::Application module can be created from code, as opposed to being written by hand. The goal of this module is two-fold:

1. To ease the creation of new CGI::Application modules.
2. To allow standardization of CGI::Application coding
styles to be more uniformly applied.

It is also the hope of this module that Computer Assisted Software Engineering (CASE) tools will eventually emerge which will allow the development process for web-based applications to be greatly improved. These CASE tools could more easily convert visual notation (such as UML state-transition diagrams) into method calls to this module, thereby creating actual code.

Module::Build::JSAN is a Perl module to build JavaScript modules for JSAN.

SYNOPSIS

use Module::Build::JSAN;

my $build = Module::Build::JSAN->new(
module_name => Foo-Bar,
license => perl,
dist_author => Joe Developer ,
dist_abstract => Say something pithy here,
dist_version => 0.02,
keywords => [qw(Foo Bar pithyness)],
build_requires => {
Test.Simple => 0.20,
},
requires => {
JSAN => 0.10,
Baz-Quux => 0.02,
},
);

$build->create_build_script;

This is a developer aid for creating JSAN distributions. Please use the example given in the SYNOPSIS to create distributions.

Module::Build::TestReporter is a Perl module to help users report test failures.

SYNOPSIS

use Module::Build::TestReporter;
my $build = Module::Build::TestReporter->new(
# normal Module::Build code here
);

# or, in your own M::B subclass

package My::Module::Build;

use Class::Roles does => Module::Build::TestReporter;

# your code as usual

Shipping test suites with your code is a good thing, as it helps your users know that your code works as you expect on your systems and it allows you better debugging information if things break in environments where you havent yet tested your code. However, it can be tedious and tricky to convince your users to send you the appropriate failure information.

Module::Build::TestReporter extends and enhances Module::Build to collect information on test failures and the Perl environment for users to send to you. Rather than walking them through running tests in verbose mode on the phone, in IRC, or via e-mail, use this module alongside your usual Module::Build build process and it will gather this information in case of failure.

reacTIVision is an open source, cross-platform computer vision framework for the fast and robust tracking of fiducial markers in a real-time video stream. reacTIVision project was mainly designed for the rapid development of table-based tangible user interfaces.

Its tracking core is using Ross Bencinas fidtrack library which is basically a newer high-performance implementation of Enrico Costanzas original d-touch concept. This framework was developed by Martin Kaltenbrunner et.al. at the Music Technology Group, IUA, UPF in Barcelona, Spain as part of the reacTable* project, a novel electro-acoustic musical instrument with a tangible user interface.

reacTIVision is a standalone application, which sends OpenSound Control messages via a UDP network socket to any connected client application. It implements the TUIO protocol, which was specially designed for transmitting the state of tangible objects on a table surface. This framework includes a set of free example client projects for various programming languages, which serve as a base for the easy development of tangible-user interface applications.

The reacTIVision application compiles and runs under the follwing operating systems: Win32, MacOS X and Linux. Under Win32 it suports any camera with a proper WDM driver, such as USB, USB2, FireWire and DV cameras. Equally under MacOS X any such camera supported by QuickTime will work in reacTIVision. Under Linux, FireWire cameras are best supported, as well as a few Video4Linux USB cameras.

NEW: Support the reacTIVision project and buy T-Shirts, posters and other merchandise featuring the reacTIVision fiducial symbols in our web-shop! All designs on these products can be recognized and tracked by the actual reacTIVision software.

Application Handling

Before starting the reacTIVision application make sure you have a supported camera connected to your system. The application can and will not work at all without a camera. Under Win32 and MacOS X the application will ask to select and configure the camera upon startup. Under Linux the camera will be selected automatically. Once configured the application will show a video window with the current camera image in black&white.

Pressing T will show the binary tresholded image, pressing the N key will turn the display off, which reduces its CPU usage significantly!

Pressing the S key will return to the original source image. For convenience and debugging porposes hitting the R key saves a raw image frame, while hitting the B key will save an image in the BMP format.

The P pauses the image analysis completely, hitting ESC will quit the application. The F key toggles the diplay of FPS info in the titlebar. In order to produce some more verbose debugging output, hitting the V key will print the currently recognized symbols to the console.

Command Line Options

The reacTIVision application per default sends the TUIO messages to port 3333 on localhost (127.0.0.1)

In order to change these parameters you can invoke the application with the -h [ip-address] and -p [port-no] options.

reacTIVision needs a so called "tree file" in order to function properly. The default "all.trees" is included and loaded automatically. If you want to use you own tree file you can invoke the application with the -t [tree-file] option.

Optionally if you dont want to analyze the complete image - for example in a square or round table setup - the application can mask a part of the video image with a black region, which speeds up the segmentation algorithm. In order to apply this mask You can invoke the application with the -m [square,circle] option.

Applying the -h or -help option will print a usage message to the console.

Calibration and Distortion

Some tables, such as the reacTable are using a convex mirror in order to increase the area visible to the camera at a minimal distance. This mirror as well as a fish-eye lens unfortunately distort the image. reactIVision includes a correction algorithm, which corrects this distortion with the help of a so called "grid file". These grid files can be generated during a prior calibration process.

To calibrate reacTIVision invoke the application with the option: reacTIVision -c 9 -g [grid_file]

In order to use the this calibration invoke the application with: reacTIVision -g [grid_file]