[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