dcopserver and KDE4

[Simon Hausmann]

On Thursday 10 November 2005 20:10, George Staikos wrote:
> On Thursday 10 November 2005 13:08, Thomas Braxton wrote:
> > >    Ok, that's what I thought.  "I don't know" and "probably".  Let's
> > > wait until we have a situation where you can say "KDE2 apps -cannot-
> > > work because X, and X cannot be fixed."
> >
> > I didn't say they can't be fixed. I just don't think KDE2 *binaries*
> > would work, since the QDataStream format has changed between versions,
> > the DCOP wire protocol would be different. But I don't have any KDE2
> > binaries around to test. I think with regards to dcopServerFile(), KDE2
> > _is_ source compatible, so a recompile would make them binary and wire
> > compatible again. KDE2 dcopserver would have a problem because it uses
> > it's own version of dcopServerFile().
>
>    My understanding, though I haven't checked, is that the wire protocol is
> not supposed to change.

Unfortunately it changes automatically through the use of QDataStream to 
define the wire protocol. All the datastream objects that we create for dcop 
calls for example never have any setVersion() calls on them, so they stick to 
the default of the qt library the program links against.

A Qt3 application has a different default format as a Qt2 one, so if a Qt3 
application sends a message over dcop to a Qt2 one it will break as soon as a 
type is unpacked that uses a different marshalling depending on the 
datastream version. This is usually not a problem with base types such as 
QString and integer objects, but it breaks for example with QPen (which in 
Qt3 streams a style, width and color and in Qt4 it streams a floating point 
width, a brush, a miter limit and a dash pattern). It breaks in the sense 
that the application is very likely to crash.

As the documentation says the only way to enforce forwards and backwards 
compatibility with QDataStream is to use a fixed version all the time. A bit 
like

struct DCOPDataStream : public QDataStream
{
public:
    DCOPDataStream(...) : QDataStream(...) { setVersion(...); }
};

And then we would have to force everyone to use DCOPDataStream, so that all 
the types have the same format as Qt 2.3.1 in KDE 2.

But given that most of the time people send integers and strings over 
DCOP /and/ they usually run the entire desktop using one or multiple 
compatible Qt versions it appears that this has never bitten us in the past.

Simon