[Kde-bindings] Qyoto: SIGNALS/SLOTS

[Arno Rehn]

Am Donnerstag, 8. Dezember 2005 21:58 schrieb Richard Dale:
> On Thursday 08 December 2005 19:32, Arno Rehn wrote:
> > Am Mittwoch, 7. Dezember 2005 17:43 schrieb Richard Dale:
> > > On Wednesday 07 December 2005 15:36, Arno Rehn wrote:
> > > > Hi,
> > > >
> > > > I experimented a bit and created a more complex Hello-World sample
> > > > app. I wanted to connect the "clicked()" signal of a button to the
> > > > "quit()" slot of QApplication. Got a SIGSEGV.
> > > > I looked into the Qt.cpp of qtruby and it seems as signals and slots
> > > > are a bit difficult.
> > >
> > > QtRuby dynamically constructs QMetaObjects, rather than it being done
> > > at compile time by the moc pre-processor. But the actual runtime is
> > > identical. We need a way of denoting which methods are slots in C#, and
> > > I assume we can use 'attributes' (or are they called 'annotations' I've
> > > forgotten). Maybe you could have a look at how we might mark slots, and
> > > then the runtime side should be very similar to QtRuby. We don't have
> > > to invent anything much new apart from that.
> >
> > OK, I found out how to mark Signals/Slots with Attributes. I attached an
> > example.
>
> That looks good. In Qt4 there is a macro 'Q_SLOTS' to use instead of the
> 'slots' moc keyword because of a clash with the Boost library. So maybe
> slots could be marked like this, to look more like that macro:
>
> 	[Q_SLOT()]
> 	public void mySlot()
> 	{
> 	}
>
> Maybe signals need to map onto delegates, rather than ordinary methods.
Would be a good idea. Maybe signals need to be delegates, which are set by the programmer or  'QObject.Connect()'. Could look like this:

	public class QApplication : ...
	{
		delegate void LastWindowClosedHandler();
		
		[Q_SIGNAL()]
		LastWindowClosedHandler LastWindowClosed;
		
		...
	}

Now we could just say 'LastWindowClosed' is set by the programmer. This would keep the delegate-system of Mono/.NET. Additionally it would be possible to create a 'QObject.Connect(...)' which dynamically connects 'LastWindowClosed' to another method.
But I don't know how to check whether the underlying C++-instance triggered the signal. Then it would be quite easy to call the appropiate delegate.

> At the moment an interface is generated containing the type signatures of
> signals like this:
>
> 	public interface IQApplicationSignals {
> 		void LastWindowClosed();
> 		void AboutToQuit();
> 		void GuiThreadAwake();
> 	}
>
> And I was thinking of having a QObject.Emit() method which returned a
> transparent proxy, so you could invoke a signal with like this:
>
> (LastWindowClosed) myInstance.Emit()
>
> And it would be forwarded to SignalInvocation.Invoke(), in a similar manner
> to how ordinary method calls get diverted to SmokeInvocation.Invoke() at
> the moment.
>
> But slots are easiest to get working first though, and marking them with
> attributes like you've done looks pretty good to me.
>
> -- Richard
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings

-- 
MfG
Arno Rehn
arno at arnorehn.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20051209/aa7f1541/attachment.html>