From kde-core-devel  Thu Nov 11 22:13:31 1999
From: David Faure <faure () kde ! org>
Date: Thu, 11 Nov 1999 22:13:31 +0000
To: kde-core-devel
Subject: Proposal for dcopidl/dcopidl2cpp improvement
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=94235835523765

Up to now, one has to create a new class (like the *IFace classes)
in order to run dcopidl on it. But since DCOPObject isn't a
QObject, why shouldn't one be able to add the DCOPObject implementation
to an existing class (which can be a QObject) ?

I've just been trying to run dcopidl on something like :
class MyWin : public KTMainWindow, DCOPObject {
  K_DCOP
  Q_OBJECT
public:
... (constructor, destructor, methods, members, everything)
k_dcop:
 void loadURL( QString url );


I fixed dcopidl to ignore Q_OBJECT, no problem.
The problem is that dcopidl2cpp behaves strangely with multiple inheritance :
- it assumes that all super classes are DCOPObjects 
   (it calls the ::process method on <classname>_stub)
  Obviously KTMainWindow_stub::process doesn't exist :)
- it calls the constructor of the first super class only
  (and I can't make DCOPObject the first one since Q_OBJECT has to be the first one)
In fact dcopidl2cpp is able to deal with 1 parent class if it's any DCOPObject child, but
not with 2 parent classes.

The fix I'm thinking of would be simple : ignore parent classes and always 
assume we inherit only from DCOPObject.

[ When I remove manually <SUPER name="KTMainWindow"/> from the .kdil file, everything
  works fine ]

Obviously it wouldn't be possible to inherit a dcopidl interface from another.
Is this a problem for anybody ? (The current code doesn't do that at all, but in
the future, I don't know).

AFAICS, we can't have both. Because dcopidl2cpp has no way to know which
parent classes are DCOPObjects and which aren't. Or we need to introduce yet
another tag for that, to tell dcopidl2cpp what to do.

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today