[Kde-java] Re: GCJ (Re: Build system for KDE4)

[Richard Dale]

On Thursday 16 June 2005 15:40, Thomas Zander wrote:
> On Thursday 16 June 2005 14:33, Martijn Klingens wrote:
> > For all practical purposes a clean API is not as important as being
> > able to leverage existing code and documentation IMNSHO.
>
> KDE is not the only API any Java programmer would be using; you know.  The
> majority of the API would be the java.* and the javax.* stuff.
> Being consistent with that is what will make this library easy to learn.
>
> Leverage existing docs or code is meant to say you expect people to copy
> paste C++ code and adapt that to Java?
> In that case you should probably try programming Java for some 6months
> since C++ is really different enough to not make that worth your while.
> Unless you want to answer questions like: "How do I do a
> macro/preprocessor/whatever in Java?"
>
> Anyway; just moving classes to other packages is really not going to make
> this stuff incompatible or whatever;  java IDEs will autodetect package
> and add it in your java file fully automatic anyway.
My main concern is to fix the existing problem with the Qt/KDE java bindings 
all being in only two packages, and the runtime doing a hack like 'does it 
the classname start with K or Q tests'. So how that is solved isn't so 
important to me, and technically changing the code generation to be driven 
off namespaces as against include file directories is easy. Nobody has said 
they like the existing scheme of 'org.kde.qt.QWidget' and that either 
'qt.QWidget' or 'qt.gui.QWidget' would both be better. In ruby that would be 
'Qt::Widget' and it is based on the C++ namespaces, not the include 
directory.  Nobody on the kdejava list has said that 'qt.Widget' looks good 
so far.

-- Richard