18.2. Creating KDE 2.0 Applications

Now you'll start with a sample session of creating a first KDE application that is compliant with the KDE 2.0 API and offers the already described Autoconf/Automake framework. As usual, whenever you're creating a new project with KDevelop, from the Project menu choose New. Then the Application Wizard of KDevelop (see Figure 18.4) will help you define the type, the name, and other properties of your new project:

After selecting the desired project type, you get a preview of the application as it will look after generating and compiling the source code, and a brief description. The next page lets you set the different project settings, such as the name, the initial version, the author name and email, and the directory where the project will be generated. The lower section allows you to select which additional features you need; API Documentation, User Documentation, icons, linkfile, and even the source code itself can be deselected if you want to start your application from scratch. The third page of this wizard allows you to enable CVS support on the initial generation. You should notice that this is restricted to be used with a local CVS repository. If you intend to use a dedicated nonlocal CVS server, you have to do the import of the generated source tree separately with a tool such as Cervesia. After the source tree is on the CVS server's repository, you can then check out again to work on a local copy with KDevelop.

Figure 18.4. The KDevelop Application Wizard.

Cervesia is included in the KDE Development Kit provided by the KDevelop Project. The kit contains all the KDE tools needed to develop specific KDE applications.

If you're a developer who works alone on projects, local CVS is always a good option because it gives you the full power of version control on your standalone machine.

The fourth and fifth pages of the wizard allow you to define the header for generated files. The header of a file is usually a comment that includes the filename, the date of creation, the author's name, and a license notice for the file. The default is good enough for most developers because it uses the GPL as a license, but you're not restricted to that—you can change the license notice either directly in the preview editing window or load an already existing template for your file header.

Page six is the last page of the wizard. Here, you click the Create button to start the generation of the project. If the button is not enabled (selectable), you've probably not filled in a setting, such as the project name. The project will then be built as defined; you'll get the output of the processes in the upper window, and errors are displayed in the lower one. The Finish button will be available if the project has been built successfully, bringing you back to the KDevelop project editor that automatically loads the generated project to let you get started with programming your KDE 2.0 application (as shown in Figure 18.5).

Figure 18.5. The KDevelop project editor after generating a KDE 2.0 application with the Application Wizard.

You've seen how easily you can get started with developing your applications for KDE—fully based on a graphical user interface that automatically solves beginners' as well as experts' problems—to set up a complete framework for a project that conforms with Autoconf/Automake, includes pregenerated source files and running code, license, documentation, and even version control!

18.2.1. Available Templates for KDE 2.0 Projects

The KDevelop Application Wizard generates your project by application templates. These are predefined packages that run "out of the box" after generating. For KDE 2.0, programmers can choose from three types of application frameworks:

KDE Mini application—This generates an application that has the usual Autoconf/Automake framework with a single window (an instance of a QWidget inherited class that the project contains). This type of project is used mostly by programmers who want to start their application from a very basic code tree to create programs such as a kcontrol module, a wizard, or an application that needs only one window as the main GUI interface.
KDE Normal application—The KDE Normal type of framework offers the predefined automatic configuration files and a source tree that contains three classes that build up a document-view interface. Therefore, these classes are
- projectnameApp—. This is the base class for the application window, derived from the KTMainWindow class of the kdeui library.
- projectnameDoc—. This is the base class for the document instances. The Doc class takes the part of loading and saving a document as a file, and it takes care of providing the interface to access the document data to other classes and instances. This class is derived from QObject because it isn't necessarily a window, but more a general tool class that deals with data structures; it should be able to communicate with other application instances via the Qt signal/slot mechanism.
- projectnameView—. The view class, on the other hand, is directly derived from QWidget because it represents the "view" in which the user of the application sees the document data on the screen. Therefore, the instance of this class is directly connected to the document instance that provides the data or at least a data area into which the view class can write. The conclusion is that a Doc-instance could live without a view, but a View-instance could never live without a Doc-instance; otherwise, it would attempt to write into areas that don't exist!
You should, however, notice that this kind of application type is designed to build a Single Document Interface (SDI) framework. SDI means that one application main window can handle only one main view area that takes care of one document instance. That raises the issue that a separate document class may not be needed that much, but it is always a good style to create the classes of an application that take care of one special task.
KDE-MDI application—Because the Qt library provides a child window class (QWorkspace) since version 2.1 (which is used by KDE 2.0), we implemented a fully functional Multiple Document Interface (MDI) application framework that is also based on the Document-View model. Nevertheless, the Qt library lacks classes that are specifically designed to take care of the document part of applications, so the document class is again derived from QObject.

Now you've seen that KDevelop offers a variety of frameworks—even specialized for KDE 2.0. These frameworks are also provided as Qt-only based applications, which make it possible to directly port commercial applications to operating systems using Qt in conjunction with their professional license or to compile a version that runs with the new Qt/Embedded library for embedded systems.

18.2.2. Editing Your Project

After project generation, the usual development steps will take place within KDevelop. You're provided with the Classbrowser, the Classtools, the file viewers to navigate within your project sources, and the internal KWrite editor to edit the sources. The New and Edit menus should give you the most-needed editing commands, and you can configure the syntax highlighting of the source code and other options, such as the printing configuration, in the Options menu. Furthermore, one of the most useful tools for editing is the Search in Files dialog option available in the Edit menu, which lets you look up expressions all over your project tree. The results are listed in a box within the dialog, allowing you to go directly to the location of the matching file and line.

Maintaining your project is very easy. The New File dialog lets you create a whole set of predefined file types, such as source files, desktop files, docbook documentation, pixmaps, and the like. Classes can be created on-the-fly with the New Class dialog, including a file header; inheriting a class automatically adds the needed include statement, as well. Source files that you've created already can be added to the project directly with the Add Existing Files functionality. After each time you've added a file to your project, the KDevelop project- management system automatically updates the Makefile.ams and takes care of the configuration process.

File properties make it easy to set the installation destination for resource files such as pixmaps.

You see how easy project maintainance gets when you use KDevelop; you just have to take care of the code you're writing.