Next Previous Table of Contents
The next pages will use a language that is usual among gui developers, for example, the word widget . A widget is everything you see on the screen, a button, a window, a scrollbar, a menubar, etc. As you can see, some widgets even contain other widgets inside of it . From a developer point of view, you can think that every specialized widget inherits a base widget class, that is, the QWidget class.
The layout of widgets is then, the way widgets are placed on the screen, one under another, one beside another, etc.
I'll try to explain the rest of words as they appear.
I'm using in this sources the autoconf/automake applications to generate Makefile files . There are many complex scripts made mainly by Stephan "coolo" Kulow. These scripts have been copied from the standard KDE packages and modified a little to be used in this tutorial.
"make -f Makefile.dist" will generate the configure
script and the Makefile.in files in each directory using the respective
Makefile.am file. To complete the operation, you'll need the autoconf/automake
packages installed on your system. In this step, Stephan makes some magic with
the scripts in order to get automatically some things done instead of having
to explicitly write a bunch of rules in each Makefile.am
When you run
"./configure" the Makefile files are created using
the recently created Makefile.in files as templates.
Now you can really run
"make" to build the binaries.
As you'll read later in the tutorial, some files will have to be preprocessed by the meta object compiler, moc. To use moc, you just have to use a trick, which is to use the following definition in Makefile.am :
METASOURCES = AUTO
The scripts that generate the final Makefile file will parse it and generate rules to create these files using moc.
The final code that process the meta object sources in Makefile is something like the following one :
p3.moc.cpp: $(srcdir)/p3.h $(MOC) $(srcdir)/p3.h -o p3.moc.cpp
Similarly to this, in p6, p7 and p8 it will be needed to use a preprocessor for the DCOP interface of these applications. This is done with the following commands :
dcopidl appIface.h > appIface.kidl dcopidl2cpp --no-stub appIface.kidl
This will generate an appIface.kidl file with a xml definition of the application interface, and a C++ file called appIface_skel.cpp with the skeleton of the Interface ready for you to implement it. If you use to do CORBA programming, you'll probably find this naming scheme of skels and stubs very familiar.
If this tutorial is of any use, after reading it you'll start your own KDE application. If that's the case, you'll probably face new problems which aren't described in these pages, that's why I've put here some notes, addresses, urls, etc that might be useful to get some help.
Qt comes with the best documentation that I've ever seen. Have a look at it whenever you wonder what a class does, or when you want to know if there's a method that does something special that you need.
I have the Qt documentation directory in the bookmark list of konqueror, so that I can access it fast when I need it.
The KDE libraries are not far behind, and also come with a lot of documentation, which you can download from http://developer.kde.org/documentation/library/2.0-api/classref/
If you cannot download the docs or don't want to download a big package, you can generate the documentation for yourself from the sources of the kdelibs by using KDoc. KDoc is a documentation generator from special tags in the sources that can generate html output as well as latex, docbook, man, etc.
The commands I use to generate the documentation are the following two:
qt2kdoc -u "http://localhost/~antonio/docs/qt2" -z ~/kdeCVS/qt-copy/html \ -o ~/.kdoc makekdedoc --srcdir ~/kdeCVS/kdelibs/ --outputdir ~/public_html/docs/kde2 \ --url "http://localhost/~antonio/docs/kde2"
Note that I have the Qt sources under $HOME/kdeCVS/qt-copy and the KDElibs sources under $HOME/kdeCVS/kdelibs . I also have a local web server that uses $HOME/public_html as index directory for http://localhost/~antonio . Finally, there's a symbolic link from $HOME/public_html/docs/qt2 pointing to the html directory on the Qt sources .
With the previous commands, kdoc generates over 11 Mb. of documentation under $HOME/public_html/docs/kde2 , which I can access easily using konqueror or kfm by going to http://localhost/~antonio/docs/kde2/<library>
qt2kdoc is a tool that parses the Qt documentation and generates an index that is used when generating the KDE docs with makekdedoc . This way kdoc can create hypertext links from the KDE documentation to the related classes on the Qt docs.
If you want to join KDE, feel free to suscribe to the KDE mailing lists that are most interesting to you.
If you're a programmer, this is most probably firstname.lastname@example.org, if you want to draw icons, you can join the artist team, if you want to translate KDE to a language, you can join the translation team, etc.
All the mailing lists are specified at www.kde.org/contacts.html, you can read there the instructions on how to suscribe.
Also, you can have a look at the developer.kde.org pages, which have very complete information for the KDE developers, including manuals, the documentation (tarred for download), tutorials, etc.
Our styles guru, Mosfet, has a home page which he updates regularly with the latest development news, you can check it at www.mosfet.org
I'd like to make a recomendation to those of you that are looking for an IDE which you don't have to abandon in any moment of the development of an application. KDevelop (which you can find at www.kdevelop.org) may be very useful to start developing a KDE application.
KDevelop is a complete IDE to develop applications (KDE, Qt or console apps), it features syntax higlighting, visual dialog editor, integrated debugger, application templates, integrated CVS support, translation support, icon editor, and many more features.
I wouldn't like to end this introduction without talking about the user interface guide which you can find at the developer.kde.org site.
On the following pages, I won't follow the UI guide as close as I should, in favour of simplicity. I suppose there's no need to say that every KDE developer developing a real application (not a simple tutorial) should read it completely and follow it as close as possible. The reason for this is obvious.
With nothing more to say, let's start the tutorial !