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

[Inge Wallin]

On Monday 27 September 2004 01.44, Ian Wadham wrote:
> ----- Original Message -----
> From: "Inge Wallin" <inge at lysator.liu.se>
> >
> > 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.

I understand all that.  However, the work that a slot does could be useful to 
invoke from within the same class as well.  The fact that the signal/slot 
mechanism is used in the way that you describe above does not detract from 
that.

> 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.

I didn't even know that you could trigger the signal without the "emit" 
keyword.  I fully agree with the rest of the paragraph.

> 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.

I know this as well.  My question was only about naming, nothing else.  I was 
probably unclear, and didn't phrase my question clearly enough.

In my case, the slot updates the view and are called when some aspect of the 
document is changed.  In my case, KReversi, the document is the game and the 
view is the board widget, the score widget (number of pieces of each side), 
the side to move, etc, etc.

One example where I want to update the view without affecting the document is 
when the computer and the human change sides.  The game only stores the 
position using colors white and black, but the top view shows who plays which 
side.  So I have to call the slot, but I do it in the main kreversi class, 
and am not sending a signal from the document (the game).

I fear that I am still unclear, but I hope that it is somewhat better.  If you 
want you can ignore the explanation above, and if you have an idea of how to 
treat the original question I would be greatful. On the other hand, since the 
question was misunderstood from the beginning, there might not be a clear 
answer, and there is no convention on how to do it.

        -Inge

-- 
Inge Wallin               | Thus spake the master programmer:               |
                          |      "After three days without programming,     |
inge at lysator.liu.se       |       life becomes meaningless."                |
                          | Geoffrey James: The Tao of Programming.         |