[Kde-games-devel] Design of Qt and/or KGame based programs, part 1

[Ian Wadham]

----- Original Message ----- 
From: "Inge Wallin" <inge at lysator.liu.se>
Sent: Sunday, September 26, 2004 11:10 PM

> One design issue that I have come across is the naming of slots.  Suppose
that
> you have a slot that is pretty simple.  For example, say that it only
calls a
> label widget to set the text within that widget.  I like to name my slots
> slotFoo(), where Foo is the actual name of the function.  It would look
> something like this:
> .....
>
> Now, further suppose that you want to set the score from several places
from
> within the same class that the slotScore() resides in.  The call will then
be
> "slotScore()" which I find kind of ugly.
>
> How do you handle this case?  Do you
>
> a) Just call the slot like above?
>
> b) have a helper method with, say, the name showScore() that does the
actual
> work, and then call it from within the slot?
>
> c) Not name the slot slotFoo() from the beginning, but just foo()?
>
> d) some other way?
>
Maybe I'm missing something here, but why would you want to invoke
a slot from "several" places within its own class?  As I understand it,
the slot/signal mechanism exists so that methods may be interconnected
even if their classes are unrelated, the idea being that a signal could
come from various places (and architectural levels) within your code,
but be dealt with at the proper level.  For example, you may detect that
the hero has been killed by colliding with an enemy, at a low level of
the animation, so you emit a signal to be caught by a slot in the main
game-control object and that slot then adjusts the score and restarts
or ends the whole game.

You might want to invoke a slot directly from within its class once,
when you are initialising the object that contains it.  When you invoke
a slot with a signal, you use the *signal* name.  So that name is important
and the slot name is not so important.  To emphasise this, I like to write
"emit signalName();", not just "signalName()", even though the MOC
pre-processor treats "emit" as a null string.  Also a comment is a good
idea when triggering a slot in an unrelated class.  Otherwise it's hard
for a human reader of the code to know where control will go next.

Note also that slots and signals are extensively used by libraries in
Qt and KDE.  Sometimes you need to provide slots for the library
to use when it detects external events.  It is important that you
complete the initialisation of all your slots before you allow any
signals to come in (e.g. before "connect"ing a library signal).
Otherwise weird things can happen at run time.

All the best, Ian W.