The easiest way is to use kdesdk/kapptemplate or kdevelop to generate the Makefile.am . Or you can just copy a Makefile.am from another app and install it in a new toplevel directory of existing KDE sources. Or you can start the old way, from scratch, but you'll miss the power of the autoconf/automake framework.
Check developer.kde.org, especially the architecture documents. Check also the kde book.
Well, you are not forced to but it is a _lot_ better. KPart allows powerful code reuse. Dcop allow scriptability and is very powerful. Given how simple it is to use these technology and how widely they are deployed, it is a shame not to use them if you can.
The guide on how to write Makefile.ams is now a separate document, makefile_am_howto.
It uses autoconf and automake with another layer by the means of a program named am_edit. But don't try to understand how to use all that. It is quite complex and the strength of KDE is that you don't actually need to understand that stuff, a core-developer already did that for you. Basically, automake transforms the Makefile.am into a Makefile.in, then am_edit runs and replaces in the Makefile.in all the KDE-specific tags with their real meaning, and configure will create a Makefile out of the Makefile.in
Because KDE is using the GNU tool called "libtool". So the question forks into two: "Why use libtool?" and "Why does libtool create .lo and .la files, and shellscripts?". KDE uses libtool for portability reasons. libtool takes care of the differences between the compilers and especially linkers on various platforms, so that we don't have to bother with that, even when writing shared libraries. The .lo and .la files are used by libtool to add some information (read them, they are plain text), about object files and libraries. For instance, it remembers which libraries a given library depends upon. Without it, we'd still have to write link lines such as -lkparts -lkio -lkdeui -lkdecore -lqt -lXext -lX11 etc. etc. So you may find it a bit strange that things are "hidden" in .libs, but the gain is huge: complete portability, at no cost for the developers.
Use make -f Makefile.cvs It will run all the Makefile generation steps
While hacking a program it might be useful to exclude certain directories from build that would otherwise be recompiled, but don't actually need to be. Also, if you checked out source code that didn't compile and you don't have the time or knowledge to fix the error you might want to turn off compilation of the directory alltogether. There are two cases. Toplevel directories, and subdirectories. For toplevel directories you can simply erase them (or not check them out).
If for some reason you don't want to do that, you can also set DO_NOT_COMPILE="someapp" before calling configure, this will make configure skip "someapp". To only compile very few toplevel dirs, instead of using DO_NOT_COMPILE to exclude most of them, you can list in a file named 'inst-apps', at the toplevel, the toplevel subdirs you want to compile. To turn off compilation of any directory, including subdirectories, you have to modify the Makefile or Makefile.am files. Makefile.am is not recommended because that file is in KDE Subversion and you could accidentally commit your changes. So we'll modify the Makefile instead here:
Open the Makefile in the directory immediately above the directory you want to exclude in a text editor and look for a variable SUBDIRS. It will often look somewhat like
SUBDIRS = share core ui . proxy taskmanager taskbar applets extensions data
SUBDIRS = $(COMPILE_FIRST) $(TOPSUBDIRS) $(COMPILE_LAST)
Here you have to find the COMPILE_FIRST, TOPSUBDIRS and COMPILE_LAST variables. One of those contains the dir you want to exclude. Remove the directory where you find it and save the Makefile again. To undo your changes you can either regenerate the Makefile from scratch or revert to an older backup (you did make one, did you? :-). To regenerate a Makefile, just make force-reedit.
Add debug symbols, disable optimisations and turns logging of kdDebug() on.
The opposite of the previous one: enable optimisations and turns kdDebug() logging off.
Concatenates all .cpp files into one big .all_cpp.cpp file, and compiles it in one go, instead of compiling each .cpp file on its own. This makes the whole compilation much faster, and often leads to better optimised code, but it also requires much more memory. And it often results in compilation errors when headers included by different source files clash one with the other, or when using c static functions with the same name in different source files. This is a good thing to do at packaging time, but of course not for developers, since a change in one file means recompiling everything.
By default KDE uses perl instead of sh and sed to convert Makefile.in into Makefile. This is an addition to autoconf done by Michael Matz. You can use this option to disable this but it is a lot slower.
If you are a developer, you should definitely compile Qt and KDE with --enable-debug. You will then be able to debug your program even inside Qt and KDE function calls. If you are just a user, you can still use --enable-debug. KDE will occupy more space on your hard disk but it won't slow down your desktop. The advantage is that you get stack trace when an application crash. If you can reproduce a crashing behaviour, go to bugs.kde.org, check that your bug doesn't exist yet and submit it. It will help us improve kde. For Qt, the compilation options are explained in qt-copy/README.qt-copy.
See --enable-final above :) . "make final" uses the all-in-one-file trick in the current directory even if --enable-final wasn't used, and "make no-final" does a normal compilation in the current directory even if --enable-final was used. Include your moc files! Header files declaring a QObject descendant have to be run through moc to produce a .moc file. This .moc file has to be compiled, for which two possibilities exists: compile it separately, or #include it in the C++ file implementing that above mentioned class. The latter is more efficient in term of compilation speed. BTW, kdesdk/scripts/includemocs does this automatically. Buy more ram, a faster machine and another processor. On a bi-PIII 866 MHz with 1GB of RAM, kde compiles at a decent speed :-)))
The strip is done at install. To use it, use "make install-strip" instead of "make install".
If you do
QString translatedStuff = i18n("foobar"); translatedStuff will contain the translation of "foobar", while for const char *markedStuff = I18N_NOOP("foobar"); markedStuff will still contain literal "foobar", but translators will know you want "foobar" translated so you can later on do QString translatedStuff = i18n(markedStuff); and get the translation of "foobar", which wouldn't work without that I18N_NOOP.
So, normally you want to just use i18n(), but in cases where you absolutely need to pass something untranslated, but still need to translate it later or in the case that you have something to be translated before the KInstance exists, use I18N_NOOP.
There is a bug in QSpinNumber, that is not corrected yet. Use KSpinNumber instead, it has almost the same features.
Add myClassHeader.kidl to your Makefile.am and run make again.
Stubs are not very documented. A stub allow you to view a dcop registered application as an object whose methods are its dcop slots. Usually, applications have an appnameIface.h file that contains all the dcop slots. Add a appnameIface.stub in your Makefile.am and use the object appnameIface. See for example kdebase/khelpcenter that uses a konqueror stub.
Hmm, don't do that, if some of the classes use the Q_OBJECT macro. The KDE framework (am_edit) doesn't support this very well. Maybe METASOURCES=file.cpp might work for moc files though.
KDE searches its libraries in $KDEDIR/lib and in the lib directory of all the components of $KDEDIRS (note the additional 'S', this different from $KDEDIR). So, while you are still developing your library and don't want to install it, you can use this trick: cd to your development directory, the one where your library is built. Set up KDEDIRS so that it include your development directory: export KDEDIRS=`pwd`:$KDEDIR Create a pseudo lib directory where KDE should find your component: ln -s .libs lib (all the objects and libraries are built in the .libs directory). Run kbuildsycoca to inform KDE that it KDEDIRS has changed.
Now, KDE should find your library when using KTrader or KLibLoader.
If want to install your application privately, configure it with another prefix: for $HOME/kdeprefix, use configure --prefix=$HOME/kdeprefix. Then let KDE know about this prefix: set KDEDIRS to $HOME/kdeprefix:$KDEDIR. To make KDE aware of new prefixes, one can also edit /etc/kderc and add
but this doesn't answer this specific question ;-)
Make sure to run "kbuildsycoca" after setting the new KDEDIRS.
The mimetype database must be rebuilt when you install new services (such as applications or parts). In theory this happens by itself (kded is watching those directories), but in doubt, run "kbuildsycoca". The best way to debug trader-related problems is to use ktradertest: cd kdelibs/kio/tests; make ktradertest, then run ./ktradertest to see how to use it.
The solution is simple: start new apps from a command line, then they will use the new lib.
The reason is that applications started by other KDE applications (kicker, minicli, konqueror, etc.) are started via kdeinit, which loads the libs when KDE starts. So the "old" version of the libs keep being used. But if you want kdeinit to start using the new libs, simply restart it. This is done by typing kdeinit in a terminal. This is necessary if you can't start things from the command line - e.g. for a kioslave. If you change something in kio, you need to restart kdeinit and kill the running kioslave, so that a new one is started.
Apps are often tempted to link to their part because they of course have much functionality in common. However this is wrong for the reasons below. A lib is something you link to, a module is something you dlopen. You can't dlopen a lib ; you can't link to a module. A lib has a version number and is installed in $libdir (e.g. $KDEDIR/lib) a module doesn't have a version number (in its name), it's more like a binary (we don't have konqueror-1.14.23 either :), and is installed into kde_moduledir (e.g. $KDEDIR/lib/kde3) (which means it's not in the search path for ld.so, so this breaks on systems without -rpath). If you didn't understand the above, don't worry. The point is: you should NOT make your application link to your (or any other) KPart, nor any other kind of dlopened module. The solutions let the app dlopen the part. This is what KOffice does. However this limits the app to the very limited ReadOnlyPart/ReadWritePart API. Keep in mind that you can't call a non-virtual method whose implementation you don't link to. The solution is to define a ReadWritePart-derived class (like we have in koffice: KoDocument), with new virtual methods. Either this derived class has code (and you need a lib shared by the app and the part, see point 2 below), or an abstract interface (header file only) is enough. You can also use known interfaces to child objects of the part instead of changing the base class of the part itself - this is the solution used by e.g. KParts::BrowserExtension. define a common library with the common classes and let both the part and the app use it. That library can be noinst_ or lib_, both work. In the first case the compiled object code is duplicated, in the second case a real versioned lib will be installed. The idea here is that the part itself is not available to the app, but instead the part is a very thin wrapper around the same classes as the app uses. Only KParts-specific stuff remains in the part.
There is a good answer in the kde2 porting instructions. Check kdelibs/KDE2PORTING.html, also there.
Get the latest KDE using SVN to check that the code you want to write has not been added yet. Check the bug database to see if your bug is not worked on. Get in contact with the author. His/her name is in the about box or in the source header. If the project has a mailing-list, browse the archives to see if your bug/feature has not been the subject of any discussion. If you can't find any mailing lists or author, simply write to kde-devel. Post a message explaining your intentions. It is important to inform the author(s) about what you are planning because somebody might already be working on your feature, or a better design could be proposed by the author, or he could give you some good advice. Next step is to code your feature. It is usually a good idea to keep an original at hand and to work on a copy. This allow to check the behaviours of both versions of the code. Respect the author's indentation and naming scheme, code carefully, think about side-effects and test everything many times. Using the latest KDE code, make a diff using either svn diff or a diff -uNp original-dir new-dir. Don't send reversed patch. The first argument of diff should be the old directory and the second the new directory. Send a mail to the author/mailing-list with your patch as attachment (don't forget to attach it :-) ). People usually have some remarks on your work and you must work further on your patch to improve it. It is common to see three or four submission before acceptation.
Never make assumptions about the geometry of the "desktop" or the arrangement of the screens. Make use of the following functions from kglobalsettings.h: static QRect KGlobalSettings::splashScreenDesktopGeometry(); static QRect KGlobalSettings::desktopGeometry(const QPoint& point); static QRect KGlobalSettings::desktopGeometry(QWidget *w); Use splashScreenDesktopGeometry() to determine the geometry of the desktop when you want to display an application splash screen. Use desktopGeometry() to determine the geometry of the desktop with respect to a given point on the desktop, or with respect to a given widget. Do not use the Qt class QDesktopWidget to determine these values yourself. The KDE functions take the user's settings into account, something the Qt functions cannot do. It is ideal to try to avoid using the desktop geometry altogether. Your application will be much more standards compliant if you let the window manager place your windows for you. When this is not possible, you have the aforementioned functions available. Please beware that the geometry that is returned from these functions may not start at (0,0)! Do your math correctly! One other caution: Both KWin and the NETWM specification have severe difficulties handling struts with Xinerama or "merged" displays. This can result in dead areas on the screen, for instance if kicker does not span a whole edge. There is not much that can be done about this, and you should try to avoid hacks to circumvent this at this time. We hope to find a proper solution for this soon.
Another thing that may help is to rebuild and reinstall your kdewidgets.so file, which is located in the kdelibs/kdewidgets directory. Note that if you *do* have multiple versions of Qt, this may compile against the wrong one. This problem creeps up on various mailing lists occassionally, so looking at the archives on lists.kde.org may be helpful.
Symbols defined in a C++ anonymous namespace do NOT have internal linkage. Anonymous namespaces only give an unique name for that translation unit and that is it; they don't change the linkage of the symbol at all. Linkage isn't changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments.
Yes. Calling delete on a null pointer is a noop in C++. Having "if (ptr) delete ptr;" is redundant. Doing "ptr = 0;" after a delete is a good idea, especially if the delete can be called on it from a different code path.