Chapter 15. Interactivity - Perl Cd Bookshelf [Electronic resources] نسخه متنی

Chapter 15. Interactivity

Contents:

Introduction

Parsing Program Arguments

Testing Whether a Program Is Running Interactively

Clearing the Screen

Determining Terminal or Window Size

Changing Text Color

Reading Single Characters from the Keyboard

Ringing the Terminal Bell

Using POSIX termios

Checking for Waiting Input

Reading Passwords

Editing Input

Managing the Screen

Controlling Another Program with Expect

Creating Menus with Tk

Creating Dialog Boxes with Tk

Responding to Tk Resize Events

Removing the DOS Shell Window with Windows Perl/Tk

Graphing Data

Thumbnailing Images

Adding Text to an Image

Program: Small termcap Program

Program: tkshufflepod

Program: graphbox

Emily Dickinson, "I heard a Fly buzz—when I died"

And then the Windows failed—and then I could not see to
see

15.0. Introduction

Everything we use has a user
interface: VCRs, computers, telephones, even books. Our programs have
user interfaces: do we have to supply arguments on the command line?
Can we drag and drop files into the program? Do we have to press
Enter after every response we make, or can the
program read a single keystroke at a time?

This chapter won't discuss designing user
interfaces: entire bookshelves are filled with books written on the
subject. Instead, we focus on implementing user
interfaces—parsing command-line arguments, reading a character
at a time, writing anywhere on the screen, and writing a graphical
user interface.

The
simplest user interface is what we are called line
mode interfaces. Line mode programs normally read entire
lines and write characters or entire lines. Filters like
grep and utilities like
mail exemplify this type of interface. We don't
really talk much about this type of interface in this chapter,
because so much of the rest of the book does.

A more complex interface is what is
called full-screen mode. Programs such as
vi, elm, and
lynx have full-screen interfaces. They read
single characters at a time and can write to any character position
on the screen. We address this type of interface in Recipe 15.4, Recipe 15.6, Recipe 15.9, Recipe 15.10, and Recipe 15.11.

Still more complex are the
graphical user interfaces (GUIs). Programs with GUIs can address
individual pixels, not just characters. GUIs often follow a windowing
metaphor, in which a program creates windows that appear on the
user's display device. The windows are filled with widgets, which
include things like scrollbars to drag or buttons to click. Netscape
Navigator provides a full graphical user interface, as does your
window manager. Perl can use many GUI toolkits, but here we'll cover
the Tk toolkit, since it's the most well-known and portable. See
Recipe 15.14, Recipe 15.15,
and Recipe 15.22.

The final class of UIs is one we won't address here—web user
interfaces. Increasingly, people are eschewing the complicated
programming of a fully responsive GUI whose every pixel is
addressable, preferring relatively clunky and plain-looking HTML
pages. After all, everyone has a web browser, but not everyone can
figure out how to install Perl/Tk. We cover the Web in Chapter 19,
Chapter 20, and Chapter 21.

A program's user interface is different from the environment you run
it in. Your environment determines the type of program you can run.
If you're logged in through a terminal capable of full-screen I/O,
you can run line mode applications but not GUI programs. Let's look
briefly at the environments.

Some environments only handle programs that have a bare line mode
interface. This includes executing programs with backticks, over
rsh or ssh, or from
cron. Their simple interface allows them to be
combined creatively and powerfully as reusable components in larger
scripts. Line mode programs are wonderful for automation, because
they don't rely on a keyboard or screen. They rely on
STDIN and STDOUT only—if
that. These are often the most portable programs because they use
nothing but the basic I/O supported by virtually all systems.

The typical
login session, where you use a terminal with a screen and keyboard,
permits both line mode and full-screen interfaces. Here the program
with the full-screen interface talks to the terminal driver and has
intimate knowledge of how to make the terminal write to various
positions on the screen. To automate such a program, you need to
create a pseudo-terminal for the program to talk to, as shown in
Recipe 15.13.

Finally, some window systems let you run line mode and full-screen
programs as well as programs that use a GUI. For instance, you can
run grep (line-mode programs) from within
vi (a full-screen program) from an
xterm window (a GUI program running in a window
system environment). GUI programs are difficult to automate unless
they provide an alternative interface through remote procedure calls.

Toolkits exist
for programming in full-screen and GUI environments. These toolkits
(curses for full-screen programs; Tk for GUI
programs) increase the portability of your programs by abstracting
out system-specific details. A curses program can run on virtually
any kind of terminal without the user worrying about which particular
escape sequences they need to use. Tk programs will run unmodified on
Unix and Windows systems—providing you don't use
operating-system specific functions.

There are other ways to interact with a user, most notably through
the Web. We cover the Web in Chapter 19,
Chapter 20, and Chapter 21, so we
make no further mention of it here.

GUIs, web pages, and printed documents are all enhanced by graphics.
We give here a few recipes for working with image files and creating
graphs of data. Once again, the environment you're in doesn't
preclude creating or manipulating images. You don't need a GUI to
create a graph of data (though you'll need one to view it, unless you
print the graph out).

14.19. Program: ggh—Grep Netscape Global History		15.1. Parsing Program Arguments

Copyright © 2003 O'Reilly & Associates. All rights reserved.