Actually move the kde files that were renamed in the last commit

1 files changed, 0 insertions, 571 deletions

diff --git a/libkdegames/kgame/kgameio.h b/libkdegames/kgame/kgameio.h
deleted file mode 100644
index 510ab0b7..00000000
--- a/libkdegames/kgame/kgameio.h
+++ /dev/null
@@ -1,571 +0,0 @@
-/*
-    This file is part of the KDE games library
-    Copyright (C) 2001 Martin Heni (martin@heni-online.de)
-    Copyright (C) 2001 Andreas Beckermann (b_mann@gmx.de)
-
-    This library is free software; you can redistribute it and/or
-    modify it under the terms of the GNU Library General Public
-    License version 2 as published by the Free Software Foundation.
-
-    This library is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-    Library General Public License for more details.
-
-    You should have received a copy of the GNU Library General Public License
-    along with this library; see the file COPYING.LIB.  If not, write to
-    the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
-    Boston, MA 02110-1301, USA.
-*/
-/*
-    $Id$
-*/
-#ifndef __KGAMEIO_H__
-#define __KGAMEIO_H__
-
-#include <tqstring.h>
-#include <tqobject.h>
-#include <kdemacros.h>
-class KPlayer;
-class KGame;
-class KProcess;
-
-/**
- *  \short Base class for IO devices for games
- *
- *  This is the master class for
- *  creating IO game devices. You cannot use it directly.
- *  Either take one of the classes derived from it or
- *  you have to create your own IO class derived from it (more probably).
- *
- *  The idea behind this class is to provide a common interface
- *  for input devices into your game. By programming a KGameIO
- *  device you need not distinguish the actual IO in the game
- *  anymore. All work is done by the IO's. This allows very
- *  easy reuse in other games as well.
- *  A further advantage of using the IO's is that you can exchange
- *  the control of a player at runtime. E.g. you switch a player
- *  to be controlled by the computer or vice versa.
- *
- *  To achieve this you have to make all of your player inputs through a
- *  KGameIO. You will usually call KGameIO::sendInput to do so. 
- *
- *  @author Martin Heni <martin@heni-online.de>
- */
-class KDE_EXPORT KGameIO : public TQObject
-{
-  Q_OBJECT
-  TQ_OBJECT
-
-public:
-    /**
-     * Constructs a KGameIO object
-     */
-   KGameIO();
-   KGameIO(KPlayer*);
-   virtual ~KGameIO();
-
-    /**
-     * Gives debug output of the game status
-     */
-   void Debug();
-
-   /**
-    * Identifies the KGameIO via the rtti function
-    */
-   enum IOMode {GenericIO=1,KeyIO=2,MouseIO=4,ProcessIO=8,ComputerIO=16};
-   /**
-    * Run time idendification. Predefined values are from IOMode
-    * You MUST overwrite this in derived classes!
-    *
-    * @return rtti value
-    */
-   virtual int rtti() const = 0;  // Computer, network, local, ...
-   
-   /**
-    * This function returns the player who owns this IO
-    *
-    * @return the player this IO device is plugged into
-    */
-   KPlayer *player() const {return mPlayer;}
-
-   /**
-    * Equivalent to player()->game()
-    * @return the @ref KGame object of this player
-    **/
-   KGame* game() const;
-
-   /**
-    * Sets the player to which this IO belongs to. This
-    * is done automatically when adding a device to a 
-    * player
-    *
-    * @param p the player
-    */
-   void setPlayer(KPlayer *p) {mPlayer=p;}
-
-   /**
-    * Init this device by setting the player and e.g. sending an
-    * init message to the device. This initialisation message is
-    * very useful for computer players as you can transmit the
-    * game status to them and only update this status in the setTurn
-    * commands.
-    *
-    * Called by @ref KPlayer::addGameIO only!
-    */
-   virtual void initIO(KPlayer *p);
-
-    /**
-     * Notifies the IO device that the player's setTurn had been called
-     * Called by KPlayer
-     *
-     * This emits @ref signalPrepareTurn and sends the turn if the send
-     * parameter is set to true.
-     *
-     * @param b turn is true/false
-     */
-    virtual void notifyTurn(bool b);
-
-    /**
-     * Send an input message using @ref KPlayer::forwardInput
-     **/
-    bool sendInput(TQDataStream& stream, bool transmit = true, TQ_UINT32 sender = 0);
-
-signals:
-    /**
-     * Signal generated when @ref KPlayer::myTurn changes. This can either be
-     * when you get the turn status or when you lose it.
-     *
-     * The datastream has to be filled with a move. If you set (or leave) the
-     * send parameter to FALSE then nothing happens: the datastream will be
-     * ignored. If you set it to TRUE @ref sendInput is used to
-     * send the move.
-     *
-     * Often you want to ignore this signal (leave send=FALSE) and send the
-     * message later. This is usually the case for a human player as he probably
-     * doesn't react immediately. But you can still use this e.g. to notify the
-     * player about the turn change. 
-     *
-     * Example:
-     * \code
-     *  void GameWindow::slotPrepareTurn(TQDataStream &stream,bool b,KGameIO *input,bool * )
-     *  {
-     *    KPlayer *player=input->player();
-     *    if (!player->myTurn()) return ;
-     *    if (!b) return ;        // only do something on setTurn(true)
-     *    stream << 1 << 2 << 3;  // Some data for the process
-     *  }
-     * \endcode
-     *
-     * @param io the KGameIO object itself
-     * @param stream the stream into which the move will be written
-     * @param turn the argument of setTurn
-     * @param send set this to true to send the generated move using @ref
-     * sendInput
-     **/
-    void signalPrepareTurn(TQDataStream & stream, bool turn, KGameIO *io, bool * send);
-
-
-private:
-   KPlayer *mPlayer;
-};
-
-/**
- *  The KGameKeyIO class. It is used to process keyboard input
- *  from a widget and create moves for the player it belongs to.
- *  @author Martin Heni <martin@heni-online.de>
- */
-class KDE_EXPORT KGameKeyIO : public KGameIO
-{
-  Q_OBJECT
-  TQ_OBJECT
-
-public:
-    /**
-     * Create a keyboard input devices. All keyboards
-     * inputs of the given widgets are passed through a signal
-     * handler signalKeyEvent and can be used to generate
-     * a valid move for the player.
-     * Note the widget you pass to the constructor must be
-     * the main window of your application, e.g. view->parentWidget()
-     * as QT does not forward your keyevents otherwise. This means
-     * that this might be a different widget comapred to the one you
-     * use for mouse inputs!
-     * Example:
-     * \code
-     * KGameKeyIO *input;
-     *  input=new KGameKeyIO(myWidget);
-     *  connect(input,TQT_SIGNAL(signalKeyEvent(KGameIO *,TQDataStream &,TQKeyEvent *,bool *)),
-     *          this,TQT_SLOT(slotKeyInput(KGameIO *,TQDataStream &,TQKeyEvent *,bool *)));
-     * \endcode
-     *
-     * @param parent The parents widget whose keyboard events * should be grabbed
-     */
-    KGameKeyIO(TQWidget *parent);
-    virtual ~KGameKeyIO();
-
-    /**
-     * The idendification of the IO
-     *
-     * @return KeyIO
-     */
-    virtual int rtti() const;
-
-signals:
-      /**
-       * Signal handler for keyboard events. This function is called
-       * on every keyboard event. If appropriate it can generate a
-       * move for the player the device belongs to. If this is done
-       * and the event is eaten eatevent needs to be set to true.
-       * What move you generate (i.e. what you write to the stream)
-       * is totally up to you as it will not be evaluated but forwared
-       * to the player's/game's  input move function
-       * Example:
-       * \code
-       * KPlayer *player=input->player(); // Get the player
-       * TQ_INT32 key=e->key();
-       * stream << key;
-       * eatevent=true;
-       * \endcode
-       *
-       * @param io the IO device we belong to
-       * @param stream the stream where we write our move into
-       * @param m The TQKeyEvent we can evaluate
-       * @param eatevent set this to true if we processed the event
-       */
-      void signalKeyEvent(KGameIO *io,TQDataStream &stream,TQKeyEvent *m,bool *eatevent);
-
-protected:
-       /**
-       * Internal method to process the events
-       */
-       bool eventFilter( TQObject *o, TQEvent *e );
-};
-
-/**
- *  The KGameMouseIO class. It is used to process mouse input
- *  from a widget and create moves for the player it belongs to.
- *  @author Martin Heni <martin@heni-online.de>
- */
-class KDE_EXPORT KGameMouseIO : public KGameIO
-{
-  Q_OBJECT
-  TQ_OBJECT
-    
-public:
-    /**
-     * Creates a mouse IO device. It captures all mouse
-     * event of the given widget and forwards them to the
-     * signal handler signalMouseEvent.
-     * Example:
-     * \code
-     * KGameMouseIO *input;
-     * input=new KGameMouseIO(mView);
-     * connect(input,TQT_SIGNAL(signalMouseEvent(KGameIO *,TQDataStream &,TQMouseEvent *,bool *)),
-     *        this,TQT_SLOT(slotMouseInput(KGameIO *,TQDataStream &,TQMouseEvent *,bool *)));
-     * \endcode
-     *
-     * @param parent The widget whose events should be captured
-     * @param trackmouse enables mouse tracking (gives mouse move events)
-     */
-    KGameMouseIO(TQWidget *parent,bool trackmouse=false);
-    virtual ~KGameMouseIO();
-    
-    /**
-     * Manually activate or deactivate mouse tracking
-     *
-     * @param b true = tracking on
-     */
-    void setMouseTracking(bool b);
-    /**
-     * The idendification of the IO
-     *
-     * @return MouseIO
-     */
-    virtual int rtti() const; 
-
-signals:
-      /**
-       * Signal handler for mouse events. This function is called
-       * on every mouse event. If appropriate it can generate a
-       * move for the player the device belongs to. If this is done
-       * and the event is eaten eatevent needs to be set to true.
-       * @see signalKeyEvent
-       * Example:
-       * \code
-       * KPlayer *player=input->player(); // Get the player
-       * TQ_INT32 button=e->button();
-       * stream << button;
-       * eatevent=true;
-       * \endcode
-       *
-       * @param io the IO device we belong to
-       * @param stream the stream where we write our move into
-       * @param m The TQMouseEvent we can evaluate
-       * @param eatevent set this to true if we processed the event
-       */
-      void signalMouseEvent(KGameIO *io,TQDataStream &stream,TQMouseEvent *m,bool *eatevent);
-
-protected:
-      /**
-      * Internal event filter
-      */
-      bool eventFilter( TQObject *o, TQEvent *e );
-
-};
-
-
-/**
- *  The KGameProcessIO class. It is used to create a computer player
- *  via a separate process and communicate transparetly with it.
- *  Its counterpart is the @ref KGameProcess class which needs
- *  to be used by the computer player. See its documentation
- *  for the definition of the computer player.
- *  @author Martin Heni <martin@heni-online.de>
- */
-class KDE_EXPORT KGameProcessIO : public KGameIO
-{
-  Q_OBJECT
-  TQ_OBJECT
-    
-public:
-    /** 
-     * Creates a computer player via a separate process. The process
-     * name is given as fully qualified filename. 
-     * Example:
-     * \code
-     * KGameProcessIO *input;
-     *   input=new KGameProcessIO(executable_file);
-     *  connect(input,TQT_SIGNAL(signalPrepareTurn(TQDataStream &,bool,KGameIO *,bool *)),
-     *          this,TQT_SLOT(slotPrepareTurn(TQDataStream &,bool,KGameIO *,bool *)));
-     *  connect(input,TQT_SIGNAL(signalProcessQuery(TQDataStream &,KGameProcessIO *)),
-     *          this,TQT_SLOT(slotProcessQuery(TQDataStream &,KGameProcessIO *)));
-     * \endcode
-     *
-     * @param name the filename of the process to start
-     */
-    KGameProcessIO(const TQString& name);
-
-    /**
-     * Deletes the process input devices 
-     */
-    virtual ~KGameProcessIO();
-
-    /**
-     * The idendification of the IO
-     *
-     * @return ProcessIO
-     */
-    int rtti() const;
-    
-    /**
-     * Send a message to the process. This is analogous to the sendMessage
-     * commands of KGame. It will result in a signal of the computer player
-     * on which you can react in the process player.
-     *
-     * @param stream  - the actual data
-     * @param msgid - the id of the message
-     * @param receiver - not used
-     * @param sender - who send the message
-     */
-    void sendMessage(TQDataStream &stream,int msgid, TQ_UINT32 receiver, TQ_UINT32 sender);
-
-    /**
-     * Send a system message to the process. This is analogous to the sendMessage
-     * commands of KGame. It will result in a signal of the computer player
-     * on which you can react in the process player.
-     *
-     * @param stream  - the actual data
-     * @param msgid - the id of the message
-     * @param receiver - not used
-     * @param sender - who send the message
-     */
-    void sendSystemMessage(TQDataStream &stream, int msgid, TQ_UINT32 receiver, TQ_UINT32 sender);
-
-    /** 
-     * Init this device by setting the player and e.g. sending an
-     * init message to the device. Calling this function will emit
-     * the IOAdded signal on which you can react and initilise the
-     * computer player. 
-     * This function is called automatically when adding the IO to
-     * a player.
-     */
-    void initIO(KPlayer *p);
-
-    /**
-     *  Notifies the IO device that the player's setTurn had been called
-     *  Called by KPlayer. You can react on the @ref signalPrepareTurn to
-     *  prepare a message for the process, i.e. either update it on
-     * the changes made to the game since the last turn or the initIO
-     * has been called or transmit your gamestatus now.
-     *
-     *  @param turn is true/false
-     */
-    virtual void notifyTurn(bool turn);
-
-  protected:
-    /**
-     * Internal ~ombined function for all message handling 
-     **/
-    void sendAllMessages(TQDataStream &stream,int msgid, TQ_UINT32 receiver, TQ_UINT32 sender, bool usermsg);
-
-  protected slots:
-  /**
-  * Internal message handler to receive data from the process
-  */
-    void receivedMessage(const TQByteArray& receiveBuffer);
-
-  
-signals:
-  /**
-   * A computer query message is received. This is a 'dummy'
-   * message sent by the process if it needs to communicate
-   * with us. It is not forwarded over the network.
-   * Reacting to this message allows you to 'answer' questions
-   * of the process, e.g. sending addition data which the process
-   * needs to calculate a move.
-   *
-   * Example:
-   * \code
-   *  void GameWindow::slotProcessQuery(TQDataStream &stream,KGameProcessIO *reply)
-   *  {
-   *    int no;
-   *    stream >> no;  // We assume the process sends us an integer question numner
-   *    if (no==1)     // but YOU have to do this in the process player
-   *    {
-   *      TQByteArray buffer;
-   *      TQDataStream out(buffer,IO_WriteOnly);
-   *      reply->sendSystemMessage(out,4242,0,0);  // lets reply something...
-   *    }
-   *  }
-   * \endcode
-   */
-  void signalProcessQuery(TQDataStream &stream,KGameProcessIO *me);
-
-  /**
-  * Signal generated when the computer player is added. 
-  * You can use this to communicated with the process and
-  * e.g. send initialisation information to the process.
-  *
-  * @param game the KGameIO object itself
-  * @param stream the stream into which the move will be written
-  * @param p the player itself
-  * @param send set this to false if no move should be generated
-  */
-  void signalIOAdded(KGameIO *game,TQDataStream &stream,KPlayer *p,bool *send);
-
-
-protected:
-
-private:
-  class KGameProcessIOPrivate;
-  KGameProcessIOPrivate* d;
-};
-
-/**
- *  \brief KGameIO variant for real-time games
- *
- *  The KGameComputerIO class. It is used to create a LOCAL computer player
- *  and communicate transparently with it. 
- *  Question: Is this needed or is it overwritten anyway for a real game?
- *
- *  You most probably don't want to use this if you want to design a turn based
- *  game/player. You'll rather use @ref KGameIO directly, i.e. subclass it
- *  yourself. You just need to use @ref KGameIO::signalPrepareTurn and/or @ref
- *  KGameIO::notifyTurn there.
- *
- *  This is rather meant to be of use in real time games.
- *
- *  @author  <b_mann@gmx.de>
- */
-class KDE_EXPORT KGameComputerIO : public KGameIO
-{
-  Q_OBJECT
-  TQ_OBJECT
-    
-public:
-    /** 
-     * Creates a LOCAL computer player 
-     *
-     */
-    KGameComputerIO();
-    KGameComputerIO(KPlayer* player);
-    ~KGameComputerIO();
-
-    int rtti() const;
-
-    /**
-     * The number of advance calls until the player (or rather: the IO)
-     * does something (default: 1). 
-     **/
-    void setReactionPeriod(int advanceCalls);
-    int reactionPeriod() const;
-
-    /**
-     * Start a TQTimer which calls advance every @p ms milli seconds.
-     **/
-    void setAdvancePeriod(int ms);
-
-    void stopAdvancePeriod();
-
-    /**
-     * Ignore calls number of advance calls. if calls is -1 then all 
-     * following advance calls are ignored until unpause is called.
-     *
-     * This simply prevents the internal advance counter to be increased.
-     *
-     * You may want to use this to emulate a "thinking" computer player. Note
-     * that this means if you increase the advance period (see 
-     * setAdvancePeriod), i.e. if you change the speed of your game, your
-     * computer player thinks "faster".
-     * @param calls Number of advance calls to be ignored
-     **/
-    void pause(int calls = -1);
-
-    /**
-     * Equivalent to pause(0). Immediately continue to increase the internal
-     * advance counter.
-     **/
-    void unpause();
-    
-public slots:
-    /**
-     * Works kind of similar to TQCanvas::advance. Increase the internal
-     * advance counter. If @p reactionPeriod is reached the counter is set back to
-     * 0 and @ref signalReaction is emitted. This is when the player is meant 
-     * to do something (move its units or so).
-     *
-     * This is very useful if you use TQCanvas as you can use this in your
-     * TQCanvas::advance call. The advantage is that if you change the speed
-     * of the game (i.e. change TQCanvas::setAdvancePeriod) the computer
-     * player gets slower as well.
-     *
-     * If you don't use TQCanvas you can use setAdvancePeriod to get
-     * the same result. Alternatively you can just use a TQTimer.
-     * 
-     **/
-    virtual void advance();
-  
-signals:
-    /**
-     * This signal is emitted when your computer player is meant to do
-     * something, or better is meant to be allowed to do something.
-     **/
-    void signalReaction();
-
-protected:
-    /**
-     * Default implementation simply emits signalReaction
-     **/
-    virtual void reaction();
-
-private:
-    void init();
- 
-private:
-    class KGameComputerIOPrivate;
-    KGameComputerIOPrivate* d;
-};
-
-
-#endif