[Kde-bindings] Qyoto Custom Signal Arguments

[Richard Dale]

On Saturday 02 September 2006 16:42, Arno Rehn wrote:
> Am Samstag, 2. September 2006 17:29 schrieb Richard Dale:
> > On Saturday 02 September 2006 14:46, Arno Rehn wrote:
> > > Am Freitag, 1. September 2006 22:50 schrieb Arno Rehn:
> > > > Am Freitag, 25. August 2006 19:49 schrieb Richard Dale:
> > > > > On Thursday 24 August 2006 20:26, Arno Rehn wrote:
> > > > > > Am Donnerstag, 24. August 2006 20:24 schrieb Richard Dale:
> > > > > > > On Thursday 24 August 2006 19:07, Arno Rehn wrote:
> > > > > > > > But there's still one problem: arguments for custom signals
> > > > > > > > don't work. I took a quick look at the way it is done in
> > > > > > > > qt4-qtruby and it seems to be nearly the same.
> > > > > > > > When I watch the variables in the EmitSignal class, there is
> > > > > > > > something passed to the class. But apparently it isn't
> > > > > > > > processed correctly or so. Am I right, that
> > > > > > > > QMetaObject::activate() emits a signal?
> > > > > > > > I don't find any documentation about this method on the Net
> > > > > > > > or in the Qt docs and it doesn't appear in any of the
> > > > > > > > header-files. Any ideas what to do?
> > > > > > >
> > > > > > > The code to emit signals used to work, and so if it's now
> > > > > > > stopped it problably is only something minor, and it's a matter
> > > > > > > of tracing the code through the above steps to see where it
> > > > > > > goes wrong.
> > > > > >
> > > > > > Everything goes right, and exactly that is the thing that makes
> > > > > > me curious. The call comes to emitSignal() in the class
> > > > > > EmitSignal, the loop goes right and _qobj->activate() is called.
> > > > > > The signal is emitted, but all arguments are 0.
> > > > > > If I print the contents of, e.g.  s_int, I get a result, so the
> > > > > > arguments are passed to the class. But it seems as they are not
> > > > > > correctly "processed" by activate().
> > > > >
> > > > > I think it used to work with existing C++ signals, so I would try
> > > > > subclassing a QPushButton and emitting an existing signal like
> > > > > 'clicked()' that doesn't have any parameters to start off with. If
> > > > > it works with existing signals, but not custom ones it would mean
> > > > > that the QMetaObject wasn't being created correctly.
> > > >
> > > > OK, just tried it out. It doesn't work with existing signals either.
> > > > I attached the code of my test app. The code is quite self explaining
> > > > I think. It should print "MyTestApp 5" on startup. Instead I get
> > > > "MyTestApp 0". So the signal is emitted, but the parameters don't get
> > > > passed correctly.
> > > > Any ideas?
> > >
> > > My idea is to port the program to Ruby, there we can check every method
> > > return value and see, where the Qyoto stuff goes wrong.
> >
> > Yes, ok but you can't emit existing c++ signals in QtRuby like you can in
> > Qyoto, only ruby signals. That isn't normally a problem as I don't think
> > it's something you need to do other than for testing.
> >
> > In order to add slot return types to QtRuby I split off the code to
> > marshall to and from slots args into two C functions
> > smokeStackToQtStack() and smokeStackFromQtStack(). That change will need
> > to be ported to Qyoto, so perhaps have a try at doing the port as you
> > test?
>
> Should be no problem. But I wonder, when do you need slot return values?
> I've never seen a slot that returns anything. They are all of type void, or
> am I wrong?
For QDBus slots, I haven't seen any slots with return values in Qt itself.

-- Richard