The idea of having different semantics for the const and non-const begin() and end()
doesn't work. The compiler uses the non-const one when the manager is non-const, even
if you type ConstIterator. This meant many methods were working on the shadow-identities
list instead of the real identities (e.g. the identitycombo), and it also meant
that the changed(uoid) signal was never emitted since commit() was looking into the
wrong list.
To fix this, I did like Qt: used a different name for the const and non-const
begin/end. But I left the const ones unchanged to minimize code change, so
I renamed the non-const begin/end to modifyBegin()/modifyEnd().
The other bug was that changed(uoid) was emitted before updating mIdentities,
so the slot (e.g. in my next kmcomposewin.cpp commit) wouldn't be able to
find that identity with identityForUoid().
CCMAIL: Marc Mutz <mutz@kde.org>
svn path=/trunk/kdepim/; revision=329612
(better than <foo.h>, especially when systems could have an identity.h somewhere)
A kconfig_update script moves the identities from kmailrc to emailidentities
svn path=/trunk/kdepim/; revision=311347
#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
David Faure
Marc Mutz
Ingo Klcker
Dirk Mueller
Zack Rusin
Malcolm Hunter