Ports Search

from the source: This is a major rewrite of the xmag program distributed by MIT with X11R5. It features three modes of magnification. The magnifier can be made to follow the mouse pointer around, displaying a magnified image either in a window that is "sticky" to the pointer, or in a stationary window. The magnifier can also be `anchored' to continually magnify a fixed area of the screen. The sticky window does not work. Trevor Johnson

KDE Base Applications consists of what runs on the desktop. This module isn't a complete collection of essential applications that a user would expect on a desktop (such as e-mail and calculator). This package is the basic set of applications beyond the workspace that KDE applications can assume are installed. These applications should have no problem running on Windows, OS X, Gnome, etc. as stand alone applications if the user wanted to use them there.

This program sets attribute "override_redirect" to True for any window you've specified (using window name). Window Managers should ignore such windows; it's useful, for example, if you're using wmx Window Manager, and want to have a clock on every virtual screen and without any borders. Just add the following string to your X-startfile (after starting watch app): xnodecor -w watch (assuming that your watch application has a window named "watch")

xstroke is a full-screen gesture recognition program written for the X Window System. It captures gestures that are performed with a pointer device, (such as a mouse, a stylus, or a pen/tablet), recognizes the gestures and performs actions based on the gestures. xstroke is most commonly configured to "type" characters in response to gestures, but it can also emulate mouse button "clicks", launch programs, and other fun things.

AntiMicro is a graphical program used to map keyboard keys and mouse controls to a gamepad. This program is useful for playing PC games using a gamepad that do not have any form of built-in gamepad support. However, you can use this program to control any desktop application with a gamepad; this means that your system has to be running an X environment in order to run this program.

This code provides a function, `i18n-man', with which you can browse UNIX manual pages. Formatting is done in background so that you can continue to use your Emacs while processing is going on. The mode also supports hypertext-like following of manual page SEE ALSO references, and other features. See below or do `?' in a manual page buffer for details. For working with Japanese, English and German, put your dot.emacs file following: (autoload 'jman "i18n-man-ja" nil t) (autoload 'eman "i18n-man-en" nil t) (autoload 'dman "i18n-man-de" nil t) then M-x jman to get a Japanese manual page thru jman(1) and put it in a buffer. M-x eman to get a English manual page thru man(1) and put it in a buffer. M-x dman to get a German manual page thru man(1) and put it in a buffer. If you want byte-compile with your favorite "Emacs", use "byte-comile" script as: # cd /usr/local/share/emacs/site-lisp # /usr/local/share/doc/prom-mew/byte-compile xemacs-mule i18n-man-ja i18n-man-ja.el i18n-man.el For usage of byte_compile scripts, run byte_compile with -h option.

Radiator is a highly configurable and flexible Radius server that supports authentication by a huge range of authentication methods such as Flat files, DBM files, Unix password files, SQL databases, remote Radius servers (proxying), external programs, NT User Manager, Active Directory, LDAP, PAM, iPASS, GRIC, NIS+, Tacacs+, a wide range of ISP billing packages such as Emerald, Platypus, Rodopi, Hawk-i, Interbiller98, Freeside etc, your legacy user database etc, etc. Radiator now supports more 802.1x secure wireless and LAN authentication methods than any other Radius server giving a wide choice of 802.1x network clients. Radiator also includes many features not found in other Radius servers such as double-login prevention, username rewriting, full vendor-specific attributes, time-of-day blocking and a GUI for running user tests. Full list of technical features. Runs on all Unix, Linux, Windows 95, 98, NT, 2000, Mac OS-9 and Mac OS-X, VMS. Due to license restrictions, this package must be purchased and manually downloaded from the Open System Consultants web site.

Tinderbox is a package building system for FreeBSD ports, based on official Portbuild scripts used on pointyhat building cluster. Tinderbox was written by Joe Marcus Clarke. You can define multiple jails (base system versions) and multiple portstrees. The combination of jail and portstree is called a build. A Tinderbox jail is not what is understood as a jail in FreeBSD, it is in fact a given world in a chroot. Tinderbox supports automatic tracking of dependencies and only rebuilds packages that changed since last run. Tinderbox has support for email notification of failed builds. Tinderbox also integrates well with ccache. Tinderbox is designed to easily provide package sets of ports you need, for platforms and architectures you need. Tinderbox is also excellent tool for testing new ports and port upgrades, especially for testing dependencies and packing lists. It's also useful for testing ports on various releases of FreeBSD, since you can run FreeBSD 6.X world as a jail on FreeBSD 7.X/8.X host.

The original Steve R. Bourne shell from the 7th edition Unix including System III, 4.3BSD-Reno, Ultrix 3.1 and ``home made'' fixes and enhancements : * `--' end of options added (sysIII). `set +x' and such added (sysIII). `/etc/bsh_profile' (sysIII) and `$HOME/.bsh_profile' (unsw) are sourced at login time if they exist. Initially, only the `.profile' located in the current directory was sourced at login time if it exists. They have been `bsh_' prefixed to avoid conflicts w/ the standards `profiles' which can contains unsupported expressions such as shell functions. negation (! or ^) in `[]' added (sysIII). `${x:-x}' and similar expressions added (sysIII). '<<-' (aka strip leading tab in here document) added (sysIII). `#' comments are allowed in shell scripts (sysIII/reno), but not on the command line (reno) ! `break N' and `continue N' fixed (sysIII/ultrix). `if... then... [elif... [else...]] fi' fixed (reno). `test' (sysIII) and `ulimit' (ultrix) builtins added. * ANSI-fication to permit an almost warning free compilation (home made). `union trenod' taken from 4.3BSD-Reno. better signal handling and error recovery (sysIII/reno). better restricted shell (sysIII) and IFS protection (reno). * functions aren't supported and command line input is not 8 bit clean.

http://www.linuxtv.org/vdrwiki/index.php/Remote-plugin This plugin extends the remote control capabilities of vdr. The following remote control devices are supported: (a) Linux input device driver ('/dev/input/eventX', X=0,1,2,...) (currently not supported on FreeBSD) (b) keyboard (tty driver): /dev/console, /dev/ttyX (c) TCP connection (telnet) (d) LIRC (e) some(?) FreeBSD uhid(4) devices (experimental support added by this port) To use, add something like this to vdr_flags: '-Premote -h /dev/uhid0', (re)start vdr, then the osd should ask you to configure the remote by pressing the buttons you want to assign. Note: If your remote is detected as a keyboard you'll have to tell ukbd(4) to ignore it first by doing (as root) something like: usbconfig add_dev_quirk_vplh 0x1241 0xe000 0 0xffff UQ_KBD_IGNORE (and possibly unplug it for a moment or reset it via usbconfig, 0x1241 there is the vendor id, 0xe000 the product id of the device, you can get yours by doing usbconfig -d 1.2 dump_device_desc and looking for idVendor and idProduct, -d 1.2 there corresponds to ugen1.2 listed by usbconfig w/o args.) You can check with: usbconfig show_ifdrv if the device is then listed as ugen...: uhid... you're good to go. 2nd note: If vdr cannot open your uhid device check it is not claimed by xorg: fstat |grep uhid If it is you may need an xorg.conf(5) with manually defined InputDevice sections for mouse and keyboard and Option "AutoAddDevices" "False" in the ServerFlags section. And if for some reason you want to reassign the buttons on the remote you can stop vdr and do: touch /usr/local/etc/vdr/channels.conf and/or remove uhid entries from /usr/local/etc/vdr/remote.conf . When you then start vdr again it should ask to configure the remote again.