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

List:       kde-devel
Subject:    Re: Quick KOM/Corba Question
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-01-06 23:38:02
[Download RAW message or body]

Hi,

On Wed, 6 Jan 1999, Simon Hausmann wrote:

> 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!!! :-)

Seems to be ok! Nice to see that there is another person now
who answers KOM questions :-)

Seems it was a good idea to invest some time in examples :-))

Bye
Torben

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