summaryrefslogtreecommitdiffstats
path: root/tdecore/klibloader.h
diff options
context:
space:
mode:
Diffstat (limited to 'tdecore/klibloader.h')
-rw-r--r--tdecore/klibloader.h18
1 files changed, 9 insertions, 9 deletions
diff --git a/tdecore/klibloader.h b/tdecore/klibloader.h
index d9e632184..813106164 100644
--- a/tdecore/klibloader.h
+++ b/tdecore/klibloader.h
@@ -36,7 +36,7 @@ class KLibLoaderPrivate;
class KLibraryPrivate;
# define K_EXPORT_COMPONENT_FACTORY( libname, factory ) \
- extern "C" { KDE_EXPORT void *init_##libname() { return new factory; } }
+ extern "C" { TDE_EXPORT void *init_##libname() { return new factory; } }
/**
* @short Represents a dynamically loaded library.
@@ -52,7 +52,7 @@ class TDECORE_EXPORT KLibrary : public TQObject
friend class KLibLoader;
friend class TQAsciiDict<KLibrary>;
- Q_OBJECT
+ TQ_OBJECT
public:
/**
* Don't create KLibrary objects on your own. Instead use KLibLoader.
@@ -143,7 +143,7 @@ class TDECORE_EXPORT KLibLoader : public TQObject
{
friend class KLibrary;
- Q_OBJECT
+ TQ_OBJECT
public:
/**
* You should NEVER destruct an instance of KLibLoader
@@ -322,7 +322,7 @@ private:
* The KLibFactory is used to create the components, the library has to offer.
* The factory of KSpread for example will create instances of KSpreadDoc,
* while the Konqueror factory will create KonqView widgets.
- * All objects created by the factory must be derived from TQObject, since QObject
+ * All objects created by the factory must be derived from TQObject, since TQObject
* offers type safe casting.
*
* KLibFactory is an abstract class. Reimplement the
@@ -332,7 +332,7 @@ private:
*/
class TDECORE_EXPORT KLibFactory : public TQObject
{
- Q_OBJECT
+ TQ_OBJECT
public:
/**
* Create a new factory.
@@ -349,7 +349,7 @@ public:
* It is valid behavior to create different kinds of objects
* depending on the requested @p classname. For example a koffice
* library may usually return a pointer to KoDocument. But
- * if asked for a TQWIDGET_OBJECT_NAME_STRING, it could create a wrapper widget,
+ * if asked for a "TQWidget", it could create a wrapper widget,
* that encapsulates the Koffice specific features.
*
* create() automatically emits a signal objectCreated to tell
@@ -363,7 +363,7 @@ public:
* @param args a list of arguments
*/
- TQObject* create( TQObject* parent = 0, const char* name = 0, const char* classname = TQOBJECT_OBJECT_NAME_STRING, const TQStringList &args = TQStringList() );
+ TQObject* create( TQObject* parent = 0, const char* name = 0, const char* classname = "TQObject", const TQStringList &args = TQStringList() );
signals:
/**
@@ -382,7 +382,7 @@ protected:
* It is valid behavior to create different kinds of objects
* depending on the requested @p className. For example a koffice
* library may usually return a pointer to KoDocument. But
- * if asked for a TQWIDGET_OBJECT_NAME_STRING, it could create a wrapper widget,
+ * if asked for a "TQWidget", it could create a wrapper widget,
* that encapsulates the Koffice specific features.
*
* This function is called by #create()
@@ -392,7 +392,7 @@ protected:
* @param args a list of arguments
*/
virtual TQObject* createObject( TQObject* parent = 0, const char* name = 0,
- const char* className = TQOBJECT_OBJECT_NAME_STRING,
+ const char* className = "TQObject",
const TQStringList &args = TQStringList() ) = 0;