Free gimp 2.6.6 software for linux

GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME.
GLib2 provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system.
Whats New in 2.6.6 Release:
- Fix several bugs with the handling of comments in key files [Mikael Magnusson]
- Fix g_atomic_pointer_compare_and_exchange on Sparc64 [Gert Doering]
- Fix a deadlock with threadpools [Hong Jen Yee]
- Make GLib work on BeOS again [Kian Duffy]
- Win32 bug fixes [Kazuki Iwamoto]
- Other bug fixes [Roger Leigh, Kjartan Maraas, Morten Welinder]
- New and updated translations (bg,cs,cy,de, en_CA,es,et,fr,gu,hu,ja,ko,nl,sq,sr,sr Latn,sv, te,zh_CN,zh_TW)

gimpShop project is a fork of GIMP which changes the layout of the user interface to resemble Adobe Photoshop.
Version 2.2 is an update on GIMP 2.0. GIMP 2.2 is fully backward compatible to GIMP 2.0. Plug-ins and scripts written for GIMP 2.0 will continue to work and dont need to be changed nor recompiled to be used with GIMP 2.2. We do however hope that plug-in authors will update their plug-ins for GIMP 2.2 and adapt the GUI changes we did with this version.
GIMP 2.2 replaces GIMP 2.0. It is advised that you uninstall GIMP 2.0 before installing GIMP 2.2. If you want to keep GIMP 2.0 installed in parallel to GIMP 2.2, you have to choose a separate prefix which is not in your default library search path.
This code has already seen quite some testing but a lot has changed since version GIMP 2.0 and we could very well have introduced new bugs. If you find any , make sure you report them at bugzilla.gnome.org (after checking that it isnt reported already).
The GIMP 2.2 API is guaranteed to be backward compatible (source and binary) with the GIMP 2.0 API. If you find that your 2.0 plug-in break when used with the GIMP 2.2 libraries, or if you cannot compile a GIMP 2.0 plug-in against the GIMP 2.2 header files, please report that as a
bug.
Enhancements:
- Keeping up with GIMP releases.

GIMP# is an API wrapper around GIMP, written in C#. However, its not just a wrapper. GIMP# project also adds a thin layer which adds C# specific features, like iterating through a collection. An example of this is an iteration through the guides of an image. In C# this looks like:

foreach (Guide guide in image.Guides)
{
// Do something
}

In C this would have been:

gint32 guide_ID = 0:
while ((guide_ID = gimp_image_find_next_guide(image_ID, guide_ID)) != 0)
{
// Do something
}

GIMP# also offers a base plug-in class which does the difficult stuff for you. Implementing a new plug-in is just a matter of overriding a few virtual methods. See the samples directory for examples of how to do this.

Gimp# fills the niche between scripting languages (easy to write, slow) and C (harder to write, fast). If you need a quick and dirty plug-in where speed doesnt matter that much, write it in any of the scripting languages that come with GIMP (Scheme, Perl, etc.). Scripting languages are very well fitted for calling existing functionality, shortening manual tasks.

You probably dont want pixel manipulation in Scheme. In C, on the other hand, it takes a lot more time to create a plug-in for several reasons: building the GUI is time consuming. Secondly, pixel handling is not completely trivial. You have to know how to traverse through the tiles of an image, etc. Typically the actual algorithm is only a very small (5 - 20 %) part of the total code. Gimp# is not as fast as C, but much faster than a scripting language. Building a decent GUI is much easier than in C.

Glame is a multi-track wave-editor with synthesis capabilities.

Glame is targeted to be the GIMP for audio processing. Glame supports non destructive multitrack editing, recording and mixing; realtime effects using native or LADSPA plugins; OSS, ALSA or SGI audio and WAV, Mp3 and Ogg file formats.

Gimp::UI is a "simulation of libgimpui", and more!

Due to the braindamaged (read: "unusable") libgimpui API, I had to reimplement all of it in perl.

$option_menu = new Gimp::UI::ImageMenu
$option_menu = new Gimp::UI::LayerMenu
$option_menu = new Gimp::UI::ChannelMenu
$option_menu = new Gimp::UI::DrawableMenu (constraint_func, active_element, var);

$button = new Gimp::UI::PatternSelect;
$button = new Gimp::UI::BrushSelect;
$button = new Gimp::UI::GradientSelect;

$button = new Gimp::UI::ColorSelectButton;

Gimp::OO is a Perl module with pseudo-OO for Gimp functions.

SYNOPSIS

use Gimp; # Gimp::OO is now part of Gimp.

As you might have noticed, you can sort most gimp functions fall into three groups, depending on the name-prefix: gimp_, plug_in_, extension_ etc..

Whats more, there are functions groups like gimp_image_ or gimp_selection_, operating on a common object, Images and Selection in this case.

If you only had the plain syntax, your scripts would quickly aquire the "vertical gimp syndrome":

gimp_palette_set_foreground(...)
gimp_layer_new(...)
gimp_palette_set_background(...)
gimp_image_add_layer(...)

etc. Of course, your fingers will suffer from severe injuries as well.

A solution to this situation is to use OO-syntax. Gimp plays some (very) dirty tricks and provides a number of classes, like Gimp::Image and Gimp::Palette that allow shorter identifiers to be used (all these appear with the Gimp:: prefix as well as without, i.e. Gimp::Palette is the same class as Palette).

If you call a method, Gimp tries to find a gimp function by prepending a number of prefixes until it finds a valid function:

$image = Gimp->image_new(...); # calls gimp_image_new(...)
$image = Image->new(...); # calls gimp_image_new as well
$image = new Image(...); # the same in green
Palette->set_foreground(...) # calls gimp_palette_set_foreground(..)

Return values from functions are automatically blessed (through The Magic Autobless feature ;) to their corresponding classes, i.e.

$image = new Image(...); # $image is now blessed to Gimp::Image
$image->height; # calls gimp_image_height($image)
$image->flatten; # likewise gimp_flatten($image)
$image->histogram(...); # calls gimp_histogram($image,...), since
# gimp_image_histogram does not exist
The class argument ($image in the above examples) is prepended to the argument list.

Another shortcut: many functions want a (redundant) image argument, like

$image->shear ($layer, ...)

Since all you want is to shear the $layer, not the $image, this is confusing as well. In cases like this, Gimp allows you to write:

$layer->shear (...)

And automatically infers the additional IMAGE-type argument.

As the (currently) last goodie, if the first argument is of type INT32, its name is "run_mode" and there are no other ambiguties, you can omit it, i.e. these three calls are equivalent:

plug_in_gauss_rle (RUN_NONINTERACTIVE, $image, $layer, 8, 1, 1);
plug_in_gauss_rle ($image, $layer, 8, 1, 1);
plug_in_gauss_rle ($layer, 8, 1, 1);

You can call all sorts of sensible and not-so-sensible functions, so this feature can be abused:

patterns_list Image; # will call gimp_patterns_list
quit Plugin; # will quit the Gimp, not an Plugin.

there is no image involved here whatsoever...

Gimp::Pod is a Perl module to evaluate pod documentation embedded in scripts.

SYNOPSIS

use Gimp::Pod;

$pod = new Gimp::Pod;
$text = $pod->format ();
$html = $pod->format (html);
$synopsis = $pod->section (SYNOPSIS);
$author = $pod->author;
@sections = $pod->sections;

Gimp::Pod can be used to find and parse embedded pod documentation in gimp-perl scripts. At the moment only the formatted text can be fetched, future versions might have more interesting features.