RFC: problems with splitting up kdebase

[Thiago Macieira]

David Faure wrote:
>You're starting from a situation where everything works already.
>But this isn't the case. We're porting from dcop, and many dbus
> interfaces were written without testing. Therefore the need for adding,
> removing, fixing typos, etc. We're not at "binary compatibility" stage
> yet, (by far, for some dbus interfaces).

Indeed, for this stage in development, I agree that auto-generating is 
better.

But are we going to go back to pre-generated files? In special, what about 
the tarballs?

>Plus the fact that any fix to dbusxml2cpp would not benefit the adaptors
>if the adaptors were not automatically generated.

No major changes are expected soon. This is not an issue.

>Hand-written adaptors are a very bad idea also because of the
> introspection xml in the .h - who's gonna maintain this by hand in
> addition to the adaptor and the real xml file? One change, three
> places? Bah.

The XML in the .h is just there to speed up the lookup. If it isn't there, 
one will be auto-generated. Hand-written adaptors are nothing more than a 
QObject-derived class with a special classinfo (the interface name). Just 
like hand-written non-adaptors.

>But this isn't only about the porting. When writing a new dbus
> interface, I have seen far too often people fixing the adaptor by hand
> so that it compiles but not updating the .xml accordingly. As a result,
> you get a mismatch and stuff doesn't work.

Remove the XML then. Like I said, it's just there to avoid building the 
XML at run-time in the first place. I tinkered with the idea of 
precompiling the entire metaobject in my own branch. Again: completely 
optional.

>> If an adaptor is generated from a .xml file and that .xml got updated
>> (compatibly), then it means that any NEW methods will not be
>> implemented.
>
>Well the point is that you will have to implement them, since the
> adaptor is calling parent->foo() so you need to implement foo() for
> this to compile. Which is good - you can't forget to implement it.

Indeed, that's the point: if you updated the XML, it means you are about 
to update the implementation as well.

In this stage in development, I agree that causing errors is best, to 
catch porting errors. But once the interface is established and 
published, there's no need to continuously update the XML file. In 
special, the XML description can diverge from the implementation.

>> Ok. What I described above is equivalent to duplicating the .xml files
>> and not updating all of them.
>> The difference being that only one of the many .xml files can be
>> installed. We have to choose which one.
>
>You lost me a bit here. Is this with the idea of "xml files in kdelibs"?
>So:
>kdelibs/interfaces/dbus/org.kde.KWin.xml with the kde-4.0 konq
> interface, (and installed into <prefix>/share/dbus-1/interfaces/)
>and kdebase/workspace/kwin/org.kde.KWin.xml with the post-4.0 interface
> (not installed) including new methods, and the adaptor generated from
> it, implementing those methods.

There's one authoritative source for the XML files. That's the one that is 
installed. Call it "the original".

All other files about the same interface are "copies". They don't ever get 
installed. Whether they are more recent or less is no matter.

If KDE is implementing a third-party interface (say, a freedesktop.org 
interface), its XML file is a "copy", so it won't be installed.

You can avoid the "copies" problem by generating the adaptor once at 
development time, not at build-time.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070627/beccbe1e/attachment.sig>