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

[Richard Dale]

On Saturday 18 June 2005 12:56, Thomas Zander wrote:
> On Saturday 18 June 2005 11:14, Richard Dale wrote:
> > On Friday 17 June 2005 11:41, Richard Dale wrote:
> > > > I created a signal/slot equivalent in an open source Java framework
> > > > since I was so frustrated by the standard way Java does things.
> >
> > Does this mean you don't like event listeners?
>
> Thats right; having lots of inner classes make it really hard to reuse
> stuff and really ugly to maintain.
Ok good we can leave them out of qtjava.

> > > > its a best of
> > > > both worlds solution that probably would be nice to use in the
> > > > bindings as well.
> > > > see:
> > > > http://uic.sf.net/api/20/uic/action/package-summary.html
> > > >
> > > > The framework is very mature (been in use for years) and has
> > > > features like multi-threading queues, action-locking and UI locking
> > > > (sleepy pointer) for actions running in another thread, and much
> > > > more.
> > >
> > > The slots/signals implementation in QtJava is mature too, and works
> > > fine, integrating seamlessly with the C++ slots/signals in the Qt and
> > > KDE classes.
> >
> > Sorry if I sound a bit rude here, I didn't intend to kill the design
> > discussion stone dead. Is there some way of combining the best bits of
> > the two approaches?
>
> I made the suggestion not because I don't like the QtJava approuch, I have
> not been able to compile kdebindngs yet, so I don't know.
> My main concern is that its incompatible with Java proper meaning the user
> has to use two different ways to do event connection in his programming
> if he is to use any part of Java that does event -based messaging
> together with the KDE libs.
>
> I do have to admit that the syntax looked quite un-java to me as well.
> Having emit() and SLOT() methods without a class scope in front it makes
> me uneasy.
>
> I feel its very important to make the bindings be just another library the
> Java programmer will want to use, which therefor has to fit in design and
> usage with all the other libraries of Java.  It may not be obvious so
> I'll mark it explicitly here; programming KDE Java means your app will
> likely be 2/3th Java and 1/3 KDE based.
I've got the same problem in qtruby, where the slots/signals are modeled quite 
closely on the C++ api and look a bit ugly and un-rubylike. So I was thinking 
of adding an alternative as well. On the other hand, I think it's useful to 
have an option close to the C++ api to make it easy to convert code from C++ 
to java. But if you were starting from scratch, you might want to use the 
version based on your design if it looked better. As long as the 
implementation underneath is the same and compatible.

-- Richard