Free be seen software for linux

GTK See is a simple image viewer based on GTK+ 1.2.x and running on X Window System. The appearance and interface are similar to popular image viewer ACDSee, that is where the name "GTK See" come from.
Its confirmed by users that GTK See work fine in these platforms:
- Slackware (intel) 3.4, 3.5, 4.0, 8.x, 9.x, 10
- RedHat (intel) 5.1, 5.2, 9.0
- ASP Linux (athlon k7) 9.2
- Solaris (sparc) 2.6, 9
- Debian (intel) 2.0
- Digital Unix V4.0(alpha)
- FreeBSD (intel) 2.2.1, 2.2.7, 3.0
- HP-UX
- TurboLinux 3.0.2c
GTK See is distributed under the GNU Public License.

Kobo Deluxe is a port of XKobo to SDL, with considerable enhancements.
Kobo Deluxe is a port of XKobo to SDL. XKobo itself is a descendant of Namcos old Bosconian, which can be seen as part of the Galaxian/Galaga family of space shooters.
In both XKobo and Kobo Deluxe, you fly a ship around in 2D space, destroying other ships, dodging bullets, and destroying massive space platforms by shooting their cores.
There are literally hundreds of levels, and each level is different every time you play--the platforms are randomly generated. Kobo Deluxe adds sound, better graphics, and much more to the original game.
Main features:
- Fast paced retro arcade style game play
- Smooth, high speed 8-way scrolling
- Very simple controls - the game is about speed and strategy
- 17 different enemies; fighters, kamikaze attackers, proxy bombs and more
- 50 maps, each with its own feel and strategies to figure out
- Maps are built as you enter them - each game is unique!
- Beat the 50 maps - and get a new wave of even more aggressive enemies
- Music and sound effects with real time reverberation
- Structured audio technology - hi-fi sound in a tiny download
- OpenGL support for extremely fast and smooth animation
- High resolution support up to 2048x1536 - five types of scaling
- Supports any display color depth - dithering for 15 and 16 bpp
- Supports control by keyboard, mouse or joystick
- Runs on pretty much any hardware and operating system
- All code and data is Free! Source code available. (GPL or LGPL)

JavaDesktopEngines aim is to produce a piece of software that is at the same time:
Shared virtual machine
It allows to launch different java programs inside the same VM. The VM will always be alive, so no more startup overhead and less memory used.
It uses our JDSVM(Java Desktop Shared Virtual Machine), which in turn is based on Javagroups great Echidna Project
Xml Rpc local server
This way it is possible for programs, even written in languages different from java, to access "services" exposed by the engine.
Plugin host
It has been built with a pluggable architecture in mind, so that it is possible to develop new "services" for the engine.
Linux/Windows service (next release)
It is run as a service, so that its "services" will always be available for other programs.
For those of us who make heavy use of java tools its always been quite frustrating to have to open lots of resource eager VMs just to launch very useful but simple programs. Moreover, VM starting for simple utilities is a real waste of time.
Weve all appreciated the difference when launching a compilation from inside an IDE. In this case javac is launched as a process inside an already active VM, and the difference is evident.
JDE in the beginning was born to try to address these problems. Having an always active VM where it is possible to launch processes in, means faster process start and less resources used. A lot of time is saved by from not loading again and again the VM.
Theres nothing new in this. Some very good related projects are alive and kicking on the net, some of them focusing on a complete Java desktop enviroment, some on just a shared VM. JDE positions itself a bit differently, as it can be seen as a java engine exposing pluggable services (shared VM being just one of these).
There are several approaches to implementing a shared VM, all of them with pros and cons. Weve chosen to use the great code from the Echidna Project for now.
The entrypoint of JDE is an XML-RPC server accepting calls for services. Everything needed from JDE can be obtained by making a call to it.
The main service exposed by JDE is obviously the java process launching one. By making a call, it is possible to launch a java process insisde the VM. Having an XML-RPC server allows us to use any language with xmlrpc capabilities to launch java programs. The package includes a simple python script, that can be easily used as launcher (see our simple tutorial for details).
Included is also a "Manager", a simple swing application with active process listing and process launching capabilities.
Hopefully, this one will evolve as far as there will be more services in JDE to be the reference manager for the engine.
Included plugins:
1) Java process Launcher. The one this project was started for. You can launch java processes inside the living VM.
2) Scripting engine. Via a simple xmlrpc call you can launch a script on the engine and get back results. The nice thing, as usual, is that being xmlrpc based, you can use it as a service called by anything written in any language. Currently supported scripting language is BeanShell. More will be available soon via BSF.
3) Fast editor Based on jEdit Syntax Package 2.2.1, a simple, fast and useful editor with only some of the nice features jEdit has got us used to.
Enhancements:
- This release should be a bit more robust when killing processes that make use of System.exit(0) without "dispose()".
- An icon for the GUI manager has been added, as well as a bat file for Windows systems.

Sauerbraten is an experimental engine based on Cube, can be seen as "Next-Gen Cube", or "Cube 2". Much like cube, the aim of this engine is not to produce the most eyecandy possible, but rather allow map/geometry editing to be done dynamically in-game, and make map editing a lot of fun.

Sauerbraten has an even simpler world model than cube (fewer exceptions, just one kind of building block), is quicker to edit geometry with, yet allows for significantly greater class of shapes. One way to see the transition from Cube to Sauerbraten is to say Cube was a 2-directional heightfield (floor and ceiling), and Sauerbraten is a 6-directional heighfield (heighfields can be modeled in all 6 directions).

The world consists of an octree of deformable cubes. It being an octree has just one important effect: it allows the mapper to work at any scale, from large landscape areas to small architectural details. The octree is largely invisible to the mapper though, he can arbitrarily break up larger cubes or merge them, and the engine takes care of the rest.

The deformable cubes are geometric shapes made out of maximally 8 vertices. In its maximum size, it is a regular cube that fills the entire octree node it sits in, as minimum size all 8 vertices coincide which is to say the cube is "empty". Anywhere in between theres a variety of slanted cubes and wedge shapes that are possible to any degree and orientation, and together with neighbouring cubes can form any shape easily.

The editor is similar to the one in Cube but much easier / direct to use, as there arent all the different kinds of cubes to worry about. Here, you can simply "push and pull" geometry with your mousewheel in 6 directions, depending on the orientation of the surface you are looking at. Modifier keys allow you to influence single vertices on a cube, connected vertices touching multiple cubes, edges, faces and entire cubes. Selections can be made to operate on more primitives at once. Many complex shapes are quick and easy to make. It is definitely the most fun way to model architecture to date.

The internal representation of a deformable cube is very different from a vertex based representation, and is based on "edge spans" which allows the engine to represent any kind of shape uniformly in just 12 bytes. This means it can hold great amounts of geometry in memory and maps on disk are small. To render this kind of geometry, the engine goes through a process of converting the internal representation to vertices using plane intersections based on the edge ranges, culls coinciding faces, merges vertices etc. to arrive at something which renders efficiently by hardware and caches this in chunks based on the octree. This allows Sauerbraten a significantly higher polygon throughput than Cube while maintaining its ability to have dynamic geometry.

The current implementation inherents all the non-world geometry related code from Cube, and as such works without modification: entities, AI, gameplay, network, console/script. For the new code, rendering and editing are close to done, physics and lighting are working quite well, level loading/saving is complete, SP & MP work, but plenty of more advanced stuff like occlusion culling & LOD is missing.

UPDATE: Sauerbraten has now started as a Cube community Open Source Engine (& Game) project. It interesting for developers & mappers, but maybe not players yet (though SP & MP do work). If you are interested in checking it out, or even in contributing, I suggest you visit the forums (see below).

NEWS: may 24 2005 release with lightmaps and working MP/SP gameplay! download from sourceforge below.

Hugin is a panorama tools GUI.

Goal: an easy to use cross-platform GUI for Panorama Tools.

With hugin you can assemble a mosiac of photographs into a complete immersive panorama, stitch any series of overlapping pictures and much more.

Main Window

This window consists of a toolbar that provides quick access to important functions. It also contains the Images, Lens, Control Point, Optimizer and Panorama Tab, which will be explained below.

Images Tab

Images can either be added with the Add button, or via drag and drop. To change the orientation of one or more images, select them in the list on the left. The image will be show in the preview area, and its orientation (yaw, pitch and roll values) can be edited on the left.

It is possible to select multiple images at the same time. Changes in orientation will be applied to all selected images

Lens Tab

The lens tab looks a lot like the Images tab, except that the lens settings can be edited here. As in the Images Tab, multiselection can be used to change the parameters for multiple images.

Currently only one lens is supported. The idea is that the Lens describes the process that was used to create the image. The most important parameters are the Lens type and the HFOV (Horizontal Field of View). Hugin will read the EXIF information in jpg files created by digital cameras, so usually it is filled out correctly.

Photographers do not use a HFOV in degrees, but the focal length. The focal length can be entered and it will be converted to HFOV in degrees, like the panorama tool require it. The focal length entered is taken to be for 35 mm film cameras.

Usually images are more or less distorted. This can be seen especially if there are long straight lines close to the image border, which are usually not completely straight but bent a little. The a b and c parameters are used to remove that distortion. They are applied radially from the image center, which can be moved by changing the d and e parameters.

During image capture, it is possible that the parameters vary, that is are not the same for each image. This can have many reasons, one of the could be a scanner that cuts a way a few pixel more at one side than the other. Other parameters stay the same, like usually the a,b and c parameters (if the zoom and focus for the images is the same).

The inherit checkmark means that this parameter doesnt vary between the images that were captures with that lens setting. If a parameter is inheritied it is forced to be the same for all images. When inherited parameters are optimized they are kept the same for all images, whereas parameters that are not inherited can get values specific for a single picture.

Control Point Tab

Control Points are probably the most important thing when using panorama tools. The Tab consists of two image displays and tab bars to switch images to be editied. The bottom contains a list view where Points can be selected and some fields to edit a selected point. Points can also be selected by clicking or dragging on them in the images. It is possible to zoom out to show the full image.

Adding a control point works by clicking into one image to select a point and then into the other image. If auto add is not set, the points can be moved by clicking at some other place in the images. They are added to the list of control points by pressing the right mouse button. If you press the right mouse button when only one point is slected, the point selection will be aborted. auto add adds the control point as soon as both points have been specified.

Control point creation is influenced by the following checkboxes:

auto fine tune hugin helps you to find the second point by looking for it in a search region (shown by a rectange around the cursor). This might not always work, but usually is reliable, if the image distortions are not too big. Try and play with it.
auto add A control point is automatically added when both points are know. You wont have time to refine the selection before adding the point.
auto estimate Tries to estimate the position of the second point by estimating the translation between the two images. This is very crude and probably only works for single row panoramas created from rectilinear images.

All these flags can be combined. I typically use auto fine tune and auto estimate at the same time. Then hugin usually automatically selects the second point correctly. Well for single row panos that is...

The images are zoomed out, the first click zooms to a temporary 100% view to give you the chance to refine your selection. Note that only the second click will trigger the auto estimate.

The Fine Tune button can be used to find a better position for the point in the right image for already selected point. Contrary to auto fine tune it only looks in a very small area around the point. This function is especially useful if you moved both points by hand, but want to have fine tuned control points.

Press the middle mouse button to pan the image. If you press shift key while paning, both images will move.

This window supports some keyboard shortcuts:

a add a new point that has been selected in both images, and the auto add is switched off.
cursor keys scroll image under the mouse cursor
shift + cursor keys scroll both images at the same time
f fine tune currently selected control point pair. Same as the Fine Tune button
Del Remove currently selected control point.
0 Zoom out to full view.
1 100% view.
Mouse function
Function
control key + mouse movement Scroll image under cursor
shift key + mouse movement Scroll both images
left button Use left mouse button to select new points or drag existing points.
right mouse button Add control point, if auto add is switched off
middle mouse button Scroll image under cursor
shift + middle mouse button Scroll both images

Optimizer Tab

The optimizer moves the images into the right position, so that they can be assembled into a hopefully seamless panorama.

To select what the optimiser should try to estimate, use the Optimize combo box, then click the Optimize Button. If you select the "custom" setting, you can change

Pano Panel

Options concerning the output panorama can be set here.

Ogg::Vorbis::Header is an object-oriented interface to Ogg Vorbis information and comment fields.

SYNOPSIS

use Ogg::Vorbis::Header;
my $ogg = Ogg::Vorbis::Header->new("song.ogg");
while (my ($k, $v) = each %{$ogg->info}) {
print "$k: $vn";
}
foreach my $com ($ogg->comment_tags) {
print "$com: $_n" foreach $ogg->comment($com);
}
$ogg->add_comments("good", "no", "ok", "yes");
$ogg->delete_comment("ok");
$ogg->write_vorbis;

This module presents an object-oriented interface to Ogg Vorbis files which allows user to view Vorbis info and comments and to modify or add comments.

CONSTRUCTORS

new ($filename)

Partially opens an Ogg Vorbis file to ensure it exists and is actually a Vorbis stream. It then closes the filehandle. It does not fill in the objects data fields. These fields will be automatically filled the first time they are accessed using the objects instance methods. Returns undef if there is a problem opening the file or the file is not valid Ogg Vorbis.

load ([$filename])

Opens an Ogg Vorbis file, reads its information, and then closes the filehandle. Returns undef if there is a problem opening the file or the file is not valid Ogg Vorbis. This is both a constructor and an instance method. The filename is required in constructor context, but should be left out when you call this as an instance method on an object. When called as an instance method, it (re)loads the info and comment data from the file. This can be used to reset the state of the object if write_vorbis hasnt been called. Note that the path parameter is ignored in instance context.

INSTANCE METHODS

These methods may be called on actual Header objects, using the -> operator or indirect objects as you prefer.

info ([$key])

Returns a reference to a hash containing format information about the Vorbis file. Hash fields are: version, channels, rate, bitrate_upper, bitrate_nominal, bitrate_lower, and bitrate_window, length. The bitrate_window value is currently unused by the vorbis codec. You can modify the referenced hash if you want, but I wouldnt suggest it.

The optional key parameter allows you to extract a single value from the internal hash (passed by value, not reference). If the key is invalid, undef is returned.

comment_tags ()

Returns an array holding the key values of each comment field. You can then use these values to access specific fields using comment. This may seem somewhat clunky at first but it will speed up most programs. In addition, it makes it easier to support the Ogg Vorbis comment standard which allows multiple fields with the same key.

comment ($key)

Returns a list of comments given a key. If the key does not exist, returns undef.

add_comments ($key, $value, [$key, $value, ...])

Adds comments with the given keys and values. Takes an array of alternating keys and values as parameters. Keys and values should be valid ascii in the range 0x20 - 0x7D and the key should exclude 0x3D (=). This is a subset of the Vorbis standard which allows this range for the key field and all of utf8 for the value field. This will be fixed in future a release.

If an odd-length array is passed in the routine will fail and return undef. Key and value will be trimmed of characters which do not match the format requirement.

edit_comment ($key, $value, [$num])

Edits a given comment field. The optional num field is used to differentiate between two comments with the same key. If no num is supplied, the first value--as reported by comment--is modified. If the key or num are invalid, nothing is done and undef is returned. If all goes well, the old value is returned.

delete_comment ($key, [$num])

Deletes the comment given by key. The optional num value can be used to specify which comment to delete, given duplicate keys. Leaving num out will result in only the first instance being deleted. Returns undef if key or num are invalid. If all goes well, the value of the deleted comment is returned.

clear_comments ([@keys])

Deletes all of the comments which match keys in the input array or all of the comments in the stream if called with no arguments. Returns undef if any key is invalid, although all keys in the input array up until that key will be cleared. Returns true otherwise.

write_vorbis ()

Write object to its backing file. No comment modifications will be seen in the file until this operation is performed.

path ()

Returns the path/filename of the file the object represents.

Yet Another Dynamic Engine (YADE) is an extensible framework that is designed with dynamic libraries in a way that it is easy to add new numerical models and objects.
There are four different models: Discrete Element Method based on spheres, a second method based on tetrahedra, modelling with lattice elements, and Finite Element Method.
Various different methods and algorithms for numerical simulation currently exist. Yade tries to extract their underlying abstractions using following examples:
- Finite Element Method (FEM, [2]),
- Discrete Element Method (DEM),
- Coupling FEM with DEM,
- Mass Spring System,
- Lattice Beam Model,
- Tetrahedron Discrete Model.
Those abstractions are implemented in C++ conforming to Object Oriented design principles. They provide interface to plug-in different modelling methods.
Yade framework is intended to work with other numerical methods than those mentioned above.
Advantages:
- allows numerous simulation methods in the single framework, so coupling them becomes possible,
- plugins can import data from other software,
- thoughtful code design promotes code reuse and improvement,
- open source development model allows community feedback.
Disadvantages:
- implementing models requires adhering to framework design,
- Yade framework is a new emerging software, still in beta phase.
- if you know more disadvantages, let us know!
Enhancements:
- This release has major improvements in the code, and directory cleanup was done.
- The build system was changed from qmake to scons.
- A complete Lattice Geometrical Model was added as a result of PhD defense by one of yades authors.
- Several improvements in Discrete Element Method, capillary law, and triaxial test.
- Among smaller improvements, it is possible to select bodies by clicking them and moving around with the mouse.
- Interaction forces are drawn between bodies, and can be seen as bars with strength related to bar thinckness.

makepp_statements Perl package contains various statements in a makefile.

and, build_cache, "build_check", define, else, enddef, endef, endif, "export", global, ifdef, "ifeq", "ifmakeperl", ifndef, ifneq, ifnsys, "ifperl", "ifsys", "include", "_include", load_makefile, make, perl, "makesub", no_implicit_load, or, perl, "perl_begin", perl_end, "prebuild", register_scanner, "register_command_parser", "register_input_suffix", repository, "runtime", signature, "sub"

A statement is any line beginning with a word which does not have a : in it. (A colon implies that the line is a rule.) For example, these are statements:

include extra_rules.mk
load_makefile subdir

Makepp has a number of builtin statements which you may occasionally need to use.

Note that wherever you see an underscore, you may also use a dash, because makepp converts dashes to underscores in statement names.

Conditionals

Conditionals are special statements, which control what lines of the Makeppfile are actually seen. The simplest form (where ifxxx stands for any of the conditional statements documented below) is:

ifxxx ...
lines seen if the statement evaluates as true
endif

or:

ifxxx ...
lines seen if the statement evaluates as true
else
lines seen if the statement evaluates as false
endif

There is also the possibility to do complex combinations like this:

ifxxx ...
and ifxxx ...
and ifxxx ...
or ifxxx ...
and ifxxx ...
lines seen if the combined statements evaluate as true
else ifxxx ...
or ifxxx ...
and ifxxx ...
lines seen if the first combination evaluates as false
and these combined statements evaluate as true
else
lines seen if the statements above evaluate as false
endif

As is suggested by the indentation, and has higher precedence than or. In other words an or elects between two groups of and`s. There may be any number of and ifxxx`s, or ifxxx`s and else ifxxx`s.