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

Richard Dale Richard_Dale at tipitina.demon.co.uk
Fri Jun 17 11:41:38 CEST 2005


On Friday 17 June 2005 12:19, Thomas Zander wrote:
> On Friday 17 June 2005 10:44, Richard Dale wrote:
> > Have you seen this comparison between the java-gnome bindings and the
> > GTK# ones:
> >
> > http://people.redhat.com/~graydon/csharp-java/
> >
> > It seems the main difference is in the event listener stuff vs. csharp
> > delegates. For QtJava we could add a similar layer of event listeners
> > classes on top of the autogenerated bindings, probably based of
> > QObject::eventFilters. Then it might look more familiar to a java
> > programmer. I've never programmed event listeners, so I'm the wrong
> > sort of person to judge whether they look 'more java-like', than
> > signals/slots or subclassing event handling methods in QWidgets.
>
> Signal/slot is a technology that requires a pre-compiler due to lack of
> introspection in C++.
Well, no language binding needs a pre-processor; python, ruby, java, perl all 
solve that problem in different ways. You can create a QMetaObject at 
runtime, instead of at moc generation time for instance. QtJava doesn't do 
that, but it is possible.

> In Java the introspection is there and it can be done, except that the
> SLOT() syntax with a function name in there is not possible since thats a
> macro.
> Whats left is the option to type the method name as a string and on
> connection find out which method that is.
Yes, that's right.

> Signals; however are completely impossible in Java the way they are done
> in Qt. You need event broadcasters for that. an 'emit' keyword is
> unavailable.
Well, have you looked at some code with slots/signals in QtJava? From the 
ScribbleWindow example:

QObject.connect( _colormenu, SIGNAL( "activated( int )" ),
                         this, SLOT( "slotColorMenu( int )" ) );
...

QObject.connect( this, SIGNAL( "colorChanged( QColor )" ),
                        _scribblearea, SLOT( "setColor( QColor )" ) );
...

private void slotColorMenu( int item )
{
	switch( item )
	{
		case COLOR_MENU_ID_BLACK:
			emit("colorChanged", black());
			break;
		case COLOR_MENU_ID_RED:
			emit("colorChanged", darkRed());
			break;
		case COLOR_MENU_ID_BLUE:
			emit("colorChanged", darkBlue());
			break;
		case COLOR_MENU_ID_GREEN:
			emit("colorChanged", darkGreen());
			break;
		case COLOR_MENU_ID_YELLOW:
			emit("colorChanged", yellow());
			break;
	}
}

In the first connect statement, SIGNAL("activated(int)") is a C++ signal, and 
in the second  SIGNAL( "colorChanged( QColor )") is a java signal. They have 
the same syntax. emit() is not type safe and I do have a better idea for 
QtJava v2 using dynamic proxies. Note that interfaces for signals are 
generated like this for QPopupMenuSignals.java looks like this:

//Auto-generated by kalyptus. DO NOT EDIT.
package org.kde.qt;

public interface QPopupMenuSignals {
	void activated(int itemId);
	void highlighted(int itemId);
	void activatedRedirect(int itemId);
	void highlightedRedirect(int itemId);
	void aboutToShow();
	void aboutToHide();
}

> I created a signal/slot equivalent in an open source Java framework since
> I was so frustrated by the standard way Java does things.  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.

-- Richard


More information about the Kde-java mailing list