Making KDE work: Part 1

[ Site Index] [ Linux Index] [ Feedback ]

KDE is generally a very cool thing: a graphical desktop environment, window manager, applications, and GUI toolkit all integrated to run under the X window system. X has had such things before, but mostly, like the commercial CDE (Common Desktop Environment), or IXI's X Desktop, they were commercial. KDE itself, however, is free software, and the Qt library it is based on qualifies as "sufficiently free" for most purposes -- meaning, you need to pay a one-time license fee if you develop commercial applications using it, but it's free for non-commercial use (like KDE) and guaranteed to remain available for non-commercial use in future (via the Free Qt Foundation).

While KDE isn't the only free desktop -- Gnome will rival it in future, and Offix, JX, or GnuStep may follow -- it's the first such environment to be available and to hit critical mass; the point at which it is fully usable as a working environment without recourse to external applications, and at which developers start piling on the band-wagon and writing extra applications for it. It's what I'm running right now: indeed, it's the desktop running on all the *NIX boxes in the company I'm currently working for. And even if it is displaced by another desktop environment (DE) over the next few months or years, it's likely that the other DE's will be drag-and-drop compatible with KDE apps. So KDE isn't going to go away real soon now.

I formed my opinion of how a GUI should work back in the days when GEM was a sophisticated environment and real humans couldn't afford Macintoshes; I recoiled in horror from the iniquities of Windows 2/386, bounced around the Windows 3.1 environment, met and fell in love with the Mac, and put up with various X11 window managers and the Windows 95 DE. I've been tracking KDE since before Beta 1, and using it in earnest since Beta 2. With each release it gets less clumsy, more usable, and more configurable. But it's still somewhat counter-intuitive. As the documentation isn't perfect yet, I'm going to try and dump down my take on the bits that aren't clearly explained in the manuals.

How desktop environments recognize files

KDE is an integrated environment. It's designed to be extensible and customizable; you should be able to use the K file manager (which puts up the pretty icons and windows you see on your desktop) to do pretty much everything you do on a UNIX box -- copy files, move things around, and click on documents to open them.

A corollary of that last requirement is that you should be able to click on documents that don't belong to KDE and open them. For example, suppose you've just installed ApplixWare, or StarOffice 4.0, and want Applix or StarOffice files to show up under KDE with the correct icons and to automatically open in their respective applications when you click on them. How do you get KDE's file manager to recognize them?

To understand what you need to do to make KDE recognize third-party applications and files correctly, you need to understand what KDE is trying to do -- and why.

Traditionally, in the CP/M and DOS world (and in the world of Windows, which is an extension of those earlier systems) files are identified by their suffix. A suffix of .exe or .com appended to the file's name indicates an executable file; .doc indicates some kind of document; and so on.

This is a Bad Thing for two reasons:

In a world where applications create their own proprietary binary file formats, this is a recipe for confusion. Was that .DOC file created using Microsoft Word or Microsoft Write? How do I know? The only way to find out is really to try opening it in one application after another, until the right one can be found.

The traditional UNIX philosophy is similar, if a little less rigid. UNIX expects all files to be treated as a stream of bytes, so that any UNIX tool should be applicable to any file. In general, the traditional UNIX approach means that data is stored in text files, along with weird markup or metainformation -- like HTML, for example. (Try looking at an Applix Write file some time using less -- then try looking at a Microsoft Word file.) Thus, UNIX doesn't put much faith in filename suffixes, and sticks to the not-very-expressive file attribute bits and hash-bang exec hack to flag files as executable and specify the application to use to load or run them with.

In the Macintosh world, things are different, and a little bit better thought-out. The Macintosh is a thoroughly application-centric environment. Files are all binary data specific to an application. Each application has a (hidden) identification code, and each data file has a hidden type code. Everything, in fact, has a Type and a Creator, and these identifiers are stashed away in the desktop database. When you double-click on a file to open it, the MacOS system checks the file's type and creator, looks in the desktop database, works out where the creator lives on the Mac, and executes it, sending an event that tells it to open the file.

This works better than the traditional DOS filename-suffix model because:

Microsoft even saw the light and built a similar feature into the Windows 95/NT registry.

The KDE way

KDE is a web-enabled desktop; the file manager is also a web browser.

The web is built around a mechanism (HTTP) that allows a client (like the KDE file manager) to communicate with a server (a web server or the local filesystem) and exchange files. HTTP necessarily needs to send meta-information describing the nature of what's in its files, because it mediates information transfers between different types of system. So, like the Mac, HTTP uses a type/creator paradigm; in this instance, MIME.

MIME (short for Multipurpose Internet Mail Extensions) is a mechanism for specifying the type of content within, and the nature of, a file transferred over the internet. In general, MIME provides files with a type and an extension. Typical types are text, video, application, and so on, indicating a generic text file, an application specific file, or whatever. The extension is a sub-type that indicates more information; for example, there exist text files of subtype HTML, like this document (text/html) and text files of subtype plain (pure ASCII text, text/plain).

Note that this says nothing about what application can open a file -- after all, this is a network protocol, and the application used to open a given file on one machine may differ from that on another. (For example, to open Microsoft Word 6 documents on a PC, you use Microsoft Word -- but on a Linux box you can't do that, and use StarOffice or ApplixWare or Word Perfect instead.)

KDE uses several configuration files to keep track of files. The files it knows about are identified by their MIME-type (which is specified in the KDE configuration files.) The applications it knows about are identified by their link files, which specify (among other things) which MIME content-types the applications can open. The K file manager uses its knowledge of the file MIME-types and the available applications to work out what happens when you click on a file.

How KDE recognizes files

KDE recognizes files and assigns MIME-types to them as follows:

(Note: KDEBASE is the base directory for your KDE installation; the environment variable $KDEDIR points to it. HOME is your home directory.)

All these configuration files do is give KDE ways of assigning MIME-types to files.

First, a bit of magic. The magic file is derived from the old UNIX file-identification tool type(1), which attempts to identify the type of a file. KDEBASE/share/mimelnk/magic contains lines like this:

# MPEG Layer 3 sound files
# Modified the 11/20/97 at 15:59:04 by Christophe Prud'homme
0       belong          0xfffb          audio/x-mp3
# XPM icons (Greg Roelofs,
0       string          /*\ XPM         image/x-xpm     7bit
# commands:  file(1) magic for various shells and interpreters
0       string          :\ shell archive or commands for antique kernel text
0       string          #!/bin/sh               application/x-shellscript

Lines beginning with a hash # are comments. The first field (zero, in all these lines) is a byte offset into a file; the second field indicates what the type program is looking for, the third field indicates something to expect, and the fourth field is the MIME-type. For example, the last line in this example says, "start at offset 0 bytes into the file; look for a string; if you find '#!/bin/sh', the file's MIME-type is 'application/x-shellscript'.

This is the first tool KDE uses to assign mime-types to files. The magic file format is documented in the man page magic(4), although the KDE project has modified it by adding the MIME-type field at the end. You can (if you're brave!) edit this file to add new MIME-types to your KDE system -- but this isn't the normal way for a user to teach KDE about the files associated with some new application.

The normal way a user adds filetypes is to add a MIME-link file, usually in their own directory. A MIME-link file looks like this:

    KDE Config File
    [KDE Desktop Entry]
    Comment=Tcl file
    Comment[de]=TcL Programm
    Comment[nl]=Tcl bestand
    Comment[pl]=Program Tcl
    Comment[fr]=Programme TCL
    Comment[fi]=Tcl ohjelma

The first two lines tell KDE what the file is -- it's a configuration file that adds a desktop entry (a description of a file type that the K desktop needs to know about). The Comment lines provide descriptions of the file that appear in the status bar at the bottom of a K file manager window when the mouse pointer is positioned over the file (assuming, of course, that the status bar is being displayed at the time). The lines with a two-letter code in square brackets are translations of the description text, displayed if KDE is running in the given locale -- for example, if you tell KDE to speak Finnish then point at a Tcl file, it will tell you it's a "Tcl ohjelma", not a "Tcl file". If no locale is set, KFM shows the default description (which in this case is in English).

The "Icon" line specifies a pixmap to use when displaying files of this type on the desktop. Icons are located in KDE's icon search path; typically in KDEBASE/share/icons. X Pixmap files are normally used; in this case, a pixmap called unknown.xpm will be displayed for any files KDE identifies as Tcl programs.

The "Type" line and the lines following it are critically important. These are the ones that identify the type of the MIME-link (that it defines a new Mime type for KDE to know about), specify the MIME-type being defined, and explain how to recognize it. Any file matching the shell wildcard patterns *.tcl and *.tk will be deemed to be of MIME content- type "text/x-tcl", and displayed with the "unknown.xpm" icon.

Of course, KDE doesn't insist that you create these files by hand.

Creating a MIME link file

In the K file manager, go to the edit menu and select Mime types. You will see a new folder, called something like /home/charlie/.kde/share/mimelnk. This is where your personal MIME-link files live. You should see some folders with names like Application and text. (These correspond to the top-level MIME content-types.) Because we're going to create a new MIME type for an application we're installing, we need to dive into the folder Application.

Having done that, go to the file menu and select . A drop-down menu appears; select File Type.

Now a popup dialog box appears. It's asking you for a filename, and as default it supplies File Type.kdelnk. Change this to something sensible, without deleting the .kdelnk suffix; for example, to add StarOffice 4.0 documents, change it to StarWriter.kdelnk. Then press OK.

A new icon appears in the mimelnk folder; it's called StarWriter. (Note that KFM doesn't display the .mimelnk suffix.)

Now we want to configure our new MIME type to match StarOffice files. To do this, we call up KDE's built-in editor; click the right mouse button on the icon, and select properties from the pop-up menu.

A tabbed dialog box appears, with three pages: General, Permissions, and Bindings. (If only two pages appear, your copy of KDE isn't properly configured.) The General panel controls what your MIME-link file is called. The Permissions panel controls the file's permissions and ownership. The important one is the Binding panel, which lets you edit the linkfile's properties.

Screen shot: KFM bindings dialog box

There are five fields in this dialog box that we need to fill in; unfortunately we can't fill in the last one until we've also set up a KDE application link as well.

The Pattern field specifies a shell wildcard pattern to match. Any file matching this pattern is deemed to be of this MIME type. It's not as sophisticated as the magic file's ability to look for a byte string within a file, but it's good enough for most purposes -- especially with StarOffice and ApplixWare, which use the old DOS principle of a file extension indicating its type. For StarOffice we need to enter *.sdw;*.SDW; in this field; for ApplixWare, we can use *.aw;*.AW. (If we want to add spreadsheets or other file types we can add their suffixes too -- or leave them for other MIME types, so they show up with different icons.)

The Comment field indicates some text which is displayed in the KFM status line when the mouse pointer is positioned over the icon for files of this type. Better say "StarOffice document" or "ApplixWare document" here.

Next, we get to pick a MIME-type. I'm going to cheat here; StarOffice is also web-enabled, and internally uses application/x-starwriter for StarWriter documents. So we'll use that.

Finally, we can pick an icon to display on such documents. Click on the icon below the "Mime Type" field and a window containing various icons will appear; you can choose any icon you like, but it's smart to pick one that isn't going to get confused with other documents.

At this point, you can press the OK button; the dialog will go away, and any files ending in .sdw or .SDW on your desktop will show up with the icon you picked. (If they don't, go to the View menu and pick Rescan bindings.)

Are we finished? No.

The problem is that although we've registered a new MIME-type and associated it with files, we haven't told KDE about the application we've added which edits those files. We need to create an APPLNK file for StarOffice, tell it that it edits files of type application/x-starwriter, then go back to the MIME link file and tell it that, among other things, it can be edited by StarOffice.

An application link defines the relationship between a program and it's data files. They live in KDEBASE/share/applnk or HOME/.kde/share/applnk. To create one you follow a process analogous to that used with the MIME link file; you use the Edit->Applications menu option to edit applications KDE knows about, then select New->Program to create a new Application link file. Then you right-click on the file's icon and choose Properties to edit its KDE-related attributes.

Screenshot: Editing an application's

We have two important property panels to edit; Execute and Applications. Execute defines how we execute the program. Minimally we must enter the program's pathname in the Execute field, followed by %f; the %f is a macro that is replaced by the name of the file we are executing. (There are other macros mentioned in the KFM FAQ.) We can also specify a directory to run the program in, and if it is a text-mode program, specify that it should run in a terminal window. (If it's a specially written program, it may also be possible to set it up to be executed in the KDE Panel.)

The Applications panel is the crucial one that binds MIME-types to an application. As with the MIME link properties, we can specify comment text to display when the mouse points to the application icon; more importantly, we can select MIME content-types registered with KDE and add them to the list of types associated with this application. (We can also use the crude mechanism of associating a "binary pattern" with the application, thought we probably won't do this.) To set StarOffice up to edit files of type "application/x-starwriter", scroll through the list of MIME-types at the bottom left of the Applications panel. When you find "application/x-starwriter" (which should show up if you created a MIME link file for it earlier), use the "<-" button to copy it to the panel on the left.

Press OK. You've now told KDE about StarOffice, including how to run it, and what MIME-types it recognizes.

Are we finished? Not quite ...

Consider the content-type "text/plain" -- basic ASCII text. It's clear that several programs can exist that edit it; vi, emacs, kedit, kfte, and so on. So how do we select the text editor?

If you right-click on a file, a pop-up menu appears. This includes a list of those applications registered with KDE that recognize the document's MIME type. This lets you choose how to open the file. But unless you set a default application for the MIME-type, left-clicking on the file won't open it; it will simply pop up a dialog box asking you to tell KDE what program you want to use.

To tell KDE that you want to open "application/x-starwriter" files using StarOffice every time, you need to go back and edit the MIME link file. Among its properties, you will find a popup menu that lets you choose a default application. Only applications that know about the current MIME type will be displayed. Because you've told KDE about StarOffice, and indicated that it knows about "application/x-starwriter", you get a choice of one; pick "StarOffice" and from now on, single-clicking a StarWriter document icon will make StarOffice run and load the file.

There's more ...

This is only scratching the surface of what you can do with the KDE file manager. KFM is a full-blown web browser, and a lot more besides; different link types exist, including URLs that can take you to other web sites or file systems, device links (that mount or unmount floppy disks, CDROMs, and other devices), and so on.

I haven't written about these other link types because I haven't gotten my head round them properly yet; besides, KDE 1.0 is due out in a week or so. Expect more articles on configuring KDE when I've got something new to report.

[ Site Index] [ Linux Index] [ Feedback ]