[Kde-java] Qt and KDE java package names

[Gert-Jan van der Heiden]

> Because PerlQt and QtRuby are so similar it made sense to keep the
> classname identical. But QtJava is different enough to make it harder to do
> the same. I think it should be:
>
> qt.QWidget
> kde.KApplication
> kde.kparts.KPart
> kde.kparts.Part

sound ok by me

> Well, there are some disadvantages. Suppose you type a connect statement
> like this:
>
> connect(mybutton, SIGNAL("clikked()"), mywidget, SLOT("buttonPressed()"));
>
> ...and you misspell 'clicked()' as 'clikked()'. Then the QtJava runtime
> will just assume that 'clikked()' is a java signal, rather than a C++ one
> for QPushButton. You wouldn't get any sort of warning, but the slot
> buttonPressed() would never get invoked.

Can't that be traced by looking the method up via Java reflection (after SMOKE 
has told that the C++ signal doesn't exist) ?

If clikked() isn't a Java method either, the reflection API will complain and 
throw an Exception, this could generate a warning.

If clikked() does exist (mybutton is subclassed), the Java method will be 
invoked.

> Interfaces are generated at the moment for signals - with names like
> '<class name>Signals.java', but they are just for documentary purposes. It
> might make sense to add a runtime check, if one of those interfaces is
> found for the current class, and only allow signals defined there to be
> used.  If no such interface was found, then it would work dynamically the
> same way it does now, and not check.
>
> With java 1.5 we might be able to use meta data to indicate which void
> methods are slots in a class, and that would allow some more checking.

That would be cleaner. Let's hope GCJ add's meta data soon.