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

List:       kde-devel
Subject:    Re: dcop question
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2005-08-09 5:35:14
Message-ID: 200508090735.17288.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 08 August 2005 22:44, Luke Sandell wrote:

> > What about type safety in these cases?
>
> DCOPRef has type safety built in. Use the three argument constructor to
> include a typename and the type() method to retrieve it.

Okay -- I indeed found a reference to the three-argument constructor. But I'm 
having a hard time finding something about using the type() method.

> > class KisImageIface : virtual public DCOPObject
> > {
> >         K_DCOP
> > public:
> >         KisImageIface( KisImage *img_ );
> > k_dcop:
> >
> >  bool raise(KisLayerSP layer); // This?
> >  bool raise(DCOPRef layer); // Or this?
> > }
>
> If you include both raise(...) methods, then the former should be public,
> while the later should be k_dcop. However, wouldn't it be better to have a
> raise() method (with no parameters) in KisLayerSP instead?

The raise(kisLayerSP layer) is in KisImage; the other one is in KisImageIface 
-- you're right of course about the design, but this is just a clear example. 
There are also things like addLayer(KisPaintDeviceSP dev). (Where all SP type 
are smart pointers wrapped around the original class).

Is there a way, by the way, to send and receive byte arrays in dcop?

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

 =

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<


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