[Kde-java] QtJava rewritten as a SMOKE adaptor?

[Richard Dale]

On Monday 11 August 2003 12:31, Gert-Jan van der Heiden wrote:
> > The 'proxy' instance variables will need to be created in the
> > constructors. Every Qt class like QApplication.java will need to have a
> > corresponding interface QApplicationInterface.java so that all the
> > methods the proxy expects to handle can be given via an array of these
> > interface classes (for the current class and its parents).
> >
> > QApplicationInterface proxy;
> > ...
> >
> > proxy = (QApplicationInterface) Proxy.newProxyInstance(
> > 						QApplication.class.getClassLoader(),
> > 						new Class[] { QApplicationInterface.class },
> > 						new QtProxy() );
> >
> > I don't know if this makes sense, but I thought it would be a good idea
> > to at least start discussing what to do about QtJava/Koala for KDE 3.2.
>
> Hmm, I've taken a closer look at the Proxy stuff, and it raises some
> questions by me:
> A proxy instance in the subject class (QApplication). That doen't make
> sense to me, but maybe I'm missing something. Normally the proxy has an
> instance handle of the subject, used for delegation.
Above, I've passed 'new QtProxy()' to create the new proxy, but in fact an 

> In order to intercept calls in the Proxy, the API user should talk to
> QApplicationInterface, created by java.lang.reflect.Proxy (as you
> described above). This could be done by adding a getInstance() method:
>
> class QApplication {
>         ...
> 	public static QApplicationInterface getInstance(){...}
>         ...
> }
>
> But that doesn't program nice:
> QApplicationInterface application  = QApplication.getInstace();
> instead of:
> QApplication application = new Application();
No it should look like the second way. Inside the QApplication constructor, it 
would look something like this:

proxy = (QApplicationInterface) Proxy.newProxyInstance(
 						QApplication.class.getClassLoader(),
 						new Class[] { QApplicationInterface.class },
 						new QtProxy() );
newApplication(args);

The InvocationHandler class 'QtProxy' would have a built in method called 
'setQt', and an instance variable '_qt', which would take a long that was the 
address of a new QApplication instance returned by the C++ constructor in the 
smoke library. That would be done inside the newApplication() call above, and 
the 'proxy' would need to forward 'setQt' calls to the QtProxy instance.

-- Richard