Free cgi animation software for linux

GIMP Animation Package is a collection of Plug-Ins to extend the GIMP with capabilities to edit and create Animations as sequences of single frames.

Please note that gimp-gap 2.2.1 requires gimp 2.2 and glib 2.8 or higher. It is recommended to use gtk+ 2.8.

Additional Installation Notes:

This GIMP-GAP release includes sourcecode tarballs of external libraries :

- ffmpeg
- libmpeg3

Those libs are built automatically. Configuration options for those libs can be set by editing the
files:

extern_libs/configure_options_ffmpeg.txt
extern_libs/configure_options_libmpeg3.txt

Those configure_option files are read by the master .configure script

Installation:

./autogen.sh # includes the ./configure call
make
make install

GIMP is an acronym for GNU Image Manipulation Program. It is a freely distributed program for such tasks as photo retouching, image composition and image authoring.

Animation fade-loop is a plugin for GIMP that can convert an animation to make it look better when played in a continuous loop (e.g. for DVD menus).

"This plug-in copies an animation frame by frame and adds a cross-fade effect at the end so that the last frame blends seamlessly back to the first.

Note that because of the resulting overlap, the output animation is [fade_length] frames shorter than the input. The currently loaded gimp image should be the first frame of the input animation.

CGI::XMLApplication is an Object Oriented Interface for CGI Script Applications.

SYNOPSIS

use CGI::XMLApplication;

$script = new CGI::XMLApplication;
$script->setStylesheetPath( "the/path/to/the/stylesheets" );

# either this for simple scripts
$script->run();
# or if you need more control ...
$script->run(%context_hash); # or a context object

CGI::XMLApplication is a CGI application class, that intends to enable perl artists to implement CGIs that make use of XML/XSLT functionality, without taking too much care about specialized errorchecking or even care too much about XML itself. It provides the power of the XML::LibXML/ XML::LibXSLT module package for content deliverment.

As well CGI::XMLApplication is designed to support project management on code level. The class allows to split web applications into several simple parts. Through this most of the code stays simple and easy to maintain. Throughout the whole runtime of a script CGI::XMLApplication tries to keep the application stable. As well a programmer has not to bother about some of XML::LibXML/ XML::LibXSLT transformation pitfalls.

The class module extends the CGI class. While all functionality of the original CGI package is still available, it should be not such a big problem, to port existing scripts to CGI::XMLApplication, although most functions used here are the access function for client data such as param().

CGI::XMLApplication, intended to be an application class should make writing of XML enabled CGI scripts more easy. Especially because of the use of object orientated concepts, this class enables much more transparent implemententations with complex functionality compared to what is possible with standard CGI-scripts.

The main difference with common perl CGI implementation is the fact, that the client-output is not done from perl functions, but generated by an internally build XML DOM that gets processed with an XSLT stylesheet. This fact helps to remove a lot of the HTML related functions from the core code, so a script may be much easier to read, since only application relevant code is visible, while layout related information is left out (commonly in an XSLT file).
This helps to write and test a complete application faster and less layout related. The design can be appended and customized later without effecting the application code anymore.

Since the class uses the OO paradigma, it does not force anybody to implement a real life application with the complete overhead of more or less redundant code. Since most CGI-scripts are waiting for events, which is usually the code abstraction of a click of a submit button or an image, CGI::XMLApplication implements a simple event system, that allows to keep event related code as separated as possible.

Therefore final application class is not ment to have a constructor anymore. All functionality should be encapsulated into implicit or explicit event handlers. Because of a lack in Perls OO implementation the call of a superclass constructor before the current constructor call is not default behavior in Perl. For that reason I decided to have special events to enable the application to initialize correctly, excluding the danger of leaving important variables undefined. Also this forces the programmer to implement scripts more problem orientated, rather than class or content focused.

Another design aspect for CGI::XMLApplication is the strict differentiation between CODE and PRESENTATION. IMHO this, in fact being one of the major problems in traditional CGI programming. To implement this, the XML::LibXML and XML::LibXSLT modules are used by default but may be replaced easily by any other XML/XSLT capable modules. Each CGI Script should generate an XML-DOM, that can be processed with a given stylesheet.

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.

CGI::Validate is an advanced CGI form parser and type validation.

SYNOPSIS

use CGI::Validate; # GetFormData() only
use CGI::Validate qw(:standard); # Normal use
use CGI::Validate qw(:subs); # Just functions
use CGI::Validate qw(:vars); # Just exception vars

## If you dont want it to check that every requested
## element arrived you can use this. But I dont recommend it
## for most users.
$CGI::Validate::Complete = 0;

## If you dont care that some fields in the form dont
## actually match what you asked for. -I dont recommend
## this unless you REALLY know what youre doing because this
## normally meens youve got typos in your HTML and we cant
## catch them if you set this.
## $CGI::Validate::IgnoreNonMatchingFields = 1;

my $FieldOne = Default String;
my $FieldTwo = 8;
my $FieldThree = some default string;
my @FieldFour = (); ## For multi-select field
my @FieldFive = (); ## Ditto
my $EmailAddress= ;

## Try...
my $Query = GetFormData (
FieldOne=s => $FieldOne, ## Required string
FieldTwo=i => $FieldTwo, ## Required int
FieldThree => $FieldThree, ## Auto converted to the ":s" type
FieldFour=s => @FieldFour, ## Multi-select field of strings
FieldFive=f => @FieldFive, ## Multi-select field of floats
Email=e => $EmailAddress, ## Must look like an email address
) or do {
## Catch... (wouldnt you just love a case statement here?)
if (%Missing) {
die "Missing form elements: " . join ( , keys %Missing);
} elsif (%Invalid) {
die "Invalid form elements: " . join ( , keys %Invalid);
} elsif (%Blank) {
die "Blank form elements: " . join ( , keys %Blank);
} elsif (%InvalidType) {
die "Invalid data types for fields: " . join ( , keys %InvalidType);
} else {
die "GetFormData() exception: $CGI::Validate::Error";
}
};

## If you only want to check the form data, but dont want to
## have CGI::Validate set anything use this. -You still have full
## access to the data via the normal B object that is returned.

use CGI::Validate qw(CheckFormData); # not exported by default
my $Query = CheckFormData (
FieldOne=s, FieldTwo=i, FieldThree, FieldFour,
FieldFive, Email,
) or do {
... Same exceptions available as GetFormData above ...
};

## Need some of your own validation code to be used? Here is how you do it.
addExtensions (
myType => sub { $_[0] =~ /test/ },
fooBar => &fooBar,
i_modify_the_actual_data => sub {
if ($_[0] =~ /test/) { ## data validation
$_[0] = whatever; ## modify the data by alias
return 1;
} else {
return 0;
}
},
);
my $Query = GetFormData (
foo=xmyType => $foo,
bar=xfooBar => $bar,
cat=xi_modify_the_actual_data => $cat,
);


## Builtin data type checks available are:
s string # Any non-zero length value
w word # Must have at least one w char
i integer # Integer value
f float # Float value
e email # Must match m/^s*]+@[^@.]+(?:.[^@.]+)+>?s*$/
x extension # User extension type. See EXTENSIONS below.

Basicly a blending of the CGI and Getopt::Long modules, and requires the CGI module to function.

The basic concept of this module is to combine the best features of the CGI and Getopt::Long modules. The CGI module is great for parsing, building, and rebuilding forms, however it lacks any real error checking abilitys such as misspelled form input names, the data types received from them, missing values, etc. This however, is something that the Getopt::Long module is vary good at doing. So, basicly this module is a layer that collects the data using the CGI module and passes it to routines to do type validation and name consistency checks all in one clean try/catch style block.

The syntax of GetFormData() is mostly the same as the GetOptions() of Getopt::Long, with a few exceptions (namely, the handling of exceptions) . See the VALUE TYPES section for detail of the available types, and the EXCEPTIONS section for exception handling options. If given without a type, fields are assumed to be type ":s" (optional string), which is normally correct.
If successful, GetFormData() returns the CGI object that it used to parse the data incase you want to use it for anything else, and undef otherwise.

If you only want to do value type and name validation, use CheckFormData() instead with a field=type list. -See the SYNOPSIS for an example.

Mon.cgi is a CGI interface for viewing the status of a Mon service.
mon is a general-purpose scheduler and alert management tool used for monitoring service availability and triggering alerts upon failure detection. mon was designed to be open and extensible in the sense that it supports arbitrary monitoring facilities and alert methods via a common interface, all of which are easily implemented with programs in C, Perl, shell, etc., SNMP traps, and special mon traps.
mon views resource monitoring as two separate tasks: the testing of a condition, and triggering an action upon failure. mon was designed to implement the testing and action-taking tasks as separate, stand-alone programs. mon is fundamentally a scheduler which executes the monitors (each test a specific condition), and calls the appropriate alerts if the monitor fails. The decision to invoke an alert is governed by logic which offers various "squelch" features and dependencies, all of which are configurable by the user.
Monitors and alerts are not a part of the core mon server, even though the distribution comes with a handful of them to get you started. This means that if a new service needs monitoring, or if a new alert is necessary, the mon server does not need to be changed. This makes mon easily extensible.
That is from Jim Trocki who wrote mon, Im currently maintaining a web interface that works with mon which was based from Arthur K. Chans original mon.cgi.
Enhancements:
- This is the initial release of the Mon Web Interface (MWI), which is the progression of the mon.cgi Web interface.
- This interface is written entirely from scratch, with full CSS and HTML W3C complacency.
- This is an alpha release: the back end code is based on the mon.cgi tree, but the interface will have features that are currently unusable.

CGI::Application::Plugin::RateLimit is a plugin for CGI::Application which provides protection against a user calling a runmode too frequently. A typical use-case might be a contact form that sends email.

Youd like to allow your users to send you messages, but thousands of messages from a single user in a short period of time would be a problem.

Installation:

To install this module type the following:

perl Makefile.PL
make
make test
make install