[ Site Index] [ Linux Index] [ Feedback ]
Linux Development Tools
Linux has been around for eight-plus years, now. For most of that time it's been a hacker's toy: and hackers love to program. I'm going to take a look at some of the development tools available for Linux, and give some pointers to them. I'm going to try and avoid talking about the standard development tools that come with any system, though. There's a world of alternatives out there, and some of them are well worth a look.
One point to note is that Linux is crawling with development tools; virtually every distribution comes with the GNU C compiler, a powerful optimising cross-platform tool that you can also buy (on a commercial basis, with support) from Cygnus. This is the default Linux compiler, and it's good enough that most people never even think about using an alternative compiler. So I'm not going to talk about it much. Neither am I going to talk about scripting languages such as Perl, Python, Tcl, Guile, Awk, or Bash, most of which also come with any random Linux distribution. Life's too short: but if you want some starting points you could try any of www.perl.com, www.python.org, Scriptics, (for Tcl) and O'Reilly and Associates.
As an aside: any Linux distribution comes with copious online documentation (see the Linux column in Shopper #133). If you're planning on learning to program it, though, you need more. One good source is "Beginning Linux Programming" (Neil Matthew & Richard Stones: Wrox Press, ISBN 1-874416-68-0); this provides a good introduction to programming C in the Linux environment. Another is the Nutshell series of books, published by O'Reilly and Associates, which covers more Linux and UNIX programming areas than you could imagine. But it's a big field and I could fill this entire column with nothing but book reviews, so I'll stop there ...
EDITORS and IDEs
Every programmer needs a text editor or IDE with which to create their work. What exactly is a text editor, and what can you reasonably expect of one? And what is the difference between an editor and an IDE (integrated development environment)?
At its simplest, a text editor is simply a program for creating and making changes to text files. UNIX historically comes with a plethora of them, from the venerable ed -- a powerful but cryptic line-oriented tool designed for use on teletype terminals -- through vi (a direct descendant of ed, augmented for use on terminals with screens) to emacs (which nobody seems able to sum up in one sentence: emacs is a Common LISP programming environment, an editor, a development tool, a newsreader, a web browser, and a way of life). The lowest common denominator is clearly vi; while it seems strange if you've come from the world of DOS or Windows, it is undeniably powerful, lightweight -- and can be found on every UNIX system there is. Including Linux.
But editing text isn't (usually) all there is to developing software. You need tools to track file dependencies and control the compilation process; make provides this on UNIX, offering services similar to the project-control features of non-UNIX IDEs. You need tools to cross-reference source code (xref), identify files where specific symbols are referenced (tags), help debug your program when something subtle goes wrong at run-time (gdb), take snapshots of stable builds so that you can resurrect these versions after making changes (rcs, cvs), and so on. The UNIX system contains a plethora of tools for doing these jobs, and Linux contains their GNU implementations. Collectively they form the UNIX programmer's workbench, and even though bits of this environment date to the early 1970's, they're still a powerful environment for writing software. In a nutshell, almost any Linux distribution contains tools that -- once you learn them -- offer the same amount of power as any IDE.
In fact, the DOS/Windows IDEs had their roots in a simple problem; DOS was so poor a programming environment that standalone applications had to be written to tie together and replace all the functions provided by nifty utilities on UNIX. So there's a fundamental difference: editors are designed to interoperate well with other programs, while IDEs attempt to provide all the necessary tools in one monolithic application. There's some blurring of boundaries, of course (as Emacs exemplifies), but this is generally how the cookie crumbles.
There are two other big differences between the UNIX programmer's workbench and the integrated development environments of the DOS and Windows world which you may want to bear in mind. The IDEs expose their functions through menus and dialogues; the workbench is a maze of cryptic commands, most of which operate on input files which in some cases are mini-programming languages in their own right. The learning curve for becoming minimally functional using the UNIX tools is arguably steeper than the curve for learning the basics in an IDE. (vi, for example, is not exactly a menu-driven editor; although some modern variants -- vim or elvis -- can run in a window under X11, and provide online help if you know how ask for it, it's an entirely command-driven editor and its modal operations seem bizarre at first.)
Secondly, the UNIX environment is not traditionally a GUI environment. While graphical toolkits such as Tk, Gtk, Motif, and Qt exist, they aren't universally available and there is a shortage of the kind of graphical screen-painting and interface-generating tools that exist on other platforms.
In general, on Linux you've got a choice between using a stand-alone editor and separate tools, or an integrated development environment. Virtually all UNIX editors integrate tightly with the rest of the system; you can send chunks of the current edit buffer through a filter, pass the entire file to an external tool like a compiler, and run external programs and incorporate their output.
The two quintessential programmer's editors available on Linux are both free; vim (from www.vim.org) and emacs (from the Free Software Foundation) or xemacs (from www.xemacs.org).
First, let's look at Vim. Vim is a modern descendant of vi; other vi editors exist (Berkeley vi -- the original, Elvis (with character-mode web browsing extensions), Vile (based on Micro Emacs, but vi-compatible!), and so on), but Vim is currently probably in the lead in terms of incorporating new features.
If you've used vi before, Vim will feel fairly familiar. vi family editors are modal; they have distinct text-entry and command modes, and you need to be in command mode before you can move around the document. This makes sense if you bear in mind vi was designed to run on a wide range of terminals, some of which don't have extras like function keys, mice, or even screens. You type away in insertion (or overtype) mode, then hit escape to go into command mode and issue commands to move around, search and replace text, save files, switch back into text insertion mode, and so on. The commands are all accessible using a standard typewriter keyboard (with the addition of the escape and control keys); vi is actually very typist-friendly once learned, although learning it is a bit intimidating at first.
Vim adds loads of non-traditional extra commands and features. For starters, it provides the ability to embed a perl interpreter in the editor, so you can write complex text processing macros. (Python, Guile and Tcl are also supported as embedded languages.) There's online help, and the ability to split the screen into multiple windows -- not exactly traditional vi features, but welcome all the same. Syntax colourising support is extensive, and in some cases (such as Perl) is the best I've seen for a given language. More radically, vim now sports a variety of GUI user interfaces; compile it with Gtk and it will run as a GNOME-compatabile windowing application with menus and configuration dialogues. (A number of other X11 toolkits are also supported.)
Despite all these whizzy extras, Vim remains vi; either you can't live without it or you'd rather cut your wrists than use it. And it is, of course, free.
Emacs and Xemacs are different forks of the same program; Xemacs was originally a commercial derivative of GNU Emacs, but went back into the open source mainstream and is now maintained as a separate editor. Don't be fooled by the names, though; Xemacs can run in a terminal window, and GNU Emacs has X11 menus and widgets if run under X. There are cosmetic differences, but both editors will run Emacs Lisp macros and they're both pretty compatible. I prefer Xemacs when running under X11 -- it's a bit prettier -- but this is a matter of personal taste.
Emacs has got everything but the kitchen sink. It has built in ftp clients, web browsers, mail readers, news readers, scheduling packages, outliners, emulators for other editors (such as vi), interfaces to version control systems like CVS or RCS, and a psychotherapist. (No, I'm not kidding.) It's essentially evolved into an integrated office suite for programmers -- some programmers prefer to do everything from within emacs, and never even see a shell window. For traditional UNIX software development Emacs does everything you could possible want.
There are, however, drawbacks to Emacs. Xemacs may have menus, but it isn't necessarily easy to use; it's traditionally driven by commands, issued using combinations of the control, escape, and meta (alt) keys. It's powerful, but as with vi you need to put a surprising amount of work in to learning these keystrokes. Unlike vi, many of the commands require weird combinations of keys to be pressed simultaneously; my personal experience is that Emacs use is associated with repetitive strain injury. Of course, you can remap all the key bindings in the universe -- but there's a lot of universe to figure out alternative key bindings for.
A second Emacs objection I have is that it's macro language is Lisp. To quote Larry Wall, "Lisp has all the aesthetic appeal of toenail clippings in a bowl of cold porridge". (This is a cruel subjective judgement, make with no attempt at objectivity. Some people like Lisp. But Larry Wall doesn't, and I don't; and it's impossible to love Emacs without being happy about wallowing in Lisp.)
A third objection is that Emacs is big. As Jamie Zawinski (architect of Netscape Navigator) noted, "any application grows until it achieves the ability to send email". Emacs passed that point a long time ago and is still growing. Emacs was originally the text editor of choice on Symbolics lisp machines in the early 1980's, where its high degree of integration with the operating system (which was basically lisp code running on a lisp interpreter) was an asset. In an attempt to recapture that level of integration, the Emacs developers seem to have built almost all the features of an operating system into Emacs. This is not a svelte, lightweight editor ...
There are other free text editors, but I'm going to pass over them rapidly. The huge footprint of Emacs has given rise to a number of small emacs clones, such as Jove and MicroEmacs. There is also a miscellany of other types of editor; Brief clones, clones of VMS' EDT, and so on. You can find a large selection of them in the Sunsite archive: ftp://src.doc.ic.ac.uk/packages/linux/sunsite.unc-mirror/utils/editors. There are also the standard editors with KDE and GNOME -- which are actually quite usable and will be instantly familiar to anyone who's met the Windows notepad or Macintosh SimpleText.
What are the commercial text editors like? A couple of heavyweight ones have been ported to Linux; the best I've seen so far is Visual Slickedit Pro 4.0, although arguably it's crossed the line into being a full IDE.
Slickedit is a commercial package (see Slickedit.com for details). While it doesn't really do much that Emacs can't do, it has an infinitely better thought-out user interface -- and this pays off in terms of learning time and programmer productivity.
For starters, Slickedit uses the standardised CUA keystrokes that were so familiar from IBM and Windows 3.1 applications during the late eighties and early nineties. However, you can pick other emulation modes: it does a reasonable job of pretending to be vi, emacs, or brief. It has a properly thought-out menu-driven multidoc interface, too. While vi exposes none of its functionality to a naive user, and Xemacs exposes perhaps 20%, Slickedit's menus give direct access to something like 80% of the built-in commands; you can familiarize yourself with it in a day and be working productively on large software projects within a couple of hours.
Slickedit includes an extremely powerful-looking class browser for C++ and Java; it's a shame I'm not a C++ or Java programmer, and I found it even more of a shame that the class browser didn't speak Perl, because when I had a chance to read the manual and see what it could do I found myself drooling over it. Alas, my target project was a large Perl application; and it's notoriously difficult to write decent parsers for Perl. Even so, Slickedit's dynamic tagging system made my life a lot easier when navigating around the thirty or so files that comprised 25,000 line application I was playing with. Basically, Slickedit updates a table of tags (variable names, keywords, and the like) as you edit; hit alt-period to jump to the definition of a subroutine, and alt-comma to return to wherever you were before. You can also browse the tagfiles in a separate window, clicking on a file or subroutine name to edit its definition. Add some nifty rediting features (the ability to do outlining on a program's structure, collapsing subroutines that you aren't looking at; extensive syntax colourising so you can tell at a glance where those comment blocks begin and end) and you have a fairly handy programmer's editor.
Slickedit really proved its worth for me when I used it's Diffzilla(TM) -- a nice, graphical diff tool with multi-way merging and recursive directory traversal -- to merge two source trees. This was a one week job, if done by hand using the traditional tools; Slickedit actually made it painless and fast (if not enjoyable). The point here is that the tedious tasks are automated; this seems to be a design strong-point of SlickEdit. Having a built-in ftp tool so I could work on a remote machine didn't hurt either: again, you can do this in Emacs, but it's much easier to learn in Slickedit.
Slickedit has all the facilities of an IDE, except for a built-in compiler and make environment. On the other hand, you can set up projects that define the compiler and other development tools you're going to use. By telling Slickedit to use DDD for debugging Perl code, I got the nearest thing to a Perl IDE ever seen on UNIX -- a very welcome addition to the toolchest.
Along with all the usual bells and whistles, Slickedit has a built-in macro language called Slick-C which should be pretty familiar if you've messed around with C at any time. I haven't had time to heavily customize my editing environment but I've got a feeling that you can do a lot here: even write a clone of that Emacs lisp psychotherapist if you find your development work driving you over the edge.
The point of all this? Simple: the free tools are probably just as powerful, but the commercial one has a big extra -- accessibility. User interface design has traditionally been a weak area for open source software; the free editors have a long way to go to catch up with Slickedit's combination of ease of use and power. Which is not to say that experienced Linux hackers ought to throw away their copies of vi and switch to Slickedit immediately -- but if you're new-ish to UNIX software development you will probably find it helps you get productive immediately, instead of spending a month or two learning cryptic command-driven utilities. And if you're working in a commercial coding environment, it will save you money.
Contrary to rumour, Linux has pots of integrated development environments.
The main difference between an IDE and an editor is that an IDE takes a project-oriented view of the task of developing an application, whereas an editor focusses mainly on the task of editing individual files. Almost all non-trivial programs involve many -- often hundreds -- of source code files, which must be assembled in order. To minimize the number of files which must be recompiled, UNIX development typically relies on a program called make; make is a dependency analyser. Using an input file called a Makefile, it works out which files have changed (based on their most recent modification time) and which need to be recompiled in order to link them into a target binary.
Makefiles rapidly become extremely complex, and the problem is compounded because different UNIX systems provide different levels of functionality; so the projects just be able to take into account missing or extra support libraries. A number of tools have been written that generate custom Makefiles for a project when it is copied to a new system; these include xmkmf (used by the X11 windowing system) and GNU autoconf (used by just about everything).
IDEs supply their own techniques for managing the build process. You usually get a menu-driven application that provides tools for opening and closing projects -- a project being a collection of files that must be compiled in order for the target program to be built. You can visually specify the relationship between files and object code. You also get tools for saving these files in a version control archive, for invoking compilers and debuggers, for editing files, and so on.
One problem here is that IDEs generally don't have a clue about the more complex makefile configuration issues. Some -- Code Forge, for example -- are clueful enough that they can import a straightforward Makefile and turn it into an internal project; many can't even do that. A few (KDevelop -- which is still under development) are designed to use make as a back-end, and even understand autoconf; KDevelop explicitly aids in the process of using autoconf, albeit within the strictly constrained circumstances of building a KDE application coded using C++. get tools for saving these files in a version control archive, for invoking compilers and debuggers, for editing files, and so on.
A second group of features provided by IDEs are interface design tools. These are increasingly important in this age of GUI programming; a traditional IDE after the fashion of the Borland IDE of the late eighties/early nineties is fine for building command-line tools, but offers no help whatsoever with widget layout and menu or dialog box design.
A whistle-stop tour of Linux IDEs probably starts with XWP and RHide -- free clones of the original Borland IDE of the early nineties. These are great if you're nostalgic for Turbo Pascal; in combination with Free Pascal they actually give you a Turbo Pascal 6.0 clone. (There's also a port of the Borland Turbo Vision text windowing library to Linux, so you can port all those old projects of yours right away.) However, their integration with existing Makefile-based projects is minimal, they don't really support version control or interface design at all, and in terms of general functionality they're left in the dust by the more modern offerings. That's not to say they're useless -- indeed, they're under active development and acquiring new functionality all the time -- but unless you have a deep attachment to this style of environment you may want to look further.
KDevelop is still in development but shows lots of promise -- this is an IDE written within, and designed to produce applications for, the KDE desktop environment. As such it has lots of KDE-specific features (plus a decent syntax-colourizing editor and a project generator which is actually compatible with, and understands, GNU autoconf). I won't say much more about KDevelop because it simply isn't a finished product; suffice to say it's targeted at the narrowish task of creating applications for KDE using autoconf, Qt, and the KDE libraries, and within that realm it provides interface construction wizards, online documentation templates, and tight intgration with the autoconf/Makefile system.
C-Forge straddles the commercial/freeware gap. C-Forge is a semi-commercial IDE; a light version is available for free, but the full kit (paid for) adds quite a few extra features. C-Forge takes a project oriented view of the world; it's able to import a Makefile and turn it into a dependency graph showing which binaries depend on which source and header files, and it provides excellent version control facilities. It's also language independent to some extent; it supports most of the mainstream languages available on Linux.
The main advantage of C-Forge is that it lets you grab hold of an existing Makefile-driven project and make head or tail of it; you can browse a dependency tree, selecting nodes (files) to edit or build or check into RCS, and the general effect is that it can take that a cryptic-looking makefile and a directory full of source and header files and make sense of it. The editor itself is pretty good, with syntax colourising and outlining capabilities, and you can integrate other editors, compilers, and debuggers: it takes a somewhat different approach from Slickedit (where the bells and whistles are in the editor, and the project functions seemed relatively cryptic in comparison). I'd recommend C-Forge for those jobs where you inherit a medium-sized UNIX source code base and want to figure out which bits do whatever. But it's not the only tool for this job ...
Debugging is something that comes to us all in time; tracking down elusive memory leaks or silly logic errors actually takes up more programmer time than writing original code in the first place.
Linux actually excels at debugging; it seems to be a national sport. The granddaddy of the debuggers is gdb, the GNU debugger; this accompanies gcc (the GNU c compiler) and you'll find it on virtually every Linux system. gdb is not a very friendly system; it's a command-driven tool and, although powerful, is somewhat cryptic. But it makes a very nice back-end for graphical source-level debuggers; and this is how most people use it.
There are several free gdb front-ends (including Kdbg), and even a commercial one (sold by Cygnus as part of their GNUPro toolkit -- basically the full Gcc compiler/debugger/assembler kit, which you can get for free, plus technical support, which you can't). But if you twisted my arm I'd admit that the best debugger is indeed free; it's DDD, the Data Display Debugger, and using it is a real eye-opener.
DDD looks at first glance like an ordinary graphical source-level debugger. It doesn't actually debug anything itself; it acts as a front-end for gdb, or some other tool (notably the Perl and Python built-in source level debuggers, which are no more friendly than gdb). It provides the usual facilities; step over functions, step into them, set breakpoints, examine variables, and so on ... except that it goes a lot further than other debuggers when it comes to giving access to the data within a program.
DDD has spectacular data display capabilities. You can tell it to watch a variable and display it as a node in a graphical window. Tell it to track that variable's children and, if it's a pointer, you'll get a cute picture of the data structures hanging off it, complete with pointers to their children or the contents stored in the variables (if any). In short, you can inspect the actual data the program is working on. You can even designate a bunch of numeric arrays to plot graphically, or generate animations showing how the data structures under examination changed over time as the program ran. DDD is a real jaw-dropper; in combination with a sufficiently powerful back end like gdb or dbperl it lets you turn your programs inside out and see exactly what's going on inside the data they're working on -- which is the half of the story that most source-level debuggers aren't too good about telling. As far as I know you can't buy anything remotely like DDD -- it's produced as freeware by some German computer scientists, and you can get it from here.
CROSS-REFERENCING AND CODE MANAGEMENT
While the IDEs try to help you manage the dependencies of a project, they also have other jobs to do. They can help you cross-reference variables and functions to figure out what bits call which other bits, but that's not their main task. Special purpose tools are available which make it easier to see what's going on in a large application.
Probably one of the earliest such tools still to be in use is cscope; originally part of the UNIX programmer's workbench, cscope has a spartan interface (to say the least) but integrates tightly with the vi text editor. Cscope's job is to scan a directory tree full of files, then let you rapidly locate symbols within it -- function definitions, calls to variables, functions which call a given function, child functions, files that #include whichever file you're looking at, and so on. You just type a symbol in front of the appropriate prompt, hit return, and it comes back with a list of files and the lines containing that symbol; hit return again and it dumps you into an editor, positioned at that line. It's spartan, it's basic, and it's very, very, fast. A free clone of cscope (called cs) can be found at ftp://cantor.informatik.rwth-aachen.de/pub/unix/cs.tar.gz -- but be warned, it's short on bells and whistles and only works with C.
SlickEdit predictably goes one step better. Although it doesn't have the explicit functionality of cscope, it can do just about anything cscope can do, and do it for a variety of languages. Once you create a project using SlickEdit, you automatically get tagfiles generated; when you edit a file, you get a list of all the functions in it (click on one to jump to its definition) and the ability to navigate to any other reference to them (or any other keyword, in fact) via the tagging system.
But for a true view of the source code, it takes a combination of cscope's point-to-edit immediacy and a project-oriented approach to make it easy to understand what's going on. Which is where a tool like Cygnus Source Navigator comes in handy. Source navigator is basically a large project source-code browser. You point Source Navigator at a directory tree and it indexes all the files under it, like C-scope; then it gives you full access to them via a class browser interface, a smart cross-reference checker, and various query interfaces designed to allow you to locate anything you could possibly want to scan for in short order. Source Navigator comes with parsers for Java, C, C++, Tcl, and other languages; it's also extensible, so if you really need it badly you can customize it to work on just about anything. (One note of warning: Source Navigator is implemented in Tcl/Tk and is very touchy about the type of system you install it on. You may have to recompile Tcl/Tk to get it working -- not an incredibly auspicious first experience for a commercial product.)
Finally, we come to the interface builders.
It's surprising how much software exists these days that relies on a command-line interface or the world wide web to provide a front-end visible to the world. However, if you want to do GUI development on Linux you are a bit more constrained by the available tools than you would be on, for example, Windows. A look at Microsoft Visual Studio for Windows confirms this; it's got interface painting tools coming out of its metaphorical ears, to such an extent that you might get the impression from looking at it that programming has more in common with graphic design than computer science.
However, there are graphical interface builders lurking in the underbrush; they're just obscure, incomplete, or powerful but expensive.
For starters, Linux has a secret weapon in the form of the Tk toolkit. Tk is not the best or most powerful kit of graphical widgets, but it is pretty much the easiest to use -- because it's built into several scripting languages, notably Tcl, but also Perl and Python. (For an overview of these languages see the Linux column in Shopper #136, "Scripting languages".) Laying out an application's front-end in Tk is not quite as easy as writing web pages in raw HTML, but it's not a whole lot harder. And there are a couple of good quality, free tools to make it easier to make such interfaces: Visual Tcl and SpecTcl. Both of these tools let you use a graphical interface to design a graphical interface; you position buttons, frames, canvases, checkbuttons, radiobuttons, and so on on a form, and then spit out a Tcl source file at the push of a button. This file basically consists of a Tcl program that produces the interface you drew, and has stub (empty) functions for each widget's callback (routines triggered when that widget is activated). Edit this source file and add code that does something when you select a menu option or a button, and you've got an application. There's a set of patches to SpecTcl which turn it into SpecPerl, so that it produces output in Perl/Tk; if you know Perl this may be the easiest way out there to put a front end on a powerful database application.
Of the two tools, Visual Tcl is modelled more closely on Microsoft's Visual Basic IDE; SpecTcl follows its own interface model, and I found it a bit confusing in use until I worked my way through the tutorial. After that, it became relatively straightforward: and the ability to rapidly generate a graphical front-end for a simple application shouldn't be underestimated.
At this point, I really ought to say a word about Java, so I won't. Suffice to say that once Java 1.2 is running properly on Linux (as of writing, it's still in beta) any Java development tools you care to name will be available. If that's your cup of coffee, of course.
Tk may be easy to use, but it's not the only GUI toolkit on Linux. I'm going to make a point of not talking about Qt (the library KDE is based on) or Gtk (ditto, for GNOME) here, because those libraries may be powerful and friendly but I'm not very familiar with them. (Watch out for a future Shopper Linux column.) One GUI toolkit that's virtually ubiquitous in the UNIX world is Motif, from OSF: this set of widgets and toolkits has been around on X for donkey's years and is probably the toolkit of choice in the workstation market. There's a lot of Motif code out there, and even a free clone of Motif for Linux -- see lesstif.org. In fact, of the commercial and freeware tools I've been discussing, a surprising number rely on Motif -- DDD, Slickedit, and CodeForge, to name but a few.
Motif will probably give way to Qt or Gtk over the next few years, but for the time being it's a fact of life. Motif is everywhere. Which makes BX Pro an item of some interest, because it's a heavyweight professional environment for developing Motif user interfaces.
BX Pro from ICS is really rather cool. It's a commercial product that does for X window system programming pretty much what Visual C++ does for Microsoft Windows programming. You get a palette of Motif widgets, which you can drag and drop onto a project; a hierarchical browser so you can work your way around your application and connect widgets to other widgets: and a fairly nice resource editor so you can tune the attributes of each object in your project. Output is available in C, C++, UIL (an interpreted Motif user interface language similar to C), and Java; push button to generate application front end. It may be Motif, but it's in the same league of ease-of-use as Visual Basic -- and to someone who suffered through Motif training courses back before any such interface builders existed, it's a real revelation.
Since this review was published, GLADE, the GNOME development tool, has matured to a considerable extent. GLADE features output in several languages and a similar approach to BX Pro -- although it provides a smaller range of widgets, and is probably not yet suitable for use as a RAD tool in business. If I was writing this review today, I'd spend a long time talking about GLADE ...
One point to note, however, is that Motif programming is not the same as X Window system programming. X11 provides a low-level set of graphics primitives and communications protocols. On top of this, applications can be developed using the basic X11 libraries, or the slightly higher-level Xt toolkit. Motif sits on top of Xt, and provides a reasonably object- oriented interface and a set of nice widgets that do most of the boring low level stuff automatically, so you don't need to bother explicitly redrawing bitmaps or handling clipping or whatever. BX Pro takes care of things at the Motif level, which is helpful if you're writing a program that needs a user interface that can be assembled from the wide range of canned Motif widgets (or the extended widgets BX Pro comes with, which provide useful things like tree and toolbar widgets). It's not so much use if you want to get down-and-dirty and do low-level X programming, but then, that's a bit like expecting Visual Basic to help you write better assembly language. If, however, you want to write a front end for a database application, or a debugger, or an IDE, or something substantial but not graphically adventurous, BX Pro is a damn fine tool to have on your shelf.
(There's another thing I like about this product, which is the documentation. Yes, it comes in a box eight inches wide, crammed with bits of spiral-bound dead tree. This is a Good Thing(TM). Too many software companies these days seem to think that online documentation is a substitute for paper. This isn't because they've done usability studies showing that users prefer online manuals; it's because they're cheaper, and money saved is profits made. To make matters worse, this practice encourages bad habits among their technical authors -- because they're not paying for pages any more, they tend to work on the principle that quantity is an acceptable substitute for quality and consequently churn out the electronic equivalent of ten thousand page shelf-breakers. Which, as any victim knows, only makes it harder to discover anything useful. So ICS have done the job properly -- without skimping -- and I just wish other companies would follow their example.)
[ Site Index] [ Linux Index] [ Feedback ]