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).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SourceClear Open
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide