[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Quick KOM/Corba Question
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-01-06 12:06:07
[Download RAW message or body]

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.... 

><totally_non-related_question>
>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?
></totally_non-related_question>

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 - <tronical@gmx.net> - IRCNet #colorfast

Life's not fair. But the root password helps. :-)

[prev in list] [next in list] [prev in thread] [next in thread]