[Kde-bindings] Qyoto Custom Signal Arguments

[Arno Rehn]

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?

-- 
Arno Rehn
arno at arnorehn.de