|
 |
|
The K Desktop Environment (KDE) is one of the largest and most successful Open Source projects. KDE users number in the millions and they depend on the stability of KDE every day. With such success, it would be easy for the KDE developers to sit back and savor their accomplishments. After all, the original goal for KDE described an intuitive and easy to use Unix desktop. With the award winning 1.1 release, KDE fits that bill almost perfectly. There is still work to be done, however. The current development pace has increased, rather than diminished. This article will try to describe some of the major features that users can expect out of KDE 2.0. The over-riding trend that carries though all of these changes is increased configurability, power, and ease of use to both the end-user and the developer.
KOM/OpenParts -- Ready for the Big Time
KOM/OP The amount of CORBA integration will vary by application. The biggest current and future user is the KOffice suite (more on that later). A close second is the Konqueror file manager/web browser. Actually, it's not quite accurate to describe Konqueror only in those terms anymore as it does so much more. Konqueror is built on the OpenParts part of KOM/OP. A "Part" is a CORBA object that can be "embedded" into other CORBA applications. The effect is similar to DCOM, OLE, and OpenDoc. For instance, when Konqueror comes upon, say, a JPEG graphics file, it checks with the mime-type registry to see how to handle it. The mime-type dictates that an "image viewer" is needed with certain properties. Konqueror then forwards these properties to the KDE trading service. The trading service "finds" an OpenPart -- a CORBA-enabled application -- that fits those properties and activates it. The activated OpenPart image viewer will then open up "embedded" into Konqueror. Konqueror's menus and toolbars will be replaced (or supplanted) with the Part's menus while it is displaying the image. From the user's point of view, it will look like the image viewer is part of Konqueror, not an entirely separate application. This leads to an almost "plug-n-play" method of using components. In the past, a file manager would typically have the image viewing code hard-coded into the application or linked through a library. Changing this code meant, at the least, recompiling everything. At the most, it could mean a massive re-write. With the KDE trading service and the OpenParts model, components are known by their properties. This means that changing the image viewer component is as easy as registering the new component with the proper properties. No recompiling or recoding is necessary. A lot of components don't need the graphical functionality that OpenParts provides. Often, the KOM layer or even straight CORBA is enough. An example of this is the Internet dialer component. Any application that wants or needs to connect to the Internet via a dial-up connection can do so using this component. They access it by requesting a dialer with certain properties from the trader. Note that this means that no one application is tied to being The Internet dialer. The current implementation uses KPPP, the KDE modem dialer, to do the dialing, but it doesn't have to. The actual method of dialing is irrelevant to the application using this component -- they just want the resulting connection.
KOffice Suite The individual KOffice applications are fully functional even as stand-alone apps. KWord is a "frame-based" word processor in the vein of FrameMaker. This makes it acceptable for use as a desktop publishing app, in addition to it's complete word processing abilities. KSpread extends its already large collection of built-in mathematical functions with Python scripting support. Users can construct arbitrarily complex KSpread documents in a manner similar to VBA-enabled Excel documents. There is little that PowerPoint does that KPresenter cannot do. Even with all of this individual functionality, the true power of KOffice can only be realized with its integration as a whole. Because all KOffice applications are built on KOM/OP technology, each app can be used as an OpenPart. That is, it is possible to "embed" a document from one KOffice part into another. For example, say a user is working on a KWord document when she realizes that a table with a spreadsheet and chart in it would add a little visual punch. She can do this by importing an entire KSpread spreadsheet and KDiagramm chart. This isn't a static cut-n-paste, though, an actual KSpread document is embedded into the document. This means that the user can dynamically manipulate the spreadsheet and chart without leaving the KWord document. Clicking on the spreadsheet causes the KWord menus and toolbars to be replaced with the KSpread versions. Clicking outside of the spreadsheet restores the originals. From the point of view of the user, all parts of the document are all integrated fully inside that document. They no longer appear to be separate parts from separate applications. A much more detailed look at the KOffice suite can be found at http://www.mieterra.com/article/koffice.html
Look (and Feel) At Me Now
"Themes" The first and most obvious change will be the ability to customize the look of each individual widget. The current widget styles of Windows9x and Motif will join NeXT, MacOS, Java Metal, and every other possible style one could imagine. Likely, there will also be many styles that aren't quite imaginable yet! The ability to customize the look, size, and actions of each and every widget is nearly total. These widget styles will be included in "pluggable" libraries that can be distributed in binary or source form. To change to a different style, one would simply have to drop in the correct library, go to the theme/style manager and their desktop will assume an entirely new look. It will not be required to recompile anything to use a new look -- all styles are dynamically loaded at runtime. This is true "plug-n-play" theming. On a technical level, these styles are not pixmap based. That is, the underlying graphics system does not need to use pictures for all of the widgets. This approach is very slow on even high end machines. The KDE/Qt approach uses virtual functions for all of the widget drawing. The result of this is widget drawing at nearly the same speed as the "original" or default style (the actual speed depends on the complexity of the drawing). Note that pixmaps may be used if so desired -- the theme engine just does not depend on it. The themes will go beyond widget styles, however. All visual aspects of the desktop will be controlled from one central location. Say a user wants their desktop to look as close as possible to a Macintosh. One click in the theme/style manager will cause the widgets and color scheme to have the Platinum style. The icons will be replaced with "Mac-like" icons. The window borders will also change to look like a Mac. If that weren't enough, the key-bindings would also change to be comfortable to a Mac addict. Most of these changes are already possible to accomplish with the present tools. What is lacking now, however, is an integrated and central way of managing all of this. The future theme/style manager will allow the user to customize everything with only a few clicks of the mouse.
More KDE-Aware Apps Probably the biggest segment of new applications will be applications that traditionally are found only in the Windows/MacOS world. These applications will be either "clones" of popular Windows apps or applications that have never been thought of before. A growing number of "third-party" or commercial applications will be "KDE aware" without being fully integrated into KDE. The StarDivision StarOffice suite already does something similar with its recognition of the KDE mime-types, KDE drag-n-drop and an awareness of the panel. This trend can only continue. Many legacy X and even console-based applications will also get fresh KDE wrappers around their older interfaces. This will happen either by taking the "work" part of the code from an application and putting a KDE GUI on the front of it or by grafting a CORBA wrapper around it. This latter approach will be used most often for console-based utilities that have command-line interfaces. A CORBA wrapper will be put "around" this utility, making it into a server. Any KDE app will then be able to access that utility's functionality in a manner consistent with all other CORBA apps.
Playing the Politics Game
"Open Source" Qt The effect of this is nearly entirely political. Those users that did not use KDE solely because of Qt's license may now use the system with no problems as to it's freeness.
GNOME Acceptance This starts with "cross-theming." The GNOME/Gtk+ method of handling widget styles is currently done with pixmap "rendering engines". The KDE theme manager will automatically detect the configuration files for GNOME apps and modify them in such a way as to create an as close as possible approximate of the current Qt style. Other "theme" components such as key-bindings will also be approximated on the GNOME side. The drag-n-drop protocol shared by the two environments will also be standardized. That means that files "dragged" from, say, the KDE file manager can be "dropped" into a GNOME application with no problems. Interaction between KDE and GNOME applications will also be much improved. The higher-level CORBA protocols will either be standardized or wrappers will provide an illusion of standardization. As a general rule of thumb, the standard user should not be able to find any significant differences between a KDE and a GNOME app while running the KDE environment. Kurt Granroth is a software engineer with the Motorola Satellite Communications Group in Phoenix, AZ. He holds a B.S. in Computer Science and Secondary Education from Michigan Technological University. Kurt is a recent member of the KDE Team and is responsible for KBiff, KAppTemplate, numerous hacks in the KDE libraries, and overall KDE evangelism.  
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
|
|
|
| All times are recorded in UTC. Linux is a trademark of Linus Torvalds. Powered by Linux, Apache and PHP 
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Whitepapers and eBooks
|
