[Kde-java] Qt and KDE java package names

Richard Dale Richard_Dale at tipitina.demon.co.uk
Mon Aug 11 12:47:22 CEST 2003


On Monday 11 August 2003 08:19, Gert-Jan van der Heiden wrote:
> > Good point. So would 'qt.Widget' or 'kde.Application' look ok, or do we
> > really need those long names with 'org.kde' in them?
>
> No, it just represents it's origin. It is used to quickly see which API is
> used in the code, and to organize large number of packages from different
> APIs.
I'm starting to think that dropping Qs and Ks when they're the first letter of 
a classname, isn't such a good idea. For instance, in the namespace KParts:: 
there is a class called 'Part' and another one called 'KPart'. If we drop the 
K from the second classname there would be a name clash.

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

Then the only change needed for existing QtJava/Koala apps would be in the 
import statements.

org.kde.qt => qt
org.kde.koala => kde, kde.kparts, kde.kio etc

> > > You made a point here. But if you write a serious application, this
> > > isn't an exception either. I mean, if you define your own slot and
> > > signals, but I don't know if the current bindings can do that. Maybe
> > > the new version?
> >
> > Oh yes, thats no problem. I the connect() statement doesn't find a C++
> > slot or signal it assumes they are java ones. You don't have to declare
> > slots/signals in advance (although you do in PerlQt and QtRuby).
>
> HOT!
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. 

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.

-- Richard


More information about the Kde-java mailing list