[Kde-java] Qt and KDE java package names

[Richard Dale]

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