Move along, nothing to see...

...here. Yet.

"Yet" because I don't have anything to commit as all involved code is littered with commented codeblocks of failed attemps.

I am talking about a QObject adapter for the Qt3 D-BUS bindings, i.e. a wrapper class that makes slots of a given QObject instance callable through D-BUS.
Generating D-BUS introspection data from the slot signature is next.

Finding out how to call slots wasn't that difficult, any moc output file gives you plenty of hints.
The hard part is to get the details of all this "QU*" classes (leftovers from Universal Objects?) and to set the actual parameter data.

While I understand that the headers in qt-includes/private/ are not documented because they are private, why the heck do I have to hack a giant switch() for the QVariant types when there is this nice, public, QVariant::rawAccess method?


At least I have finally reached the point where the current binding's marshalling code isn't sufficient anymore.

So I guess I will be adding "writing a variant datatype class" to my C++ knowlegde portfolio soon.
Unless someone else contributes one (hint, hint) ;)


Not sure what kde's stance on using Boost is, but boost::variant is a nice class.


Though, if it were me, I'd probably just use QVariant::rawAccess until such point as it went away. If they didn't want you to use it, they wouldn't make it public, right? :)

By matelich at Mon, 02/06/2006 - 16:36

i have a more portable version of the boost::any object that works fine for values and another one that works pretty well for pointers. i use it in kjsembed because of some limitations on QVariant. afaik it even compiles under VC 6.0.

By Ian Reinhart Geiser at Mon, 02/06/2006 - 18:35

Thank you to both of you.

I have actually very limited requirements as D-BUS only specifies a handful of datatypes, but I need some kind of type to denote a general complex type, e.g. a class or struct.

Hmm, there could also be a better way as I am currently modelling the Qt3 bindings quite closely to the Qt4 ones.

The current idea is to let the application split/merge class members into a list of base types and let the bindings marshaller transform from/to D-BUS wire-format.

Should I take the discussion to some mailinglist?
kde[-core]-devel or kde-bindings?

By krake at Mon, 02/06/2006 - 20:54