[Bug 32125] Should support auth using captcha

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32125

--- Comment #14 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-02-07 10:03:05 PST ---
(In reply to comment #12)
> After talking with Thiago, we definitely need to add a signal for Status, as
> QtDBus does not (want) to support property changes over the bus.

So there are two possibilities here:

If QtDBus doesn't provide high-level convenience API to emit or receive
PropertiesChanged automatically (much like the way dbus-python doesn't handle
Properties at all), but can emit/receive it like any other signal via explicit
code in services/clients, then we can deal with that. If this is the case, IMO
the interface should still use the standard PropertiesChanged signal, and we
should put glue in telepathy-qt to make it easier to emit and/or receive if
necessary, perhaps something like:

    SomeHelperClass::emitPropertiesChanged(QDBusConnection *,
        const QString &objectPath,
        const QString &iface,
        const QVariantMap &valuesProvided,
        const QStringList &invalidated);

on the emitting side, and

     signal Tp::Proxy::propertiesChanged(QString iface,
         QVariantMap valuesProvided,
         QStringList invalidated);

on the receiving side.

(For those who didn't follow the design of that signal: "valuesProvided" is a
map from property names to their new values, whereas "invalidated" is a list of
properties whose values have changed, but which the service has declined to
include in valuesProvided, for instance for performance or secrecy reasons.
Clients may retrieve them via GetAll() or something if desired.)

On the other hand, if QtDBus is actively obstructive and prevents us from
emitting and/or receiving PropertiesChanged even via generic "any signal"
stuff, then we need to know about that so we can avoid relying on
PropertiesChanged *anywhere*. That'd be a problem - we already have interfaces
that rely on it, like Chan.I.Subject2. To work around this, we'd either have to
add our own PropertiesChanged to each interfaces (like the current
Account.AccountPropertiesChanged, or any oFono interface), or add a new
interface with one signal with semantics identical to those of
PropertiesChanged and use that to work around Qt.

Which is it?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.