[Kde-java] Signals and Slots implemented in Java

[Marco Ladermann]

Am Montag, 20. Oktober 2003 13:37 schrieb Richard Dale:
> What if
> you are trying to connect to a slot which is inherited from a superclass -
> you have to get from the name of the class representing the slot to finding
> the actual implementation as a nested class inside an inherited widget
> class. How would the classnames for the slot and signal wrappers be
> autogenerated - say two slot methods were called foobar(), one took an int
> and one a string - what would the class be called?

Okay, I'm nearly convinced. Of course life should be made easier for humans 
not the compiler.

> Instead:
>
>     protected Proxy emit()
>     {
> 	String signalInterfaceName = this.getClass().getName() + "Signals";
> 	Object signalInterface = Class.forName(signalInterfaceName);
>
>             sigProxy =
>                 (Signal) Proxy.newProxyInstance(
>                     signalInterface.getClassLoader(),
>                     new Class[] { signalInterface },
>                     new QObject.SignalHandler(
>                         this
>                     )
>                 );
>
> Then as an enhancement it should walk up the inheritance heirarachy,
> getting any <classname>Signals interface it finds in the superclasses, and
> adding them to the array passed to the Proxy constructor.

This seems to be a good idea: have a interface for all signals (and another 
one for the slots) build by classname and appended "Signals" ("Slots").  But 
even if the lookup in the inheritance hierachy is simple, the user has still 
to know in which super class the interface is defined to call the appropriate 
signal method. The Proxy must be casted to this interface. What about also 
requiring that the super signal interface must be extended by the current 
class signal interface?

public class MyWidget extends QSuper {
  public interface MyWidgetSignals extends QSuperSignals {
    public void signal1(...);
    ...
    protected void signal2(...);
    ...
    protected void signal3(...);
  }

  public interface MyWidgetSlots extends QSuperSlots {
    ...
  }

  public void myMethod() {
    ((MyWidgetSignals) emit()).signal2(...);
    ((MyWidgetSignals) emit()).superSignal(...);
  }
  ...
}

The connect method can then stay as is, with SIGNAL and SLOT "macros" and 
signals and slot identified by strings.

> Perhaps the best thing would be to try and generate a 'prototype' api and
> see what it looks like - I might well be wrong - it's happened before :).
> It's just my feeling that what looks good with small test cases, wouldn't
> scale and be so tidy with the enormous Qt and KDE packages.

I'm not very used to the kalyptus system, but I will look at the source, if I 
can make some sense of it, so that we can look at something more but my 
previous toy code.

Marco