Introducing TkDesk

Don't want to give up your Macintosh or Window desktop for Linux? With TkDesk you don't have to.

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.

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.

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

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.