|
|
|
|
|
|
|
|
Don't want to give up your Macintosh or Windows desktop for Linux? With TkDesk you don't have to.
by John Blair
TkDesk, developed over the past several years by Christian Bolik, is currently one of the most powerful desktop managers for Unix and Unix-like environments. Christian points out in his documentation that the system was designed especially for Linux, which is primarily where I use it. However, I also use it successfully under AIX and reports have been favorable under Solaris and other Unix flavors.
Rather than provide a user's manual or specific customization tips, which you can learn by reading TkDesk's excellent documentation, I'll describe in this article why I think TkDesk is such a useful and important Unix tool. As an example, this morning I logged into my computer through xdm. All I have scripted to start automatically is TkDesk and a few utility applications, like xautolock and xsysinfo. After seeing the TkDesk startup screen, I am presented with the AppBar (see Figure 1) and a few file browsers (see Figure 2), positioned where I left them the last time I was logged in. From the mailbox icon I see that I have e-mail. Clicking the mailbox starts exmh, and I read the messages that have arrived since yesterday. Someone has found an error in a CGI script. Figuring it won't take long to find the problem and fix it, I start up XEmacs and Netscape, again by clicking icons in the AppBar. I point one of my file browsers at the directory containing the CGI script and another to a development directory. By clicking and dragging with mouse button two, I make a copy of the script into my development directory (see Figure 3). I then drag this copy onto the XEmacs icon in my AppBar, which loads the script into my previously started XEmacs session. Looking through the code I realize that I may have flipped the arguments to a CGI module function that I called. Clicking with button three on the Library icon in the AppBar shows my customized documentation menu (see Figure 4). I select the reference to my locally installed Perl documentation. A Netscape window opens up listing the directory and I click on the cgi.pm.html link. Seeing my error, I make the necessary changes. I also need to check another Perl script. This time, instead of dragging the script onto the XEmacs icon, I click the file once to select it, then choose the ``Open File New Frame'' I have configured under the XEmacs menu. This creates a new XEmacs window displaying the script.
After double checking this code, I finally have to start a shell so I can test the changes I made to the script off-line. Clicking with button three on the file browser listing that represents my development directory causes a pop-up menu to appear, much as clicking on an icon in Windows 95 or Windows NT 4.0 with the right mouse button causes a menu to appear. I select the ``Start XTerm Here'' option and an XTerm window opens with the working directory set to this location. When I am satisfied with the script's behavior I use su to go to the WWW administrative account and install the script. Unfortunately, TkDesk doesn't provide me with an easy way to accomplish this last step--at least not yet.
Last, curious if anyone is currently accessing the web server, I run the netstat command. However, I don't run it from the command line. I choose the ``netstat'' option I have set under the System Statistics icon, which opens the ``Periodic Execution'' tool, running the netstat command (see Figure 5). The Periodic Execution tool, in this case set to run netstat every 30 seconds, is one of several general purpose tools which TkDesk provides.
Figure 5. Screen Shot of Periodic Execution Tool
This scenario demonstrates only a small subset of the wide variety of tasks I regularly conduct quickly and efficiently using the TkDesk desktop manager. I find this account significant because this is not how most people think of interacting with Unix. Being a long-time Macintosh user, I have always been convinced that a well-designed GUI is more efficient than the command line for most activities I conduct on my computer. Unfortunately, until TkDesk came along I hadn't found a Unix file manager that I felt made me any more efficient than working within the shell. A possible exception to this is NextStep. This is appropriate since the look and feel of TkDesk borrows heavily from the NextStep Dock and file browser. The NextStep file browser did deal poorly with non-NextStep native files and applications when I last used it, circa NextStep 2.0. Things may have changed since then.
The reasons for not having an efficient desktop manager are varied, but chief among them is the difficulty of dealing with the relative anarchy of the Unix environment. A monolithic GUI desktop manager works well only within the context of a well-defined API. The Macintosh Finder and the Windows Explorer as of Windows 95 can depend on nearly every application to support basic operations, such as opening a file, in the same way. Obviously, Unix contains no such API. To most Unix gurus this provides a level of flexibility that is considered a strength, not a drawback.
Instead of breaking in the face of this anarchy, TkDesk is able to effectively work with it. Unlike the other monolithic file managers, TkDesk was written almost entirely in Tcl/Tk. This means that instead of relying on a specific class of procedures to deal with files, TkDesk can react to each file type differently by referencing a chunk of Tcl code. An example of this can be seen in how TkDesk deals with XEmacs and Netscape when I double click on a file ending in .html; TkDesk loads the file into Netscape using the Netscape-Remote extensions to Tcl. However, when I drag the same file onto the XEmacs icon or choose the XEmacs option I have added to the pop-up menu associated with HTML files, TkDesk calls the gnudoit function to send a load command to XEmacs. Dragging a group of documents onto the Netscape icon works equally well, since a small ``foreach'' loop applies the operation to each file, causing a Netscape window to appear for each file. This technique of encapsulating chunks of Tcl code behind icons and menus is used to define most of the behavior of TkDesk. Since each of these chunks of code is accessible in the many TkDesk configuration files, changing the behavior of TkDesk is fast and easy.
I think the best way to understand TkDesk is to think of it as a kind of universal file selector. TkDesk provides you with a clean, intuitive interface to apply specific commands to different types of files. The built-in commands supported by TkDesk are the types of operations you would expect from any complete file manager: copying, deleting, moving, renaming, linking and symbolic linking. The delete command, like any self respecting desktop manager, can be used to copy files into a ``trash can'' before permanently deleting them.
A file's type is determined by matching it with a global pattern. One configuration file, the FileTags file, maps global patterns to the icons, fonts and colors which describe how the file will appear in the file browser. Another configuration file, the PopUps file, maps global patterns to lists of Tcl commands which will be available when one clicks on the file with mouse button three.
This design allows you to tie specific menu options, icons and other behavior to a file or directory by matching its extension, as one does under Windows. However, it also lets TkDesk react to other types of file patterns, such as Emacs checkpoint files, README files and Makefiles in specific ways. With TkDesk I can now unpack a source distribution, run the configure script and build the system without opening a command prompt. A handful of Tcl functions that could be considered the TkDesk API make writing these code fragments easier and more consistent. One function is used to run a command in the background, displaying notice in the status bar of the file browser when the program starts and exits. This same function adds this command to the command history menu. One function allows you to display your own messages in the status bar. Other functions allow you to ask for confirmation or for strings to be entered, to display the output of programs in the built-in editor, to play sounds, to start commands in the periodic execution tool and more. A ``Local'' configuration file is even provided should you wish to write your own functions for use in the other configuration files (and I'm sure most readers of this article will sooner or later feel the urge to add their own functions).
While the core of TkDesk is the AppBar and file browser, a collection of smaller tools is also supplied. My favorite is the convenient help viewer, which can parse the text representation of a Linux HOWTO document (see Figure 6). One of the initial default configurations is a global pattern to recognize gzipped HOWTO documents, unpack them and display them in this help viewer.
Figure 7. Screen Shot of Information Box
Another tool is the built-in file information box that provides a quick way to view the attributes of any given file, change the access mode of the file, ``touch'' the file, and more (see Figure 7). The built-in editor is comparable to Windows Notepad or Macintosh TeachText and provides a quick way to view and scan text files. The find file tool encapsulates the varied options of the Unix find command behind an easy to use dialog box, including filtering all the found files through grep. As you would expect, the results of the find command are displayed in a list which provides access to the same pop-up menus available from the file browser (see Figure 8).
Despite this glowing review, TkDesk is not without its flaws. The most obvious complaint is its speed. One frequently notices operations that slow down because of the large amount of Tcl being interpreted behind the scenes. I usually choose not to display the icons in the file browser--updating the icons in a large file list often takes too long. However, this is likely to change very soon. Tcl 7.6 and earlier versions were internally based on no more than substituting strings over and over again. While this allows for the design of a very simple interpreter, it does cause a performance hit in frequently executed code. Tcl 8.0 has an internal byte-code interpreter and provides speed comparable to Perl. Unfortunately, the object-oriented extension to Tcl, [incr tcl], that TkDesk is written in, is not yet ported to Tcl 8.0. The work to port [incr tcl] to Tcl 8.0 is ongoing and may be finished by the times this article goes to press. Once [incr tcl] works with Tcl 8.0 we can expect a big speed increase in TkDesk.
I hope that TkDesk is not the last word in GUI desktop managers for Unix and, in particular, Linux. Several other projects, like the K Desktop Environment and GNUStep show much promise. Just as TkDesk currently demonstrates, I think the future of GUI design lies in tying the widgets that these projects provide to a flexible scripting language like Tcl, GUILE or other scheme variants, Python or some yet-to-be-invented scripting language. The success of the GIMP project is another testimony to the success of this type of design. For now, though, TkDesk is the ruler of my desktop.
John Blair is currently a system administrator in The University Computer Center at the University of Alabama at Birmingham where he tends several Unix and (shock, horror) Windows NT servers. By the time this article is published he may be working someplace else. John is also the author of SAMBA: Integrating Unix and Windows, published by the same people who bring you Linux Journal. Feel free to contact him via e-mail at jdblair@uab.edu.
