We’re finishing up the Kylix book (Kylix Power Solutions, with Don Taylor, Jim Mischel, and Tim Gentry, published by the Coriolis Group). We had originally planned a chapter on interfacing with the KDE and GNOME desktops to provide things like desktop icons, docking apps and such, but that turned out to be a major job worthy of several chapters, if not a book in itself. Our backup plan was a chapter on providing application help, and it falls to me to write this one.
Stepping up onto soapbox
Like it does with everything else, the Linux world has about a zillion different ways to display online help. There’s KDE help, HTML help displayed in a web browser, man pages, HyperHelp, and Heaven knows what else. Perhaps No Help is the most popular. Also par for the course, this flexibility ends up costing on both ends: developers have to decide on a help system and ship the viewer with their applications, and users have to install yet another help viewer on their computers. I fail to see how this is better in any way than Windows which for years had a single standard help system that was guaranteed to be on every machine. Under Windows, developers are free to supply their own help systems if they like, but most choose to use the built-in WinHelp. Microsoft complicated matters a few years ago when they released HtmlHelp and “deprecated” WinHelp, but WinHelp is still there and used by many applications. Users especially like having a single help system interface. Getting a standard help system for Linux GUI applications is almost as likely as settling on a single desktop standard. I suspect I’ll find a winning lottery ticket in the trash before something like that happens.
Stepping down
Borland did an excellent job supplying Kylix with a flexible help system interface. The HelpIntfs unit defines a handful of interfaces for developers to derive Viewers for individual help systems. The online documentation of these interfaces is a bit sketchy, but what the help files don’t explain fully, the sample applications (a HyperHelp viewer and a man page viewer) make abundantly clear. The help viewer interface works behind the scenes of an application, serving up help topics in response to requests from the Help Manager, which is invoked by users’ actions. The application’s interface to the Help Manager remains constant regardless of the underlying Help Viewer. It’s a very elegant solution to a thorny problem. By supplying these interfaces, Borland has made it possible for developers to create applications that can easily switch their help file formats, making it easier to keep up with emerging (ha!) Linux help systems.