"The result is that org.kde.plasma-desktop.PlasmaApp is
not registered with QtDBus when KDE starts, which can cause problems elsewhere."

the problem is in libdkeui, actually, and affects all KDE apps that have app names that don't match the dbus spec. moreover, it does appear on the bus as dbus-daemon doesn't enforce this and QtDBus can reach it just fine as well.

it's a thus-far harmless warning. i'm working up a patch against libkdeui in any case to hopefully get rid of these warnings because it only causes undue panic and bug reports. we'll see :)

"the problem is in libdkeui, actually, and affects all KDE apps that have app
names that don't match the dbus spec. moreover, it does appear on the bus as
dbus-daemon doesn't enforce this and QtDBus can reach it just fine as well."

QtDBus is generating those messages because it is refusing to process invalid D-Bus names. I have a bug report with Nokia where I proposed a patch to make QtDBus accept the names for compatibility purposes and it was rejected:

http://bugreports.qt.nokia.com/browse/QTBUG-10927

If you look at the source code of QtDBus, you will see that it is refusing to register the invalid names, so this is not necessarily as harmless as it seems.

this is not about properties (which is the br you note in Qt) and obviously it works with Qt otherwise plasma-desktop would not be reachable by other apps. it's a cosmetic issue currently and having talked with thiago about this particular issue on kde-core-devel it's actually a problem with qt itself (since it is generating this particular name before putting it on the bus)

Nokia's developers said in the upstream bug report that when this happens, it means there is a problem in other people's software, not theirs. The D-Bus specification explicitly disallows the use of '-' in interface names, which means that KDE is non-compliant.

Here is the source code in question from ./src/dbus/qdbusxmlparser.cpp in QtDBus 4.6.2 that deals with this:

        // parse methods
        QDomNodeList list = iface.elementsByTagName(QLatin1String("method"));
        for (int j = 0; j < list.count(); ++j)
        {
            QDomElement method = list.item(j).toElement();
            QString methodName = method.attribute(QLatin1String("name"));
            if (method.isNull())
                continue;
            if (!QDBusUtil::isValidMemberName(methodName)) {
                qWarning("Invalid D-BUS member name '%s' found in interface '%s' while parsing introspection",
                         qPrintable(methodName), qPrintable(ifaceName));
                continue;
            }

            QDBusIntrospection::Method methodData;
            methodData.name = methodName;

            // parse arguments
            methodData.inputArgs = parseArgs(method, QLatin1String("in"), true);
            methodData.outputArgs = parseArgs(method, QLatin1String("out"), false);
            methodData.annotations = parseAnnotations(method);

            // add it
            ifaceData->methods.insert(methodName, methodData);
        }

The code clearly refuses to register anything it deems to be an invalid interface name. If that is not the case, then something is causing the continue statement to be ignored and I do not see how that can happen here.

Perhaps things work inspite of Qt-DBus's rejection of the interface names because D-Bus accepts the names and QtDBus is just a wrapper for that, in which case the names are still broadcast to the outside world, but anything that asks QtDBus for them won't receive them. I don't write code that interacts with either Qt or DBus, so I cannot verify this, although I assume that is why plasma-desktop appears to work fine with other applications. It would depend on how QtDBus is designed, but I expect that anything that asks QtDBus if plasma desktop is present would break because QtDBus would say no (and would possibly produce an error message because it was asked a question about an invalid interface name).

Richard, please do not reopen this report. I've discussed this with Thiago, maintainer of QtDBus and the conclusions are:

* in this case, it works just fine even if it is technically a violation of dbus. Yes, that includes with QtDBus (obvious proof: not only does plasma-desktop appear on the dbus, but other Qt/KDE apps talk to it over dbus)

* the problem in this case is in Qt, according to Thiago.

the problem you are describing and this one are slightly different. this is not about dbus properties.