Created attachment 39859 [details] [review]
patch 2

Created attachment 39860 [details] [review]
patch 3

Created attachment 39861 [details] [review]
patch 4

Created attachment 39862 [details] [review]
patch 5

Review of attachment 39859 [details] [review]:

::: TelepathyQt4/capabilities-base.cpp
@@ -161,3 @@
     uint targetHandleType;
     foreach (const RequestableChannelClass &cls, mPriv->classes) {
-        if (!cls.fixedProperties.size() == 2) {

This looks like a real bug, in fact; the precedence isn't what the author of this code expected.

The fix should be "if (blahblah.size() != 2)", though :-)

(In reply to comment #5)
> Review of attachment 39859 [details] [review]:
> 
> ::: TelepathyQt4/capabilities-base.cpp
> @@ -161,3 @@
>      uint targetHandleType;
>      foreach (const RequestableChannelClass &cls, mPriv->classes) {
> -        if (!cls.fixedProperties.size() == 2) {
> 
> This looks like a real bug, in fact; the precedence isn't what the author of
> this code expected.
> 
> The fix should be "if (blahblah.size() != 2)", though :-)
Ooops :D. I fixed this in my rcc-high-level branch that should be merged any time soon.

(In reply to comment #0)
> Created an attachment (id=39858) [details]
> patch 1
> 
> I've made some changes to get telepathy-qt4 compile with MSVC 9.

This is fixed in my lib-enable-deprecation-warns branch. The correct would be DEPRECATED instead of EXPORT, probably copy/paste error. It's just waiting for review.

> Created an attachment (id=39860) [details]
> patch 3

Why do you need that? QString has a constructor taking a QL1S

(In reply to comment #3)
> Created an attachment (id=39861) [details]
> patch 4

The public API for qdbus_cast only receives 1 param, I wonder why this does not work for you, or even worst, works by passing a new param.

(In reply to comment #4)
> Created an attachment (id=39862) [details]
> patch 5

This is a bug in tp-qt4, these methods should have never being exported. We will fix this for 0.5.0 (API break version) that should be out next month.

(In reply to comment #8)
 
> Why do you need that? QString has a constructor taking a QL1S

Sorry I forgot to explain that in the commit message. The reason for this patch is basically the most vexing parse. MSVC treats the constructor invocation as a function declaration and fails with this error message:

channel.h(244) : error C2751: 'Tp::Client::ChannelTypeContactSearchInterface::staticInterfaceName' : the name of a function parameter cannot be qualified
see reference to function template instantiation 'Interface *Tp::Channel::typeInterface<Tp::Client::ChannelTypeContactSearchInterface>(Tp::OptionalInterfaceFactory<DBusProxySubclass>::InterfaceSupportedChecking) const' being compiled

(In reply to comment #9)

> The public API for qdbus_cast only receives 1 param, I wonder why this does not
> work for you, or even worst, works by passing a new param.

Actually qdbus_cast receives 2 parameters, but the second one is excluded from the API documentation:

template<typename T> inline T qdbus_cast(const QDBusArgument &arg
#ifndef Q_QDOC
, T * = 0
#endif
    )

(In reply to comment #11)

Another way to work around the problem is to use an additional set of parenthesis:

QString name((QLatin1String(Interface::staticInterfaceName())));

It would occur to me you're working on this already, Andre :)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-qt/issues/12.