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

[Thomas Zander]

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.


> > > 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.

-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-java/attachments/20050618/fadff1b3/attachment.pgp