[Kde-java] Signals and Slots implemented in Java

[Richard Dale]

On Monday 20 October 2003 16:10, Marco Ladermann wrote:
> Am Montag, 20. Oktober 2003 13:37 schrieb Richard Dale:
> > 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"). 
I would be in favour of having Slots interfaces, but it would add more classes 
to the huge kde. package. It should still be possible to do a check via 
reflection that the target instance has a void method with the name and types 
matching the one in the SLOT() string.

> 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?
I think you would invariably want to emit a signal that was in the interface 
for the current class, rather than emit inherited ones. In the current JNI 
java bindings the Signals interfaces for a class contain all the inherited 
signals - the heirarchy is flattened. But in the current version of the proxy 
based api, the Signals are just for the ones in the original Qt class, not 
its parents.

> 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(...);
>   }
>   ...
> }
Yes, that looks good to me. Is MyWidgetSignals visible outside MyWidget, does 
it mean the same as this?

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

> 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.
I'll try and get back on the java code generation when I've done a bit more on 
ruby, I can't seem to do both at once. I think we've got a few ideas to try 
out now anyway.. 

But I can explain which bits of kalyptus need changing. Look in 
kalyptusCxxToJava.pm for these three methods - if you need to generate a 
class for each slot, then that would go in 'generateMethod()'.

sub writeClassDoc

sub generateAllMethods($$$)

sub generateMethod($$$$$$)


-- Richard