Free user manual software for linux

Sub::Slice::Manual is a Perl module with user guide for Sub::Slice.

USING Sub::Slice

Sub::Slice is a way of breaking down a long-running process and maintaining state across a stateless protocol. This allows the client to draw a progress bar or abort the process part-way through.

The mechanism used by Sub::Slice is similar to the session management used on many web user authentication systems. However rather than simply passing an ID back as a token as these systems do, in Sub::Slice a data structure with richer information is passed to the client, allowing the client to make some intelligent decisions rather than blindly maintain state.

Use of Sub::Slice is best explained with a minimal example. Assume that there is a remoting protocol between the client and server such as XML/HTTP. For the sake of brevity, assume that methods called in package Server:: on the client are magically remoted to the server.

The server does two things. The first is to issue a token for the client to use:

#Server
sub create_token {
my $job = new Sub::Slice();
return $job->token;
}
The second is to provide the routine into which the token is passed for each iteration:
sub do_work {
my $token = shift;
my $job = new Sub::Slice(token => $token);

at_start $job sub {
my $files = files_to_process();

#Store some data defining the work to do
$job->store("files", $files);
};

at_stage $job "each_iteration" sub {

#Get some work
my $files = $job->fetch("files");
my $file = shift @$files;

my $was_ok = process_file($file);

#Record we did the work
$job->store("files", $files);

#Check if theres any more work left to do
$job->done() unless(@$files);

};
}

The client somehow gets a token back from the server. It then passes this back to the server for each iteration. It can inspect the token to check if there is any more work left.

#Client
my $token = Server::create_token();
for(1 .. MAX_ITERATIONS) {
Server::do_work($token);
last if $token->{done};
}

The Modular Manual Browser is a set scripts designed as a man/apropos work-alike. It indexes manual pages across different operating systems and displays them in a searchable database in a Web browser.
It is easy to set up and includes highlighting, linking support in man pages, browsing and searching of pages, categories, and manuals.
It can also optionally set up a database containing descriptions of pages from the page titles.
Enhancements:
- BUGS, COPYING, INSTALL, INSTALL.roff, Makefile, README, README.roff, TODO.sh, config.php, index.php, mandb.php, modfunc.php, modman.php, api/files.php, api/modfunc.php, api/pages.php, api/whatis.php, install/BUGS, install/COPYING, install/INSTALL, install/INSTALL.roff, install/Makefile, install/README, install/README.roff, install/TODO.sh, tmp/.local: api split up, install data moved, so that modman may be dropped directly into webspace. mandb.php can pick up multi-line descriptions now.
Apropos results can be filtered by Section or Manual, but not Page (obviously).
whatis pseudo-database implemented, enabled by default in config.
Sections include Subsections (3->3ucb, 3ucb->3ucblib). Local Apropos and description support added via apropos/whatis programs.
- Release 1.2 -- The Small-Box/WhatIS Release.

Kpum is a user manager for the pureftpd server. You can add, modify and delete users of the pureftpd server.
Currently only the pureftpd.pdb database is supported. Kpum is a application for the KDE environment.
Installation:
make -f admin/Makefile.common
./configure
make
su
make install
exit
Enhancements:
- toolbar + statusbar added
- double click on user opens user edit dialog
- userdefinied remove of fields from listview
- User ID
- Group ID
- max. Upload
- max. Download
- max. Files
- max. Size
- Up/Down Ratio
- Time
- Restrictions
- max. Connections
- user must not longer be root
- storing of window position and size
- default user/group/home directory option added
- KDE 3.1.x build fix

User Account Information provides an ethernet users/customers traffic counter.
User Account Information is lightweight system for accounting for ethernet traffic on a per-user basis.
It includes a Web-based interface for allowing users to view their own network accounting information.
This product was designed and was tested in RedHat Linux 6.2 and in SlackWare Linux 7.0.
Main features:
- For each customer (who have IP adress in your local network area) are added two ipchains rule for counting input and output traffic.
- Each customer can look his own account information through WEB-interface.
- You ( as system administrator) can correct anything You want or anything you dont like in this program.
Enhancements:
- A date format error solely affecting output with DD/MM/YYYY action dates was corrected in the cgi-bin part.

This chapter serves as a gentle introduction to Maypole and setting up Maypole applications. We look at what Maypole is, how to get it up and running, and how to start thinking about building Maypole applications.

What is Maypole?

Presumably you have some idea of what Maypole is all about, or otherwise you wouldnt be reading this manual. But Maypole is good at many different things, and you may have accidentally focussed on one aspect of Maypole while missing the big picture.

For instance, you may know that Maypole is extremely good at putting web front-ends onto databases. This is true, but its only a part of what Maypole does. You may have heard that Maypole is a web application framework, which is true, but it doesnt mean very much. There are a huge number of things that Maypole can do, because its very much a blank slate. You can make it do what you will. In this manual, well be making it act as a front-end to a database, as a social network site, as an intranet portal, and many other things besides.It is a framework.

I like to think that Maypole is a way of going from a URL to a method call to some output. If you have a URL like /product/order/12, Maypole is a way of having it load up product number 12, call an order method, and produce a page about what its just done. The reason Maypole is such a big deal is because it does all this for you. You no longer have to care about your web server. You hardly have to care about your database. You dont have to care about templating modules, parsing CGI parameters, or anything else. You only need to care about business logic, and the business logic in this instance is how you order a product, and what you need to display about it once youve done so. This is what programming should be: only caring about the work that distinguishes one program from another.

It does this using a technique called MVC for web applications.

What is MVC for web applications?

Maypole was originally called Apache::MVC, reflecting its basis in the Model-View-Controller design pattern. (I had to change it firstly because Maypole isnt tied to Apache, and secondly because Apache::MVC is a really dull name.) Its the same design pattern that forms the foundation of similar projects in other languages, such as Javas Struts framework.

This design pattern is found primarily in graphical applications; the idea is that you have a Model class which represents and manipulates your data, a View class which is responsible for displaying that data to the user, and a Controller class which controls the other classes in response to events triggered by the user. This analogy doesnt correspond precisely to a web-based application, but we can take an important principle from it. As Template Toolkit author Andy Wardley explains:

What the MVC-for-the-web crowd are really trying to achieve is a clear
separation of concerns. Put your database code in one place, your
application code in another, your presentation code in a third place.
That way, you can chop and change different elements at will,
hopefully without affecting the other parts (depending on how well your
concerns are separated, of course). This is common sense and good practice.
MVC achieves this separation of concerns as a by-product of clearly
separating inputs (controls) and outputs (views).

This is what Maypole does. It has a number of database drivers, a number of front-end drivers and a number of templating presentation drivers. In common cases, Maypole provides precisely what you need for all of these areas, and you get to concentrate on writing just the business logic of your application. This is one of the reasons why Maypole lets you develop so rapidly: because most of the time, you dont need to do any development at all.

Template::Manual::Views is a template toolkit views (experimental).

This section describes dynamic views: a powerful but experimental new feature in version 2.01 of the Template Toolkit.

A view is effectively a collection of templates and/or variable definitions which can be passed around as a self-contained unit. This then represents a particular interface or presentation style for other objects or items of data.

You can use views to implement custom "skins" for an application or content set. You can use them to help simplify the presentation of common objects or data types. You can even use then to automate the presentation of complex data structures such as that generated in an XML::DOM tree or similar. You let an iterator do the walking, and the view does the talking (or in this case, the presenting). Voila - you have view independant, structure shy traversal using templates.

In general, views can be used in a number of different ways to achieve several different things. They elegantly solve some problems which were otherwise difficult or complicated, and make easy some things that were previously hard.

At the moment, theyre still very experimental. The directive syntax and underlying API are likely to change quite considerably over the next version or two. Please be very wary about building your multi-million dollar e-commerce solutions based around this feature.

Games::Maze::SVG::Manual is a Perl module with manual for the Games::Maze::SVG modules.

PURPOSE

The Games::Maze::SVG module supports the creation of 2-dimensional mazes in an SVG format suitable for printing or playing interactively. This module use the Games::Maze module to perform the actual work of creating the mazes.

HISTORY

During the middle of 2004, my son was extremely interested in mazes. We could not get enough mazes for him to solve. As a Perl programmer, I decided there must be some way to generate mazes and went to CPAN. I found Games::Maze. I printed a few pages of these mazes, and he was happy.

Unfortunately, the ASCII-based maze was not really satisfying for me. So I wrote code to convert the output of Games::Maze to SVG. This made much nicer looking mazes. I worked for a while to make the lines look better and to vary the corners to generate mazes that looked even better.

But the mazes were still missing something. So, I added the scripting support that would make the maze playable. I wrapped an HTML form around the generation program to allow it to be launched from the web.

I made this version available on my website. A friend of mine made some suggestions for individual visual changes that I incorporated. The design of the code did not change much during the next year. It was still a quick hacked wrapper around Games::Maze without much flexibility.

A year later, a comment on the SVG Developers mailing list made me dust off the code with an ey towards making a legitimate Perl module out of it. When I began looking at the code again, I realized that the original had been more of a hack than I remembered. The new version still could use some significant cleanup, but I am much happier with the overall design.

SYNOPSIS

use Games::Maze::SVG;

my $maze = Games::Maze::SVG->new( Rect, wallform => roundcorners );

my $svgout = $maze->toString();

OVERVIEW

The Games::Maze::SVG module can produce interactive or non-interactive mazes in SVG of three basic shapes. The shape of the maze is determined by the first parameter. This parameter is a string with one of the following values:

Rect

A maze with a rectangular overall shape and rectangular hallways.

RectHex

A maze with a rectangular overall shape and hallways made from hexagonal cells.

Hex

A maze with a hexagonal overall shape and hallways made from hexagonal cells.

The mazes can be further configured using a set of named parameters that follow the shape parameter. Most of these parameters are independent of the shape chosen. In addition, the mazeparams parameter supports passing parameters directly to the internal Games::Maze object which is used to create the maze.