[Kde-bindings] What should I be doing?

[Richard Dale]

On Sunday 10 August 2003 22:25, Ashley Winters wrote:
> --- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> > On Sunday 10 August 2003 00:24, Ashley Winters wrote:
> > > The Ruby/Qt bindings look very functional, and Richard's idea
> > > for integrating Java/Qt with Smoke looks entirely
> > > feasable to me.
> >
> > Yes, the only problem with SMOKE/Java is that you can't dynamically
> > add signal methods to a java class. I'll need to use the current
> > QtJava java slot/signal proxies, and special case any methods
> > with actual or implied slot/signal args. But then I don't want to
> > see C++ types in the connect statements, so I would have needed to
> > special case C++ -> Java slot/signal type signature
> > translation anyway.
>
> *ahem*
>
> Might I propose something? :)
>
> Okay, here's my thought. How does one declare a signal in Java? Chew on
> this.
>
> class Foo inherits Bar {  // whatever. I don't know Java
>     protected Signal signalSomething;
>     public Slot foo;
>     Foo() {
>         signalSomething = new Signal(...);  // dunno how to do this
>         foo = new Slot(slotFunction);  // or something?
>
>         // now we do a connect...
>         signalSomething.connect(someobject.someSlot);   // easy!
>     }
>     public void doSomething() {
>         signalSomething.emit(bleh);    // emit our signal
>     }
> }
>
> :)
>
> Please place all donations in the cookie jar on your way out.
>
> Will this may every object hugely giant thanks to all the stub
> Signal/Slot objects which will be inherited from superclasses? Yes. So
> what? It's too beautiful to ignore. *sniff*
No - it doesn't work like that. There are two C++ QObject classes 'JavaSignal' 
and 'JavaSlot', and all possible slot type signatures in JavaSlot where every 
slot is called 'invoke'. The actual name of the java slot is held in an 
instance variable in JavaSlot 'invocation'.

public slots:
    void invoke();
    void invoke(bool arg);
    void invoke(char arg);
    void invoke(double arg);
    void invoke(float arg);
...
protected:
    jobject invocation;

You don't need to declare slots/signals in advance of using them in a 
connect() statement like you do in PerlQt and QtRuby. 

class Foo extends Bar {
	Foo()  {
		connect(SIGNAL("signalSomething(QWidget)"), someobject, SLOT("someSlot()"));
	}

	public doSomething() {
		QWidget myWidget = new QWidget();
		emit("signalSomething", myWidget);
	}
}

If the underlying Qt lib had a C++ signal called signalSomething with the same 
type signature, that would take precedence.

> > > However, each Smoke library attempts to be a self-contained unit
> > > containing its own "meaning" of every class. The smokekdecore
> > > library would have its own dataset entries for QObject and
> > > friends, even though it wouldn't provide an interface for them.
> > > This imprecise duplication of information leads to a coordination
> > > nightmare and a Tower of Babel type situation when attempting to
> > > communicate a simple thing like "QWidget pointer" between kdecore
> > > and kdeui and qt.
> >
> > I didn't know about this problem. I thought it all came down to
> > deciding how to allocate the base offsets for the various lookup
> > tables in each library, by leaving plenty of space in between each
> > of the ranges allocated.
>
> No. Each library has no insight into the numbering scheme of another.
>
> There is a mapping from classnames to numbers internally which makes
> things happy.
>
> QWidget => 1
> QObject => 2
> QPaintDevice => 3
>
> Internally, smoke only references the numbers, but every time you
> recompile, the numbers (presumably) change. For two libraries to
> communicate something like "QWidget pointer" the plan is to have them
> convert the number back to a string, pass that string to another
> library, and then convert the string into a number again using the
> other library's mapping. A tower of babel indeed. It was a convenient
> solution at the time, though.
Isn't it possible for the libraries to coordinate the ranges to use at 
startup, if they registered the current number ranges they used with a 
central authority and so on?

-- Richard