.comment: The Developers Haven't Heard

By: Dennis E. Powell
Tuesday, April 3, 2001 11:11:01 PM EST
URL: http://www.linuxplanet.com/linuxplanet/opinions/3202/1/

Don' Need No Steenkin' Distribution

As one distributor after another moves away from the idea of selling desktop Linux to mere people, it becomes increasingly clear that the developer community hasn't gotten word that Linux isn't suited to be a desktop operating system for the likes of me and thee.

Good.

On Monday, GNOME 1.4 either was or wasn't released, and if it wasn't we can pretty well assume it will oneday be. (I write this on Monday with the issue still in doubt.) When it is, my colleague Michael P. Hall, who has really cool initials, will very ably tell you about it.

And though GNOME is not my desktop of choice, surely it is the one that seems most specifically aimed at the single-machine desktop user as opposed to the enterprise, what with the variety of content provision either offered or envisioned for it. I suppose there are ways that this could be turned to the advantage of businesses, but it is the single/home/hobbyist market that seems to me to be most likely to make use of these services. If the desktop is no place for Linux, the people at GNOME (and Ximian and Eazel) haven't heard about it.

Nor have the people involved with KDE, where some exciting stuff is going on.

KDE-2.1.1 was released last week. It is a bugfix. Not to criticize in any way those who undertook the often difficult, usually unexciting, and always important task of finding and exterminating bugs, but the really exciting stuff is going to be in KDE-2.2.

Major Advances

Three things have consistently annoyed me about Linux: its typeface handling, its poor printing support, and the lack of what I think of as a decent word processor (I'm writing this in an ancient beta of Lotus WordPro '96 just to see how it compares with Linux word processors; so far, the answer is "favorably"). The KDE folks are taking serious steps to resolve all three.

You can already see how the typeface issue is being addressed, at least to some extent, in the option to use font anti-aliasing in KDE-2.x, if you have Xfree86-4.02 or better and have compiled QT to enable it. This is not, I hope, the end of it, for problems remain: A limited number of character sets are currently supported. With QT-2.x, you can enable anti-aliasing in KDE and use TrueType and Type1 typefaces, or you can decide to do without anti-aliasing and use your bitmap typefaces as well, but you cannot have anti-aliasing for some typefaces but not others. (There is a workaround for dumping anti-aliasing in Konsole, which is otherwise just about useless, but that's as far as selectively turning it on and off goes.) The Trolls say that having it all won't be possible until QT-3.0. That's true unless one of the master coders at KDE decides it's important enough for a miracle to be done.

It would not, interestingly enough, be a first. More about that in a minute.

The printing issue is being addressed in what looks to be a very robust fashion through a new printing architecture contributed by Michael Goffioul. The Kprinter class seems to effectively replace Qprinter. It's based on plugins and is accompanied by a printer management tool. The library itself is split into core and management parts. It is very CUPS-friendly (indeed, CUPS was the first system to receive full plugin support, and CUPS is good enough, and freely available, so an obvious solution for many if not all users is simply to get and install it), but the hooks are there for any other print engine, spooler, or system one wants and is willing to hack his or her way toward. Before it is released, other plugins will likely exist as well -- there is rudimentary support for LPR even now. Though I'm expert in neither code nor architecture, Michael Goffioul's work looks as if it's something that will address a world of complaints about printing in Linux, at least for KDE users.

KDE's Miracle Worker

I mentioned the performance of miracles. There are many very good KDE developers, and some brilliant ones, but very few make it seem as effortless as does David Faure. It is as though he can just arrive at a particularly thorny project, wave his magic keyboard over it, and that which was inscrutable becomes clear. I may be overstating, but if I am it's only by a little.

His latest miracle involves KWord, which I think any objective observer would say has been badly broken. To the credit of the developers, no one was claiming, really, that it wasn't; but as things stood Kword was in no immediate danger of filling the void in Linux word processors.

QT-3.0 will involve some improvements in text handling that are not much short of a quantum leap. Problem is, or was, that QT-3.0 is still over the horizon, and KWord needed fixing today. So David Faure backported the QT-3.0 richtext handling for use in KWord.

"That was actually a piece of cake," he explained to me in an email message. "The real work was rebuilding KWord around it (and implementing the document/view separation that doesn't exist in QT), and credits go to Reggie [Stadlbauer, one of the Trolls, originator of KWord more than two years ago, and like David one of the nicest guys in the world] for making this very powerful richtext stuff in the first place."

The difference, at least here, was the difference between a KWord that was unusable, and one that is already good for things. Bear in mind that it is not yet by any means a finished product. But a lot of stuff has been happening there. KWord's handling of big documents has become slicker, file storage has improved so that a given document is now smaller, bullets now exist, and margins are more controllable. KPresenter parts can now be embedded in KWord documents.

Still to come, though this must await QT-3.0, is bi-directional text editing, necessary for languages that read right to left. This is so reliant upon features that will be in QT-3.0 that there was no way to backport it without bringing most of QT along, which carried its own problems, obviously.

KWord is still by no means a finished product; it's not even especially close. A lot of issues remain, and there is always the problem of filters, because unless and until everyone uses KWord, document interchange requires filtering. But it's a huge step forward.

Meanwhile, in Sunny California

To the extent that I can take measure of the Linux community, there's a broad mood of acceptance and even welcoming, except from especially vocal and zealous iconoclasts, of commercial application software as an entry among the choices available to Linux users. I think that this is a Very Good Thing, and I think that it's a tragedy that whatever drove, for instance, FrameMaker from the Linux arena did so. The best I can tell, the wider Linux community wants an open operating system and the tools to create applications, but is perfectly happy for there to be commercial, closed-source applications. This acceptance, to the extent that it is fostered and comes to thrive, will mean much in the long-term success of Linux not just as an operating system but as a desktop operating system. Not everybody can code for free forever.

A beneficiary of this acceptance, and I think a worthy one, is theKompany.com, which at any given moment is at work on a world of applications, most of which promote Linux on the desktop. This week it released the second beta of its Aethera program, an integrated email and contact management suite. Added are support for imap servers and mbox storage, as well as the beginnings of some crucial internal tunings and some user interface improvements.

Also coming out this week is the second beta of Kapital, theKompany.com's Quicken replacement for KDE. Bugs have been fixed, but in my estimation the crucial new feature is importation of Quicken-generated QIF files, which does much to ease migration from Windows to the Linux desktop. It, too, has some changes in its user interface. Plans call for Kapital to be released in late summer. Unlike most of theKompany.com's projects, Kapital is not open source. (Which, before you criticize, leads to a consideration: when you were calling upon Intuit to produce Quicken for Linux, did you expect them to open source it?)

But wait -- there's more: Kivio 1.0 is near. This is theKompany.com's flowcharting application, a Visio killer, that will be part of KOffice, with additional stencil sets available for sale, though users may of course develop their own. Also due is the first beta of ReKall, a database application for KDE.

For developers, beta three of KDE Studio Gold, an integrated development environment, and QScintilla, a port of the popular Scintella source code editing environment to QT, will be along shortly.

If Linux on the desktop is a nonstarter, theKompany.com hasn't heard about it, either.

Memo to Distributions: Get a Clue

Anyone who has followed this column for the last several months (and I thank you and applaud your patience and, perhaps, your stomach) will see a trend beginning to emerge here. It is no surprise that Linux distributors, putting in a colorful box some CDs containing a Linux distribution that was neither optimized nor documented for any particular purpose, did not make a lot of money. Or, in most cases, any money. Some things are obvious: date somebody who's married and it will turn out unhappily; market one-size-fits-all Linux and -- well, you might as well date somebody who's married; at least there's probably a good dinner or two in it for you.

Sense suggests that contrary to the current prevailing view there is plenty of room for a desktop-optimized Linux distribution. And the recipe is not at all tough. It's so easy, in fact, that I've built one right here, on my desktop machine, no big deal. What does it comprise?

A great desktop, your choice. I favor KDE; there are those who for reasons I do not fathom, prefer GNOME. Fine. Just pick one and throw yourself behind it. Equip it with the latest XFree86 you can get your hands on. Give it a very recent kernel, and don't get cute with the kernel code. Make every imaginable module available. Don't load the system up with services that are of use only to the enterprise. Apache is great, but desktop users have no need for it, and those who use it anyway to host their own websites are delusional, so you can ignore them. And don't turn anything on by default. If you want to send an invitation to crackers, take out an ad or something.

Do provide development tools. "Desktop user" and "total moron" are not synonyms. There will be things that will undergo major upgrades between the time you freeze your code and the time the boxes hit the shelves -- and not everybody will buy it the first day. If you want to do something cool, make a nifty little graphical application that sits atop the compiling process (prompting for the root password up front, so that "make install" will work). If you need to have some kind of package manager, become friends with Debian and use theirs (and tie in your compiler front end, because otherwise a lot of users will break your precious database the very first day, and everybody will eventually). And for Heaven's sake, provide documentation, good, thorough, readable documentation.

Make sound work. That's a tall order, but it's important. About half the sound problems are permissions issues. Sound is something that desktop users want and a lot of enterprises, seeking to prevent office-related homicides, don't. Do the same for OpenGL. Desktop users are not allergic to games, and even those who are will be pleased by the latest XScreensavers. If for some reason your install program, which oughtn't presume your users are idiots but ought to presume that this is the first time they've seen Linux, can't install working sound or GL (or anything else), provide both a screen explanation and a file in the user's ~ directory, giving details. Users might not understand it now, but it will help them later.

Revamp support. No, it's not ever going to be a profit center for desktop Linux. But you can keep users happy for very little money. How does KDE provide support? Through mailing lists. So set up a support mailing list. Find something else for the people who don't answer your support phones to do, and instead assign a couple of people to the mailing list. These need to be relaxed, non-authoritarian folks, because there will be times when the discussion will turn to the best way of making barbecue or who can endure the hottest chile peppers. Clue: these are signs of community, and that's exactly what you want to achieve. And you want your people there to be part of that community, but always ready to go looking for an answer to an urgent question.

And don't be surprised when in due course every other distribution decides to do the same thing. It won't last.