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

List:       kde-core-devel
Subject:    Re: Signals/slots via DCOP
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-08-04 18:10:24
[Download RAW message or body]

On Fri, 04 Aug 2000, Matthias Ettrich wrote:
> > Ok, DCOPServer / DCOPClient have support for "sending object" now. Shall
> > I put some wrappers for emit / connect /disconnect in DCOPObject?
>
> sounds reasonable.
>
> > I can also disconnect all connections from a certain object but at the
> > moment objects themselves don't know if anyone has connected to them. So
> > you would always need to do a DCOP call from the DCOPObject destructor.
> > The other option is that the dcopserver informs the object when someone
> > connects to it so that it can keep a count.
>
> Not sure whether Is that really necessary. Right now the connection dies
> with the application. The only difference in semantics is if you create an
> object, make a connection, delete the object again and then create another
> object with the same address and name.

It's unlikely to bite us. Then again, we don't want to have an ever 
increasing number of (not used) connections building up inside the dcopserver.
(they will still be flushed when the client exits of course)

> hmmm... on the other hand we are talking DCOP objects here, not QObjects.
> There are very few of them. So I'd say *if* there is at least one
> connection (bitflag in DCOPObject), 

I don't know *if* there is a connection. More precisely, I don't know if 
someone else has connected to a signal of my object. I only know when I 
connect a signal of some object to a slot in my object.

> we make a dcop call in the destructor (unless qApp->closingDown() )

I think I just do that. For the time being these DCOP objects aren't very 
dynamic anyway.

Cheers,
Waldo
-- 
Make way, KDE/Linux is coming to a desktop near you!

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