[Kde-java] Qt and KDE java package names
Richard Dale
Richard_Dale at tipitina.demon.co.uk
Sun Aug 10 19:38:10 CEST 2003
On Sunday 10 August 2003 11:13, Gert-Jan van der Heiden wrote:
> I disagree. The old style packages looked fine by me. (Though the idea of
> subpackages like kparts, kio, etc is an excellent idea).
Yes, we need to think about all the issues involved in splitting up the
current giant kde package into sub-packages. I'm not too keen on
'org.kde.qt.*' I think people would expect it to be 'com.trolltech.qt.*', but
I can't really do that - the trolls would rightly complain! Nor can I change
it to 'com.losthighway.qt.*' (my company name), because it's a free software
project, and that might make people thing wrongly that it was owned by Lost
Highway. And long names are a big problem for slots and signals because they
would make connect statements look so clunky.
>
> These dns style names aren't true Java coding conventions, though it is
> widely accepted.
>
> Using lower case package names is a true Java coding convention. I would
> recommend applying this convention, because it doesn't confuses a Java
> programmer. It would be the same as writing Classes in lower case. Take
> this example, it looks very strange (in my opinion):
>
> Qt.QWidget
>
> It looks like QWidget is an inner class of the class Qt.
>
> oR IT LOOKS LIKE THIS. :)
>
> That's just the difference between C++ and Java. Java is using the dot for
> more purposes. Look at this:
>
> Qt::QWidget (C++)
> or this
> Qt.QWidget (Java)
Good point. So would 'qt.Widget' or 'kde.Application' look ok, or do we really
need those long names with 'org.kde' in them?
>
> On Friday 08 August 2003 14:03, Richard Dale wrote:
> > Who wants to write:
> >
> > connect(myapp, "SLOT(org.kde.qt.QWidget, org.kde.koala.KPart)", ...
I meant:
connect(myapp, SLOT('foobar(org.kde.qt.QWidget, org.kde.koala.KPart)'), ...
The real problem is what package names would 'look nice' in connect
statements. I think qt.Widget is fine, but don't like the above at all.
> 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).
> > That is fine when all the KDE classes are in one package, but an
> > important enhancement will be to split them up into packages which map
> > onto the C++ namespace - 'kparts', 'kio' and so on. And as soon as the
> > KDE classes are in more than one package, the above solution doesn't
> > work.
>
> Wait a minute, the above statement (connect...) defines classes in a
> String. So the above solution will always work, because the slot requires
> always require packagename+classname.
The code special cases String. The problem is that there is no way of
discovering which imports a java class has used via reflection - it's a
compile time only thing. Here's the 'hacky' code from qtjava.java:
/** Converts any unqualified class names in a signal or slot string to the
fully qualified versions */
public static String toFullyQualifiedClassName(String className) {
if (className.equals("String")) {
return "java.lang.String";
} else if (className.equals("Date")) {
return "java.util.Date";
} else if (className.equals("Calendar")) {
return "java.util.GregorianCalendar";
} else if (className.equals("ArrayList")) {
return "java.util.ArrayList";
} else if (className.equals("ByteArrayOutputStream")) {
return "java.io.ByteArrayOutputStream";
} else if (className.equals("Job")) {
return "org.kde.koala.Job";
} else if (className.equals("Part")) {
return "org.kde.koala.Part";
} else if (className.equals("Slave")) {
return "org.kde.koala.Slave";
} else if (className.equals("DOMNode")) {
return "org.kde.koala.DOMNode";
} else if (className.startsWith("Q")) {
return "org.kde.qt." + className;
} else if (className.startsWith("K")) {
return "org.kde.koala." + className;
}
return className;
}
> I thing what you're ment to write is that classes used in Java code can be
> in the same package. But are there so many classes with the same name in
> KDE?
No, not many just a few like 'Document', 'Node' and one or two others.
-- Richard
More information about the Kde-java
mailing list