Free at spi software for linux

at-spi is the Gnome Accessibility Project.

Building the documentation:

Pre-built versions of the HTML documentation are available at http://developer.gnome.org/projects/gap/tech-docs/at-spi-docs/book1.html. However the documentation in the docs directory is the most up-to-date. Building the docs requires docbook and jade, see the gtk-doc package (from Gnome CVS) for more information.

Use of the AT-SPI:

Accessible applications will register with this registry service (via bonobo-activation) and adaptive/assistive technologies will register with the service as well, to indicate their interest in receiving UI events. ATs can also use the registrys services programmatically to query accessible applications.

Running the test programs:

At the moment the only clients and are two test at clients (at and simple-at). There is also a test app (app) in the tests subdirectory.

If you have a working ORBit2/bonobo-activation installation you can run the tests after adding the registryd directory to the bonobo-activation directory list with bonobo-activation-sysconf, or by installing Accessibility_Registry.server in your bonobo-activation servers directory.

You can then run ./at and ./app from the test directory, to see app register as an application, and at as a listening client. Bonobo should take care of the job of bootstrapping the registry daemon (registryd) for you. These test programs use the bonobo/CORBA C bindings directly.

imaj.at is a service menu for KDE to upload images to the http://imaj.at is photo upload service.

http://imaj.at is photo upload service and DeliPenguen(Tugrul) written a service menu for imaj.at.

cp gonder_imaj_at.desktop /usr/kde/3.5/share/apps/konqueror/

cp imaj.at.upload.py /usr/bin

GAIL provides accessibility support for gtk+ and libgnomecanvas by implementing AtkObjects for widgets in gtk+ and libgnomecanvas. GAIL library is a GTK+ module.
For example, if the module is loaded in a program which calls gtk_widget_get_accessible() for a GtkEntry an instance of GailEntry is returned. This module is normally used with the atk-bridge GTK+ module from at-spi to allow an assistive technology, e.g a screenreader, to query or drive the program.
Dependencies:
In order to get CVS gail installed on your system, you need to have the most recent CVS versions of gtk+ and libgnomecanvas installed as well. Note that gtk+ requires glib/pango/atk and libgnomecanvas also requires libart, pangoft2 and gnome-common.
Building:
To compile a CVS version of gail on your system, you will need to take several steps to setup the tree for compilation. You can do all these steps at once by running:
cvsroot/gail# ./autogen.sh
Basically this does the following for you:
cvsroot/gail# aclocal; automake; autoconf
The above commands create the "configure" script. Now you can run the configure script in cvsroot/gail to create all the Makefiles.
Before running autogen.sh or configure, make sure you have libtool in your path.
Note that autogen.sh runs configure for you. If you wish to pass options like --prefix=/usr to configure you can give those options to autogen.sh and they will be passed on to configure.
Enhancements:
- Bugfixes: #460820, #363450.
- Implement ATK_STATE_DEFAULT in gailwidget.
- This version of GAIL should be used with Libgnomecanvas released with GNOME 2.19.6.

sdparm utility outputs and in some cases modifies SCSI device parameters. When the SCSI device is a disk, sdparms role is similar to its namesake: the Linux hdparm utility which is for ATA disks that usually have device names starting with "hd".
More generally sdparm can be used to output and modify parameters on any device that uses a SCSI command set. Apart from SCSI disks, such devices include CD/DVD drives (irrespective of transport), SCSI and ATAPI tape drives and SCSI enclosures. A small set of commands associated with starting and stopping the media, loading and unloading removable media and some other housekeeping functions can also be sent with this utility.
This utility currently contains over 500 entries spread across generic mode pages, transport specific mode pages, vendor specific mode pages, Vital Product Data (VPD) pages and their attributes. Rather than try and document all of these here (or in the man page), another approach is taken. This utilitys internal tables can be searched and output with the --enumerate option. Additional explanatory information is output when the --long option is used (and more if the --long option is used twice).
SCSI mode pages
Mode pages hold meta data about a SCSI device which can, in some cases, be changed by the user. In SCSI parlance the "device" is a logical unit of which there may be several in a SCSI target. In the case of a SCSI disk connected directly to a Host Bus Adapter (HBA) the disk is both a SCSI target and a logical unit. The "user" in this case is the person using sdparm which is a SCSI "application client" and it feeds commands into a SCSI initiator. The SCSI initiator is found in the HBA. At the command level SCSI is a client-server protocol with the logical unit (or target device) being the server that responds to commands sent by the application client via the SCSI initiator.
Mode pages are defined in SCSI (draft) standards found at www.t10.org . Mode pages common to all SCSI devices are found in the SCSI Primary Commands document (SPC-4) while those specific to block devices (e.g. disks) are found in SBC-3 and those for CD/DVD drives are found in MMC-5. This diagram shows how various SCSI and associated standards interrelate. Often device product manuals detail precisely which mode pages (and parts thereof) are supported by a particular model and describe the way that the device will react if the generic description in the SCSI (draft) standard needs amplification. There are also transport protocol specific mode pages for transports such as "spi" (the 25 year old SCSI Parallel Interface), "fcp" (Fibre Channel Protocol) and "sas" (Serial Attached SCSI). There are also vendor specific mode pages. Mode pages that are not transport protocol specific or vendor specific are sometimes referred to as "generic" in sdparms documentation.
To see a list of generic mode page names that sdparm has some information about use: sdparm -e. To see a list of transport specific mode page names that sdparm has some information about use (for example) sdparm -e -t sas. Both lists are sorted alphabetically by mode page abbreviation.
Mode pages are not the only mechanism in SCSI devices for holding meta data. Information which seldom if ever changes for a particular device may be found in the Vital Product Data (VPD) pages which are obtained via the SCSI INQUIRY command. Performance statistics are held in log pages which are obtained via the SCSI LOG SENSE command. Recent CD/DVD drives hold a lot of information in feature and profile descriptors (see MMC-4 and MMC-5) which are accessed via the SCSI GET CONFIGURATION command (see the sg_get_config utility in the sg3_utils package).
Each mode page has up to four tables associated with it. These can be thought of like tabs on a spreadsheet, with each tab containing the same size table. The four tables are:
current values: those values that are active at this time
changeable values: bit masks showing those values that the user may change
default values: the manufacturers default values
saved values: those values that will be active after the next power cycle (or format)
The saved values are optional. If the mask in the changeable values indicates a field can be changed then the corresponding field in the current values may be changed. A bit of 0 in the changeable values mask indicates the corresponding bit in the current values (and saved values) may not be changed. A bit of 1 in the changeable values mask indicates the corresponding bit in the current values (and saved values) may be changed. At the point when a current value is changed, the user may also choose to change the corresponding saved value.
The manufacturer obviously knows a lot about the characteristics of its devices. Hence if a current field value (and saved field value) is different from the default field value then there should be some rationale.
Some current values represent a state within the target device or logical unit. If that state changes so does the current value. Such values are not usually changeable by the user.
The sdparm utility has a --get, --set, --clear type of command line interface in which mode page fields are identified by an acronym. In many cases these acronyms will correspond precisely to the standard (e.g. "WCE" for Writeback Cache Enable in the caching mode page of SBC-3). For some longer fields the standards "spell out" a field name (e.g. "Write Retention Priority" in the caching mode page of SBC-3). In such cases the sdparm utility uses an acronym (e.g. "WRP"). In sdparm, acronyms across all generic mode pages are unique (i.e. an acronym matches at most one field of one generic mode page). Each transport protocol has its own namespace of acronyms so that an acronym is unique within a transport protocol. By default, saved values are not changed by --set and --clear. When changing the current values, the saved values can be changed as well by adding the --save. All the current values in a mode page can be changed back to the manufacturers defaults with the --defaults option (and the --save option here will additionally change the saved values back to the manufacturers defaults).
Changing some mode page fields is like jumping off a cliff holding onto a rope which you are not sure is properly secured. If in doubt, change the current value without using the --save option. That way if the setting is disastrous, power cycling the device will restore the previous setting. Once the new setting is known to be safe, then the sdparm utility can be re-executed with the --save option added.
sdparm commands
The --command= option allows a command to be sent to the given device. The currently supported commands are:
capacity: sends a READ CAPACITY and if successful reports the number of blocks, block length and capacity expressed in MibiBytes (1048576 bytes). Valid for disks and CD/DVD drives with the appropriate media loaded.
eject: stops the medium (if it is spinning) and ejects it from the drive. Note that this may be prevented by software in which case use the unlock command first.
load: loads the medium and then spins it up
ready: reports whether the medium is ready for IO. Ready usually means that it is present and spun up. If the device is not ready then the exit status will be 2 (see exit status section below).
sense: reports sense data (from a REQUEST SENSE SCSI command); can include power condition information, a progress indication for a time consuming command (e.g. format) or a report an informational exception (when MRIE=6)
start: spin up the medium
stop: spin down the medium
sync: send a SYNCHRONIZE CACHE SCSI command to the device.
unlock: instructs the device to allow medium removal (i.e. an eject). Beware, the OS may have had a good reason for preventing removal of the medium (e.g. it contains a mounted file system). Use at your own risk.
These sdparm commands send SCSI commands to the given DEVICE. If they dont seem to work, adding a verbose flag (i.e. -v or -vv) may provide more information. The "ready" and "sense" commands need read permissions on the DEVICE while the other commands need both read and write permissions.
Enhancements:
- Changes to SCSI mode and VPD pages that were introduced by t10.org since the last release were incorporated.
- The pass-through interface was updated, and code which is written in C was made to compile cleanly with C++.

Accerciser is an interactive Python accessibility explorer for the GNOME desktop. It uses AT-SPI to inspect and control widgets, allowing you to check if an application is providing correct information to assistive technologies and automated test frameworks. Accerciser has a simple plugin framework which you can use to create custom views of accessibility information.
In essence, this project is a next generation at-poke tool.
Main features:
ORBit, not cspi, based
- Like the modern LSR and Orca screen readers, Accerciser uses pyORBit to talk AT-SPI with other applications. The legacy cspi module is avoided.
Plugin architecture
- Create a Python module, drop it in a folder, and have it load as a plugin pane with full access to AT-SPI and the selected element in the accessibility tree view.
Interface browser and event monitor plugins
- All the features youve come to expect from a poke tool, and then some.
IPython console plugin
- A full, interactive Python shell with access to the accessible object selected in the tree view; all AT-SPI interfaces, methods and attributes; and any other Python modules. Supports autocompletion and a million other niceties thanks to IPython.
API browser plugin
- Shows the interfaces, methods, and attributes available on the selected accessible object.
Global hotkeys
- Move the tree view quickly to the last focused accessible or the one under the mouse pointer. Insert a marker into the event monitor log for easy identification at a later time.
Customizable UI layout
- Move plugin tabs to different panels or even separate windows to view them concurrently.
Accessibility!
- Accerciser does not disable its own accessibility.
Yelp documentation
- Included in the package.
Python powered
- Brits, not serpents.

IP accounter application measures and graphs traffic for IPv4 and IPv6 netfilter-based routers. Input data is accounted using several abstraction layers (routers, hosts, flows), and IPv6 traffic accounting may be mixed with IPv4.
Enhancements:
- The WEB frontend is still unavailable. There were some minor dificulties running ipaccounter. Still the main issue is when mysql server crashes. The traffic info is then lost until someone fixes it. Therefore it is advised to use some net watching software like Nagios. For further feature enchancements see the ChangeLog. 2006-09-02 by Ondra Ipaccounter-1.0 was released. Only WEB frontend is unavailable at the moment. The accounter is run on one machine. Namely maximus.spi-net.org. There were no fault ancountered so far, but its running only for one week.