18.1. General Issues

Before going into the details of the IDE, let's first cover some issues that apply to development using the C and C++ programming languages in UNIX environments in general.

As you have learned, C++ is commonly used to develop KDE software. This is necessary because the Qt library on which KDE is based is also written in C++ and therefore offers interfaces to the library by C++ classes. KDE extends the Qt library by far and implements many things that are either missing in Qt or that are useful for a UNIX desktop but not on a Microsoft-based operating system. (Qt is a cross-platform toolkit, and applications written with Qt can be directly used under MS-based operating systems, either by recompiling on that environment or by compiling with a cross-compiler as a Win32 binary.)

You can, however, make use of other languages (especially scripting languages) that have a set of bindings that translates the Qt/KDE C++ classes to the other programming languages such as Python or Perl; therefore, KDE is not limited to using C++, although it is the preferred way to write KDE software.

The second issue that applies to software development is project management. An application usually consists of more than one source file, and compilation on different systems usually requires different settings for things such as compilers, paths to header file locations, and linker settings to bind all compiled object files to a binary. As you learned in Chapter 16, "Packaging and Distributing Code," the management of all this is done via make. Writing Makefiles by hand is usually not a trivial task, and if they are specifically written for one development environment, you can never be sure that the same rules apply to any other system—not even another Linux distribution. Because of this, the GNU tools offer a development framework that automates much of the project management but still requires the developer to lay hands on the project-specific parts of the framework, which is again non-trivial.

The tools that help here are the Automake and Autoconf packages, which sometimes make things a bit simpler; however, sometimes they cause headaches because the developer wants to use C++, not fuss with Makefile generation and configure scripts. At least they ensure that the source distribution will compile automatically on almost all UNIX systems such as Linux, SCO UNIXWare, HP-UX, and the like without much trouble. This is an issue because developers like their applications to work under as many systems as possible.

You should know that when you retrieve a source package of KDE and most other applications that are available as source code for UNIX systems, you will have to compile it yourself. This has two advantages: First, the binary is specifically built on your system, and when it is cleanly built, it will run without any trouble. Second, it will install smoothly where you want it to.

Topackages:creating build a package, follow these steps: untar the package.tar.gz file and change to the created directory containing the source files; then enter ./configure and make on the console. After that, you can install the software package as root with entering make install. This makes things so simple that even complete UNIX newbies who will probably never be interested in writing applications themselves are able to compile and install a source package. The developer, on the other hand, doesn't have to provide so much support for the installation process of the application on the user's platform, but only for the functionality.

The magic behind this is that the developer has to provide the source package only as Autoconf/Automake compatible. To write this framework, you need some knowledge that is not necessarily the developer's job—and this is where an IDE can help. It can provide programmers with the comfort of creating a complete framework and take care of the project management during the process of creating an application.

Another important issue is handling make and the compiler, as well as the linker, to produce the executables or libraries. These are command-line tools that require the knowledge of the according options, which are most often very cryptic and have to be learned and are easily forgotten. On the other hand, an IDE can "remember" these things for you. An example is the following scenario: while developing your application, you will most likely program an error, and you will have to debug the binary to follow the code while executing to find exactly where that mistake happens. This requires telling the compiler to include debugging information into the binary. Then the debugger can translate the function calls in the binary to the according lines in the source files. But you will also want to switch back to optimized compilation, even if it is only to test whether everything works as expected at a reasonable performance. Here, a simple menu that says debug/release within an IDE helps enormously—even more so if it allows you to debug your program with setting breakpoints directly in the source-code editor and running a debug session within the programming environment.

Accessing documentation is the third element where an IDE can help you as a developer. Especially when using large C++ class libraries such as Qt and KDE, you will get lost without a good access to the API documentation. Fortunately, the Qt has excellent documentation, and the documentation for the KDE libraries can be created easily with the KDOC documentation tool. KDOC also can be used to document your own project, as you learned in Chapter 15, "Creating Documentation."

Because the documentation as a whole is used as HTML files, a development environment without an IDE will look like the following: an opened browser to read the documentation, a shell to run the compiler, and one or more editor window to write the code.

After this horror scenario, which is what long-time UNIX developers have lived with for years, let's have a look at what you can expect when using KDevelop to create your applications.

18.1.1. Be User Friendly—Be Developer Friendly Why should users have all the ease of use when working under a graphical environment like KDE for production, such as KOffice and all the other KDE applications that make life easier, but the developers who are writing this beautiful software suffer and look at the "normal" user jealously? That's why we made KDevelop—for programmers who dislike working under UNIX the "old" way, who want to save time and be more productive, and who also like not only the results of their work but also how it is done. Often, new developers coming from environments that offer development systems based on a graphical user interface are afraid to switch to UNIX because they don't want to miss a comfortable environment. In the next sections, we'll walk through the KDevelop IDE to see what it looks like and what functionality is available. When you first glance at KDevelop in Figure 18.1, you'll notice that it looks much like other KDE applications—the main window contains the usual user interface with a menubar, toolbars, a statusbar, and a central view area that is separated into three subwindows. Figure 18.1 shows KDevelop 1.2, which is actually for running under KDE 1.1.x, but as you can see, the desktop it runs on is KDE 2.0. You may wonder what a KDE 1.x application has to do with this book covering KDE 2.0, but there is a simple answer: the 1.x series of KDevelop has been developed to be the most stable development environment so far, and we put forth a lot of effort to make it as usable as possible—even for KDE 2.0 development, which is directly supported. After two years of development, testing, and successful usage in industrial environments, KDevelop has proved to be an excellent, stable, and very friendly IDE that is today the developer's choice when starting to program with C/C++ under UNIX. Meanwhile, the KDevelop 2.0 IDE is under development by the KDevelop Team and will be made public when it reaches the same amount of functionality and stability as the 1.2 version (see Figure 18.2). Figure 18.1. The KDevelop 1.2 main window. Figure 18.2. KDevelop 1.2 editing a sample project's options. With KDevelop 2.0, our team will break with the traditional single-window philosophy commonly used by UNIX applications, and that is what developers have to expect: complete configurability and visibility all over the user interface of the IDE. This will make KDevelop even more attractive to users coming from other platforms and make the transition to UNIX much easier, further reducing the learning curve for handling the programming environment. Until the release of KDevelop 2.0, we recommend using version 1.2 for production. It offers almost everything developers expect, especially stability and usability. 18.1.1.1. The KDevelop User Interface As seen in Figure 18.1, the main window of KDevelop is separated into three subwindows. Each has a certain purpose and can be resized, enabled or disabled, and automatically switched on and off by a built-in autoswitch function. 18.1.1.1.1. The Tree View The left pane contains one major part called the Tree View. It is created as a tabular window containing several pages: The Class Viewer (CV)—Here, the C++ classes, C functions and structs, as well as namespaces of your project are displayed as a tree, which allows you to dive directly into the source files at the location of declaration and definition of attributes, functions, classes, and namespaces. The tree is initially built when loading a project by an amazingly fast-scanning implementation and actualized during automatic and manual saving to rematch location changes and added code to the displayed objects in the source files. The Logical File Viewer (LFV)—The LFV sorts all project files into groups dependent on their MIME type; for example, all C++ source files are collected into a folder called sources, and all C++ header files are found in a folder called headers. New groups can easily be added via a context menu specifying the name of the folder and the file types to be collected. The Real File Viewer (RFV)—Displays the project directories and files as they are located on your system and displays all files along with their status within the project as "registered" and "CVS" or "local." The Documentation Tree View (DOC)—Offers easy access to all documentation available on your system: the KDevelop handbooks, the Qt library documentation as well as the full KDE-API documentation, project documents, and self-configured additional documentation. The library documentations can be accessed down to the location of class-member function automatically opening the right page in the Documentation-Browser. The Variable Viewer (VAR)—Active while debugging your application with the internal debugger. Here the attribute values of your application's class instances are displayed during runtime in a debugging session. The Tree View is one of the most effective parts of the KDevelop user interface, offering the logistics to your project, information, and localization of source code from the "object-oriented" point of view. 18.1.1.1.2. The Output View At the bottom of the KDevelop main window, you see the Output View. This is the second helper window that you will make use of often. Like the Tree View, it contains several pages, each for a certain purpose: Messages—Any output that comes to KDevelop when running tools such as make or the KDOC documentation program will be displayed here. The messages window also brings you to the location of errors by clicking the error line of the output. Stdout—When starting your application from within KDevelop, it sends all output you would see normally on a console into that window. Thus, you can control the behavior in a way most developers do when using the cout function to get status information at runtime. Stderr—Here, the started application will put its information that is sent out via the cerr function to monitor error messages. Breakpoint—Lists the breakpoints set in the source files and monitors how often the application reached the breakpoint during a debugging session. Frame Stack—Lists the calling stack of the currently monitored application or function together with addresses. Disassemble—A machine-instruction view that displays the currently executed code in assembler language. The Output View therefore offers you the most information about the status of other applications, including the application that you are programming. Additionally, you're offered exact debugging information as well as an error-locating mechanism that brings you to the right place by a single click on the error line. 18.1.1.1.3. The Working Area The window that contains the actual editor is called the working area and is placed at the right of the Tree View and above the Output View. This window is again split into several pages: Resource/Header Files—The first editor window, displaying C++ header files and any other file that is not a source file to be compiled like normal text files. C/C++ Files—The second editor window for opening and editing C/C++ source files (*.cpp- files). Source files can be compiled separately without rebuilding the whole project when the file to compile is loaded into this editor window. Documentation-Browser—This window is an HTML browser like KFM and is used together with the documentation tree to open the documentation for you. Results from search requests over the documentation will be displayed here for direct browsing, as well. Tools—The Tools window is an embedding area for other applications that can be started from within KDevelop, such as KIconEdit, KTranslator, Cervesia, and the like. 18.1.1.1.4. The Dialog Editor Because KDevelop aims to focus on KDE/Qt developers, it contains a what-you-see-is-what-you-get (WYSIWYG) Dialog Editor that integrates seamlessly into the IDE (see Figure 18.3). The Dialog Editor can be accessed either automatically when opening or creating a dialog file or via the menu item Dialog Editor. Figure 18.3. The KDevelop Dialog Editor with a sample dialog ready for editing. The Dialog Editor has several advantages for a KDE/Qt developer: it lets you directly create, edit, and build GUI components and includes a preview functionality. The user interfaces can then be directly used within a project and adapted to further functionality needs. This is very easy because you can set all available properties for a GUI component, such as a push button, on the right in the Properties window. After creating a user interface, KDevelop creates the according source files in C++ as a class derived from classes provided by Qt, such as QWidget or QDialog. Thereafter, the developer implements the signals and slots into that class and adds the instantiation for calling the dialog at the desired place within the application's source code. By that, developing user interfaces for your applications is as easy as it could be with the simple steps of visually designing them and generating the source code afterward. It cannot be denied, however, that the current Dialog Editor has one weakness that may require you to re-edit the source code output. Because it can handle the creation of user interfaces only on the basis of fixed geometry measurements, your application will have problems with translations if the texts are longer than your English originals. This will cut off the ending, for example, on buttons and labels if these are too short to display the full translation. Thus, you need to make use of the geometry management functions provided by the Qt library and implement a layout by yourself, separated from the default output of the Dialog Editor. You will read more about the Dialog Editor later on when you'll have a closer look at actually developing a KDE application with KDevelop.