- Remove the existing org.kde.kmail.kmail/kmailpart/mailcomposer.xml files, and let them
be generated at build time instead. This is done by extracting the slots and signals
marked with Q_SCRIPTABLE.
I had to adjust the CMake files of all users of the XML files to use the one from the
build directory now.
Currently, the XML files are also installed. I am not sure if this is a good idea, as that
implies we have to keep some sort of compatibility.
- Fix incorrect D-Bus path and method call in the summary view. Now the generated interface is
used instead. Checking the accounts with the sync actions works again now.
- Some DCOP->D-Bus renamings in comments
- Some style fixes around D-Bus related lines
The D-Bus test of KMail and the Kontact KMail summary still work.
This needs the new FindQt4.cmake from kdelibs.
This probably needs a clean build.
I did not touch the groupware interface or the SMIME security config page
(which talks to Kleopatra). This is left for KDAB to fix, but it would be
nice to contact me before.
svn path=/trunk/KDE/kdepim/; revision=750976
then if it goes right through my kitchen then it totally messes up my hairdo.
When i wrote folderiface i wanted to make sure there's no gui code in it. now
i added it myself which implies i'd have to flame myself and give myself
an f in "software design 101" if not the fact that i fix it in this commit -
switching to using dcop signals.
svn path=/trunk/kdepim/; revision=295370
#define kernel KMKernel::self()
to
#define kmkernel KMKernel::self()
because 'kernel' was a much to general term. We really shouldn't repeat the mistakes of the X developers.
I noticed this problem when I played around with KImageEffects. kimageeffects.h contains 'kernel' as parameter of some methods and so the compilation had to fail. We won't need KImageEffects in the near future, but at least we are now prepared and a clash with another 'kernel' can't happen anymore.
svn path=/trunk/kdepim/; revision=252621