From 838baf3f99ec5ab81b063eb5449a3381d860f377 Mon Sep 17 00:00:00 2001 From: tpearson Date: Sat, 11 Jun 2011 04:58:26 +0000 Subject: TQt4 port kdegames This enables compilation under both Qt3 and Qt4 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdegames@1236074 283d02a7-25f6-0310-bc7c-ecb5cbfe19da --- libkdegames/kgame/kgameproperty.h | 42 +++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 21 deletions(-) (limited to 'libkdegames/kgame/kgameproperty.h') diff --git a/libkdegames/kgame/kgameproperty.h b/libkdegames/kgame/kgameproperty.h index 04474603..03fcae87 100644 --- a/libkdegames/kgame/kgameproperty.h +++ b/libkdegames/kgame/kgameproperty.h @@ -51,7 +51,7 @@ public: IdName=5, //KGame - IdGameStatus=6, + IdGametqStatus=6, IdMaxPlayer=7, IdMinPlayer=8, @@ -66,7 +66,7 @@ public: }; /** - * Commands for advanced properties (Q_INT8) + * Commands for advanced properties (TQ_INT8) **/ enum PropertyCommandIds { @@ -117,7 +117,7 @@ public: /** * Constructs a KGamePropertyBase object and calls registerData. - * @param id The id of this property. MUST be UNIQUE! Used to send and + * @param id The id of this property. MUST be UNITQUE! Used to send and * receive changes in the property of the playere automatically via * network. * @param owner The owner of the object. Must be a KGamePropertyHandler which manages @@ -125,8 +125,8 @@ public: **/ KGamePropertyBase(int id, KGamePropertyHandler* owner); - KGamePropertyBase(int id, KGame* parent); - KGamePropertyBase(int id, KPlayer* parent); + KGamePropertyBase(int id, KGame* tqparent); + KGamePropertyBase(int id, KPlayer* tqparent); /** * Creates a KGamePropertyBase object without an owner. Remember to call @@ -238,7 +238,7 @@ public: int id() const { return mId; } /** - * @return a type_info of the data this property contains. This is used + * @return a type_info of the data this property tqcontains. This is used * e.g. by KGameDebugDialog **/ virtual const type_info* typeinfo() { return &typeid(this); } @@ -344,7 +344,7 @@ protected: bool sendProperty(const TQByteArray& b); /** - * Causes the parent object to emit a signal on value change + * Causes the tqparent object to emit a signal on value change **/ void emitSignal(); @@ -359,7 +359,7 @@ protected: struct { // unsigned char dosave : 1; // do save this property // unsigned char delaytransmit : 1; // do not send immediately on - // change but a KPlayer:QTimer + // change but a KPlayer:TQTimer // sends it later on - fast // changing variables unsigned char emitsignal : 1; // KPlayer notifies on variable change (true) @@ -403,7 +403,7 @@ private: *
  • A Mixture (very dirty) * * I repeat: we do not recommend the third option ("a mixture"). Unless - * you have a good reason for this you will probably introduce some hard to find + * you have a good reason for this you will probably introduce some hard to tqfind * (and to fix) bugs. * * @section Always consistent (clean): @@ -413,7 +413,7 @@ private: * property. This is achieved by using send to change the value of the * property. send needs a running KMessageServer and therefore * MUST be plugged into a KGamePropertyHandler using either - * registerData or the constructor. The parent of the dataHandler must be able + * registerData or the constructor. The tqparent of the dataHandler must be able * to send messages (see above: the message server must be running). If you use * send to change the value of a property you won't see the effect * immediately: The new value is first transferred to the message server which @@ -488,7 +488,7 @@ private: * which result in inconsistent properties (like "game running" on client A but * "game ended/paused" on client B). But note that there is a very good reason * for the existence of these different concepts of KGameProperty. I have - * myself experienced such a "strange error" and it took me several days to find + * myself experienced such a "strange error" and it took me several days to tqfind * the reason until I could fix it. So I personally recommend the "clean" way. * On the other hand if you want to port a non-network game to a network game * you will probably start with "dirty" properties as it is you will not have to @@ -546,16 +546,16 @@ private: * }; * TQDataStream& operator<<(TQDataStream& stream, Card& card) * { - * Q_INT16 type = card.type; - * Q_INT16 suite = card.suite; + * TQ_INT16 type = card.type; + * TQ_INT16 suite = card.suite; * s << type; * s << suite; * return s; * } * TQDataStream& operator>>(TQDataStream& stream, Card& card) * { - * Q_INT16 type; - * Q_INT16 suite; + * TQ_INT16 type; + * TQ_INT16 suite; * s >> type; * s >> suite; * card.type = (int)type; @@ -585,15 +585,15 @@ public: * Constructs a KGameProperty object. A KGameProperty object will transmit * any changes to the KMessageServer and then to all clients in the * game (including the one that has sent the new value) - * @param id The id of this property. MUST be UNIQUE! Used to send and + * @param id The id of this property. MUST be UNITQUE! Used to send and * receive changes in the property of the playere automatically via * network. - * @param owner The parent of the object. Must be a KGame which manages + * @param owner The tqparent of the object. Must be a KGame which manages * the changes made to this object, i.e. which will send the new data. * Note that in contrast to most KDE/QT classes KGameProperty objects * are not deleted automatically! **/ -// TODO: ID: Very ugly - better use something like parent()->propertyId() or so which assigns a free id automatically. +// TODO: ID: Very ugly - better use something like tqparent()->propertyId() or so which assigns a free id automatically. KGameProperty(int id, KGamePropertyHandler* owner) : KGamePropertyBase(id, owner) { init(); } /** @@ -651,7 +651,7 @@ public: * \endcode * as myProperty has not yet been set when doSomething is being called. * - * You are informed about a value change by a singal from the parent of + * You are informed about a value change by a singal from the tqparent of * the property which can be deactivated by setEmittingSignal because of * performance (you probably don't have to deactivate it - except you * want to write a real-time game like Command&Conquer with a lot of @@ -842,7 +842,7 @@ private: typedef KGameProperty KGamePropertyInt; typedef KGameProperty KGamePropertyUInt; -typedef KGameProperty KGamePropertyQString; -typedef KGameProperty KGamePropertyBool; +typedef KGameProperty KGamePropertyTQString; +typedef KGameProperty KGamePropertyBool; #endif -- cgit v1.2.1