New version of Panel Clock applet

Martijn Klingens klingens at
Fri Jan 9 15:31:40 GMT 2004

On Friday 09 January 2004 10:23, Kevin Gilbert wrote:
> This is just another example of my newbie-ness. I was under the
> impression that any class derived from a QObject-derived class didn't
> require that macro. I'll research this matter and make the appropriate
> changes. But - if I've done the wrong thing, why does it work?

It will "work" as long as you don't add signals and slots to the classes (and 
only use those from the parent). But it avoids the generation of a proper Qt 
meta object, which makes things like QObject::className return wrong values.

It's not a fatal fault, but it (may) result in weird behaviour from 
introspection code like the Qt DCOP bridges, or accessibility and scripting 
engines, amongst other things.

> >4.) There are many little C++ style problems, like not passing stuff as
> >    reference-to-const to functions (i.e. "void f(QFont)", passing
> > constant values to functions (I saw "void f(const double)" somewhere),
> > constructors which use assignment instead of initialization.
> I'm not sure what you are referring to here. Could you give me a
> specific example of what you want? Obviously my code is OK from a C++
> view-point but not from the KDE view-point.

From a C++ point of view this is not generally 'Ok' either, only from a 
compiler point of view ;-)

The compiler accepts a lot of code that is perfectly valid, but also bad habit 
to write.

One such thing is passing objects by value like QFonts. Instead they should be 
passed by const references so only the reference is passed (which is much 
faster than copying a whole object onto the stack).

Example: instead of

void MyClass::myMethod( QFont font )
   // ...

you should use

void MyClass::myMethod( const QFont &font )
   // ...

Things that help here (besides experience ;) are C++ books and looking at 
other people's code.

> How important is this?


While it indeed breaks from time to time upgrading a KDE version ideally 
should not ever break your existing config.

The best way is to write a kconf_update script that migrates the current 
config to the new format once. See the docs in kdelibs/kconf_update for 
details. The advantage is that the migration is done completely outside your 
own code, so you don't have to add ugly compatibility hacks there.


More information about the kde-core-devel mailing list