Free not part software for linux

Kexi Report Part is a reporting component for Kexi 1.6 based on OpenRPT 1.2.
Main features:
- A report viewer for Kexi
- An external report designer (KexiReportWriter) based on the OpenRPT writer program
Known Working Features
- Page Header
- Page Footer
- Report Header
- Report Footer
- Detail section
- Labels
- Lines
- Fields
- Page Browser
How To Create Report
1. Install the component following the instructions in INSTALL
2. Run KexiReportWriter to start designing a report
3. Select Database->Connect to DB
4. Browse to an existing Kexi Database and open it
5. Create a new report (File->New)
6. Assign a data source to the report (Document->Properties)
7. Create the report using labels/fields/lines
8. Assign columns to the field objects (Double click for properties)
9. Save the report. (Database->Save to DB)
10. Load the database in Kexi and double click the report to view it
Enhancements:
- Removed requirement to have kexi source available to install the plugin.Done this by including the needed kexi headers in the package. Only downside is that kexi 1.1.3 (from koffice 1.6.3) is required.

GNU 3DKit is a platform independent rendering architecture based on OpenGL, written in ObjC.

GNU 3DKit is part of the GNUstep environment, which provides an object-oriented application development framework and tool set.

Parted Magic is a ~30mb LiveCD/USB with its only purpose being partitioning hard drives. Although GParted and Parted are the main programs, the CD/USB also offers programs like partimage, testdisk, fdisk, sfdisk, dd, etc...
Parted Magic is based on my work from the GParted LiveCD project and falls under the terms of the GPL.
Enhancements:
- We added dd_rhelp, sdparm, mbr, and xfburn for starters. Updated programs: linux-2.6.22, e2fsprogs-1.40.2, ntfs-3g-1.710, dd_rescue-1.13, ddrescue-1.5, leafpad-0.8.11, file-4.21, testdisk-6.7, mdadm-2.6.1, pciutils-2.2.5, syslinux-3.51, isomaster-1.0, hdparm-7.4, xfsprogs_2.8.21-1, busybox-1.5.1, and usbutils-0.72. All menus are bypassed now. After the syslinux menu, it boots to the desktop without any other interruptions. You can now create the LiveUSB from the LiveCD by using our new USB Operations program...

Red Carpet is a software management tool for RPM-based Linux distros.

Red Carpet is a suite of applications that allows easy installation and update of software on Linux systems. Red Carpet project features both command-line and graphical GNOME interfaces.

These days Red Carpet is part of the Novell ZenWorks solution.

Not A Commander is yet another file manager modeled after the Norton Commander. Good integration with the command line is the primary goal.
This project is using the technology of Natural Stupidity for development: first get something working at all, then gradually improve it. My primary targets are the features that I personally would use. The features that I wont use anyway are not planned to be implemented at all (though if someone would contribute an implementation I would gladly accept it - as long as it does not break any of the things that I use).
Build
Run `make. That should build all the binary parts. The X11 headers are required for build. You may need to modify the Makefile for peculiarities of your particular system (directory names, libraries etc.).
Installation
Run `make install. By default the `nac binary is instaled into /usr/local/bin and the rest of files is installed into /usr/local/lib/nac (which is referred further as "the NAC directory").
These directory names can be changed in the Makefile. If the configuration file nac.sysrc was present in the NAC directory before installation, it will be moved into nac.sysrc.old.
Configuration
The default configuration of NAC can be changed with rc files. There are two rc files:
per system - nac.sysrc in the NAC directory per user - .nacrc in the users home directory
These files are common Tcl scripts that can be used to change the tunable values. NAC first sets the built-in values, then loads the system-wide rc file (if present), then loads the users rc file (if present). Thus the system-wide script can examine the built-in values and modify them was neccessary, and the users script can do the same thing with the result
of the system-wide script.
Be careful with the syntax, in case of an error in the rc scripts NAC wont start.
The list of the supported tunables and their values can be found at the top of tune.tcl. For now (the alpha phase of development) its expected to be quite liquid and change between snapshot releases. Probably some sort of versioning will be added after it stabilizes.
The sample system rc file included in a release contains only one setting - the name of font to use (most probably you dont have the font "koi9x16" which is the built-in default).
The default initial size of the window is defined by panel dimensions, variables named set panel:filespercolumn (number of rows in panels), panel:ncolumns (number of columns in panels), panel:columnwidth (width of a column in dots). The internal xterm is automatically resized to fit these dimensions. Alternative size in pixels or xterm characters can be
selected with command line options.
Enhancements:
- Various bugs were fixed and workarounds were included for bugs in glibc and Tk.

XML::NodeFilter is a generic XML::NodeFilter Class.

SYNOPSIS

use XML::NodeFilter;

my $filter = XML::NodeFilter->new();

$your_iterator->set_filter( $filter );

"Filters are objects that know how to "filter out" nodes. If a NodeIterator or a TreeWalker is given a NodeFilter, it applies the filter before it returns the next node. If the filter says to accept the node, the traversal logic returns it; otherwise, traversal looks for the next node and pretends that the node was rejected was not there."

This definition is given by the DOM Traversal and Range Specification. It explains pretty well, what this class is for: A XML::NodeFilter will recieve a node from a traversal object, such as XML::LibXML::Iterator is one and tells if the given node should be returned to the caller or not.
Although I refere only to XML::LibXML here, XML::NodeFilter is implemented more open, so it can be used with other DOM implementations as well.

The Spec And The Implementation

The DOM Traversal and Range Specification just defines the contstants and accept_node() for a node filter. The XML::NodeFilter implementation also adds the what_to_show() function to the class definition, since I think that it is a filters job to decide which node-types should be shown and which not.

Also XML::NodeFilter adds two constants which are not part of the specification. The first one is FILTER_DECLINED. It tells the traversal logic, that it should apply another filter in order to decide if the node should be visible or not. While the spec only defines the traversal logic to have either one or no filter applied, it showed that it leads to cleaner code if more filter could be used in conjunktion. If a traversal logic finds a single filter that returns FILTER_DECLINED, it should be handled as a synonym of FILTER_ACCEPT. While FILTER_ACCEPT is finite and would cause all other not to be executed, FILTER_DECLINED gives one more flexibility.

The second extension of the specification is the SHOW_NONE symbol. It was added for operational completeness, so one can explicitly switch the node type filter off (means all node types are rejected). This will cause the two calls of what_to_show have a different result:

$filter->what_to_show( undef ); # will set SHOW_ALL
$filter->what_to_show( SHOW_NONE ); # will not set SHOW_ALL

Infact SHOW_NONE is a NULL flag, that means it can be added to any list of flags without altering it.

$filter->what_to_show( SHOW_ELEMENT | SHOW_TEXT | SHOW_NONE );

is therefore identical to

$filter->what_to_show( SHOW_ELEMENT | SHOW_TEXT );

SHOW_NONE is espacially usefull to avoid numerically or even more ugly unintialized values while building such flag lists dynamically.

Apparix combines the properties of the cdargs utility and the CDPATH shell mechanism for fast navigation through the file system.
Apparix is especially useful for visiting and documenting both often- and rarely-used locations. Apparix enables you to attach marks to locations and jump to those locations by loading the mark.
Marking, unmarking and jumping are simple operations that are performed in the current shell. By setting up convenient aliases for marking and jumping the file system can be navigated in a fast and intuitive manner.
This section contains some examples of the most common uses of apparix. OPTIONS contains a list of additional options available for pruning and squashing bookmarks.
NOTES features a brief discussion of the advantages of apparix over other approaches such as setting up aliases for often visited directories, using symlinks, CDPATH, or a combination of these. HISTORY explains the difference between cdargs and apparix.
Apparix works in a manner very similar to cdargs. One usually invokes apparix by using pre-defined aliases. Here they will be called bm for bookmark, portal for a CPPATH-style bookmark and to for initiating an apparition (aka jump) . These aliases are found below in the FILES section and can also be obtained by issuing
apparix --shell-examples
Apparix works by aliases for two reasons, necessity and convenience. When bookmarking, it is convenient to be able to do it with just a few keystrokes. When jumping, apparix cannot change the current directory in the current shell. It writes the result destination in a results file $HOME/.apparixresult - necessity. An alias or function with a conveniently short name such as to achieves the desired change of directory.
Suppose your user name is eez and your home directory is /home/eez. You often visit a directory called /home/eez/cvs/xyz/tfa/faq/zut/bar/foo. This is how to create and use a bookmark for foo
/home/eez/cvs/xyz/tfa/faq/zut/bar/foo> bm foo
added: foo -> /home/eez/cvs/xyz/tfa/faq/zut/bar/foo
/home/eez/cvs/xyz/tfa/faq/zut/bar/foo> cd
/home/eez> to foo
/home/eez/cvs/xyz/tfa/faq/zut/bar/foo>
Another scenario is where you have some directory that contains a largish number of subdirectories, all of which you would like to have bookmarked. If the subdirectories have distinctive names this can be achieved in one fell swoop by marking the parent directory as a portal.
This is identical to adding the parent directory to the CDPATH environment variable, except that apparix bookmarks are not part of the cd namespace. It is argued in NOTES that this is a good thing. Consider this.
/home/cvs/bagger/boemel/mcl/mcl/src> ls
alien/ CVS/ impala/ Makefile.am README shmcx/
attic/ giraffe/ lib/ Makefile.in shcl/ shmx/
contrib/ gmon.out Makefile mcl/ shmcl/ taurus/
Some of the subdirectories have not-so-distinct names such as contrib and attic, but they happen to be the directories least visited. Issuing
/home/cvs/bagger/boemel/mcl/mcl/src> portal
[apparix] expanded 1 portal to 12 destinations
yields all of the subdirectories as destinations bookmarked by the last component of their path name. Note that bookmarks resulting from portal expansion are kept in a separate resource file (see FILES). Portal expansions can be recreated by issuing
apparix --rehash
This is useful to reflect a change in the directory naming structure underneath a portal.
Conflict resolution
Apparix allows identical bookmarks to point to different locations. When asked to visit such a bookmark it will present a list of options.
Subdirectory specification
When jumping (apparating) you can specify an additional subdirectory after the bookmark. Apparix will append the subdirectory to the destination. This does require you know the exact name of the subdirectory you want to visit.
Enhancements:
- Subdirectories can be excluded from portal expansions by appropriately setting the environment variable APPARIXEXCLUDE.
- Apparix is now licensed under the GNU General Public License version 3.