Jay's home page

aqtools (formerly jstools)


The aqtools (formerly jstools) suite is a group of applications written in Tk/Tcl and some libraries that they share. (At present, some of the libraries use the old Tcl ‘autoloading’ mechanism, and some of them use the newer ‘package require’ mechanism.) I intend for the libraries to be general enough to be useful to others writing in Tcl; although they're driven by what I need for my applications, I've tried to make them as general and flexible as possible.

The major application at this point is a text editor, aqedit. It supports multiple modes for editing different kinds of files, and has extensive support for multi-font text and hypertext. (It can export its documents as HTML, making it a WYSIWIG HTML composition tool. It can also import HTML, albeit a little clumsily.) There's also a hypertext document viewer (used for online help), a file viewer—essentially an X Windows analogue to more(1), a preferences panel, and a number of little wrapper scripts, described below. Those applications are documented and reasonably robust; there are also a few scripts that are included as demos or pre-release versions, including a configurable app for small databases like addressbooks or CD catalogues. (It comes with a config file that turns it into an addressbook, but you can write your own for other purposes.) In the long term I'd like to have a drawing application as well.

The suite includes several small wrapper scripts intended to provide access to dialogue panels for user input from shell scripts, window-manager configuration files, etc. These provide access to an alert panel, a couple of colour-selection tools, a confirmation tool (for yes/no questions), a file-selection box, and a prompt panel to ask for a string. (The file viewer aqmore may also be useful in similar contexts.)

Screen dumps

(Most of these are from previous versions, but the appearance hasn't changed much.)

Current version

The current version of aqstools is numbered 0.2002.01.26. (I'm using dated rather than major.minor release numbers because the package is in a period of fairly rapid change now, as I switch from old-style autoloaded library files to the current package mechanism.) For now, you can download it from this web page (see below).


This version of aqtools requires at least version 8.1 of Tcl/Tk. I've been using it under 8.3, so there may be peculiarities with earlier versions. I've developed it under Linux and tested heavily under other versions of Unix, but I've heard reports that most of jedit at least works fine under Windows NT/95, and I made sure the installation tool works there, too. (I would be interested in reports of success or failure under MacOS.)

New features

The main change since the last interim release has been the ongoing conversion of more of the library files to the ‘package require’ format. However, there are a few user-visible changes:

Acquiring the package

The current version is 0.2002.01.26. (It starts with 0 so that when I switch back to ordinary version numbering, the version number will be greater) For now, you can get it from here (I may move it to Neosoft or SourceForge eventually). You can also look at the announcement/README: and at the installation instructions: If you happen to have a Compaq iPAQ running the Familiar Linux distribution, you can install the following aqtools .ipk package on it. This does not include the documentation—you can read that on your desktop. (If you want full documentation, or to change where aqtools lives on the iPAQ, you can just run the installer from the tarball above—it runs fine on the iPAQ, as long as you have Tk installed.)


The following are temporarily unavailable, sorry! They're part of the jstools distribution, though.

aqtools: past, present, and future


I started working on what is now the aqtools suite in the early 1990s—just after, I think, Tim Berners-Lee had invented the Web, but certainly before it was at all common, and before Tk (the widget set that aqtools is written in) had a text widget, and well before Tcl and Tk had been ported to Windows or Macintosh.

The first application I wrote was a file browser somewhat inspired by the NeXTSTEP file browser; that application no longer exists. The second application was a text editor, which I originally conceived of as a quick-and-dirty single-file text editor that would do for small tasks when Emacs would be too slow to start up. It's come a long way since then, for better or for worse. :-) The third was a rich-text hypertext (but not HTML-based) documentation viewer.

I did much of the early development of the package on a NeXTstation (under X, however). I switched over to a PC running Linux in the mid-90s (after moving to Boston). While I've used it on many varieties of Unix and Linux, I've never routinely used a Windows machine, and haven't routinely used a Mac since well before Tcl/Tk supported Macs, so I haven't really had the opportunity to test it on those platforms. (I welcome non-Unix bug reports, though.)

Towards the end of the '90s, I stopped working on the package as actively. Part of that was because I had gotten most of the functionality that I relied on daily written, and didn't have as much immediate incentive to work on it. Part of it was that I got really busy with other things in my life. And part of it was that, simultaneously, Tcl itself (the language the suite is written in) was undergoing a tremendous, vibrant burst of evolution, that I was having a hard time keeping up with—Tcl was adding huge swaths of built-in functionality that (in many cases) I'd worked around not having, and so when I sat down to work on (what was then still called) jstools, most of what I was doing was making major implementation changes that didn't actually add or change any user-visible features. (That process is still ongoing.) Also, I had started off with pretty elaborate documentation, and all the internal changes I was making demanded corresponding changes to the documentation, which was becoming increasingly inaccurate.


Recently, a very sad event in my life (my partners' move to Hawai'i) has left me with somewhat more free time, and for that and other reasons I've started to work more actively on aqtools again. The internal changes (to try to catch up to changes in Tcl itself and in common Tcl practice) are still ongoing and far from complete. The documentation is in serious disarray, and doesn't match the current state of the code. However, the suite itself works fine from an end-user perspective, and while my recent focus has been on internal implementation changes, I've added functionality here and there—mostly to the editor, since that's the application I use dozens if not hundreds of times a day myself.

Also, towards the end of 2001, I got an iPAQ 3760 PDA (or ‘PocketPC’ to use Microsoft's terminology) and put Linux on it. So now I have a PDA that runs Linux and X, that (unlike the Agenda) is fast enough and has enough memory to run Tcl/Tk comfortably, but that existing desktop environments like GNOME and KDE are a bit too heavyweight for. This is the sort of thing that's guaranteed to suck me back into Tcl scripting in a major way. :-) So I've recently been adapting aqtools (or at least the parts of it that I use routinely) so it works under Linux on the iPAQ, and interacts smoothly with the matchbox window manager that's the default the latest version of the iPAQ Linux distribution. (matchbox is somewhat unusual in that it normally gives any window the entire screen, minus titlebar and dock at the bottom. This makes an X interface feel a little more like PalmOS, where you only have one app on the screen at a time, and works better for a PDA's tiny screen.)


As mentioned above, my internal changes to aqtools to match current Tcl/Tk practice are ongoing. In addition, I'm slowly trying to bring the documentation in line with the code.

Having aqtools on a handheld, though, is probably likely to be the biggest engine of change. Writing an effective app for a PDA (even such a high-end one as the iPAQ) is pretty different from writing one for a desktop computer with large screen, keyboard, and mouse. Because the screen is so small, the user is likely to want only one large window visible at a time, and that window should probably use the whole screen if it can get it. Since the keyboard is emulated with the stylus, keyboard shortcuts are almost never going to be a win over other interface elements. Responsiveness is more of a challenge (given memory constraints and lower processor speed), and also more important on a machine that I use several times a day very briefly to look something up, rather than sitting at for hours on end. (Several seconds to open an editor window I'm going to be working in for an hour is much more tolerable than several seconds to open a window I'm just going to spend two seconds in to look up a phone number.)

So an effective PDA app needs to look pretty different from an effective desktop app. However, as much as possible, I'd like to have the apps I use on my PDA behave similarly to the apps I use on my desktop—to learn one editor rather than two, one address-book manager rather than two. So what I suspect I'm going to be doing is writing libraries that provide the same functionality, but a slightly different user interface on the two platforms. For instance, the menu is at the top of the window, always visible, on the desktop. Perhaps on the PDA the user should be able to call up a menu with the same content, but it shouldn't be visible (and taking up screen space) except when it's being used. The application-level Tcl code that creates both menus should be the same. Or a window that has two components might want to display them side-by-side on the desktop, but let the user switch between them on the PDA.

Anyway, while I'm obviously going to keep working on the ‘desktop’ side of aqtools, my new need for PIM applications under PDA constraints is going to give me a whole new bunch of goals to aim for in the future.

Jay Sekora <js@aq.org>
last modified 2003.01.14