Writing a Mouse-Sensitive Application
And what if the environment is not a Linux computer? A pair of good design choices and a small investment of your time can make you a proficient user of the autoconf package, and your application can easily adapt to the following environments:
A Linux machine with gpm installed. This is the best environment, and the application will be compiled with full support, under both the console and xterm. When invoked within a mouseless tty, the application will run in keyboard-only mode without needing runtime conditionals.
A Linux machine without gpm. If the application is distributed in binary form, the gpm library will silently detect lack of the server and will run in keyboard-only mode on the console. Under xterm everything will work. If the application is distributed in source form, and thus can't link in the gpm library, the following case will apply.
Another Unix-like operating system. The application will compile with xterm support built in, because autoconf will include gpm-xterm.c in the set of files to be compiled. This source replaces the most useful functions you find in libgpm (that is, the open, close, and getc functions) and Gpm_Repeat(), a support function used to provide event repetition while the button is kept pressed. The concept of “mouse handler” will still work.
A non-Unix operating system. It seems like a lost battle... You have to include a lot of conditionally compiled code anyway. Are you sure you need a mouse-sensitive application? In any case, it will be no harder than making any application portable between significantly different operating systems.
The code excerpts in Listings 1 and 2 include the the relevant parts of configure.in and Makefile.in used to create the “portable” sample application distributed within the gpm package. They are reproduced here to give an idea of how easy it is to set up a portable compilation environment. In fact, you needn't be an autoconf expert to set up such an environment, because a little documentation and good amount of cut and paste can easily work.
This configure.in checks if Gpm_Repeat is found in libgpm and selects whether libgpm is linked in or gpm-xterm.c should be compiled. Note that the high-level library, though not managed in this configure.in, is independent of the low-level mechanisms, thus it can be included in the portable application as well.
Gpm_Repeat is a software aid to repeating events on a timely basis up to button release. It works also under xterm and is used here as a test because it appeared only when the library and server were quite stable. I presume you don't want to link your application with libgpm 0.01, in the unfortunate case that some early alpha tester has one lying around on his or her hard drive.
Before you actually start coding, however, it is worth understanding the pros and cons of mouse programming using libgpm, and being warned against common pitfalls.
If you need to write a friendly interface, using libgpm is really difficult compared to writing a Tk script. If your interface is going to run on a powerful workstation, you are better off running X-Windows and Tk. Moreover, it is completely portable—free Macintosh and MS Windows ports of Tk are in development.
If your application will run on a general-purpose workstation which does not run X-Windows, you should take into account the trend to upgrade existing hardware. Thus, if your application is a medium- or long-term project, you might be better off to start with Tk anyway.
But then, what applications need libgpm, if the author himself discourages its use? As a simple rule, I suggest writing text-only applications when you need to support the whole range of Linux computers. System management tools are good candidates for libgpm—remember that Linux-1.2 still runs happily with 2MB of RAM and 10MB of disk.
Another field which could benefit from a simple mouse-sensitive front end is the field of embedded systems and dedicated machinery. For example, an inexpensive Linux box can be used as an NFS (Network File System) or WWW server for a small company, and usage reports will be queried by novice users. Avoiding X-Windows and writing a gpm-based interface is a win here.
If I've not discouraged you from using libgpm, go for it, but remember to pay attention to portability, simplicity, and the user's proficiency.
Portability is a major issue when developing a Unix application. Particularly, remember to build a tty-independent application—this means you must always provide a keyboard alternative to mouse events. There are hundreds of tty types, and you can't force a user to use the Linux console. Besides, a user might need to drive your application in “unsupervised mode” through stdin.
Another important issue is keeping it simple: don't depend on things like pressing two buttons at once, for example, which won't work under xterm.
Finally, remember that the user must feel the mouse. You should redraw the mouse cursor (possibly by means of Gpm_DrawPointer) after each write to the screen. This is important because users tend to use the mouse for selecting text, and using a mouse-sensitive application in the same way as selection can make for disasters.
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
|Firefox Security Exploit Targets Linux Users and Web Developers||Aug 17, 2015|
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Three More Lessons
- Calling All Linux Nerds!