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.)
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.
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.)
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.
