On Wed, 06 Jan 1999, Kurt Granroth wrote: >[try saying the subject 10 times fast!] > >Anyway, I have a quick question about KOM and/or CORBA. The 'signals' >example in the corba package does a fairly good job of describing how >to use signals in KOM... but only within one application. This is >helpful, then, but not practical for "real world" use. If I was not >going to have interaction *between* apps, then it makes more sense to >just use "native" Qt signal/slots. > >Sooo, there *must* be a way of using KOM signals/slots between apps (else >why have them at all?). My quick question is: how? Can somebody with >a decent understanding of this explain in a few steps how one could modify >the signals example to have the Sender in one app and the Receiver in a >totally separate app and have them STILL send each other signals? Well, there's quite no difference between the examples (tutorial) and "real" ;) apps. On the sender's side you do something like (withouth signal args here, but this should be not _thing_ to modify) : Constructor: SIGNAL_IMPL( "KurtsSignal" ); And probably also: SenderApp::KurtsSignal() { SIGNAL_CALL0( "KurtsSignal" ); } Otherwise you can just do this SIGNAL_CALL0 directly whenever you want to emit you signal. So the SIGNAL_CALLx (where 0 <= x <= 2 (or was it 3?)) macro does the "final" signal call (corba request). And on the receiver's side: Receiver::Anywhere() { //let's pretend we have a reference to an instance of SenderApp called // m_vSender m_vSender->connect("KurtsSignal", this, "mySlot"); } Receiver::mySlot() { //here we are } buttthh: Make sure to have Receiver::mySlot() defined in the IDL-interface as well!!!!!! (just like in the example/tutorial) In addition you might have a look at KoHTML and how it makes use of several OpenPart signals. For example there's a highlighted signal in every opToolBar: (from openparts_ui.idl) /** * when not item is highlighted id equals -1 */ signal void highlighted( in long id ); Now let's beam over to KoHTML: (from kohtml_view.cc) In bool KoHTMLView::mappingCreateToolBar(OpenPartsUI::ToolBarFactory_ptr factory) : .... m_vMainToolBar = factory->create(OpenPartsUI::ToolBarFactory::Transient); .... m_vMainToolBar->connect("highlighted", this, "statusCallback"); and statusCallback() is defined in the idl like this: slot void statusCallback(in long ID); and in kohtml_view.h: virtual void statusCallback(CORBA::Long ID); But make sure you disconnect your slot/object at the appropriate time! Just to repeat it: There's no difference between the tutorial and "real" apps, you just need a proper reference to the objects you want to connect to. Just let me know if I missed anything.... > >Would it be at all possible to have slots that immediately return with >the KOM interface? That is, say there is > >App1: >void Receiver::slotClicked() >{ > for(;;); >} > >and > >App2: > sender->clicked(); > printf("Got here!\n"); > >With native signals/slots, you will never get to the printf. Is there a >way that the slotClicked() function would be called in app2 but execution >would continue in app1? > Hm.... I'm not quite sure but afaik the one possible solution would be to enter a local event loop. The point is that the CORBA dispatcher HAS to be able to receive requests (and to finish them, too) ! And since we use something like qtmico (If I understood that right.... Torben: correct me if I'm wrong!!!) the dispatcher is integrated in the qt event handling. But I guess all this is not really possible cause I actually don't have a real clue how to return to the dispatcher (to finish the corba request/invokation) (who actually called slotClicked()) and afterwards come back to slotClicked() ....hm... /me is somehow clueless ;-) >-- >Kurt Granroth >granroth@kde.org >http://www.pobox.com/~kurt_granroth Greets, Simon P.S.: Torben: PLEASE correct anything wrong here!!! :-) -- Simon Hausmann - Tronical^Colorfast - - IRCNet #colorfast Life's not fair. But the root password helps. :-)