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:
- It does not encode a way of knowing what application you must use to open a given file (i.e. files are not associated with applications which "own" them)
- You can in principle open any file using any application (even if the results would be disastrous)
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:
- Files know which application can edit them
- Applications know which files can open them
- Document meta-information (the type/creator stuff) isn't confused with human-readable descriptive information (the filename). (So if your cat walks across the keyboard and renames MYFILE.DOC to MYFILE.wth16`52`3, your word processor will still recognize and be able to open it.)
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:
- By looking in the file KDEBASE/share/mimelnk/magic
- By looking for MIME-link files in subdirectories of KDEBASE/share/mimelnk (global settings)
- By looking for MIME-link files in subdirectories of HOME/.kde/share/mimelnk (personal settings)
(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, newt@uchicago.edu) 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
Icon=unknown.xpm
Type=MimeType
MimeType=text/x-tcl
Patterns=*.tcl;*.tk;
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
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.
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.
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.
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.
There's more ...