[Bug 31376] TpFileTransferChannel : high level API for FT

[bugzilla-daemon at freedesktop.org]

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

--- Comment #24 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2011-07-13 05:50:17 PDT ---
(In reply to comment #22)
> +  features[FEAT_CORE].name = TP_FILE_TRANSFER_CHANNEL_FEATURE_CORE;
> +  features[FEAT_CORE].core = TRUE;
> 
> Does that mean the feature will be prepared automatically at object
> construction, or just that if we call tp_proxy_prepare_async() that feature
> will be prepared first?

Both.

> Also you forgot to list it in the automatic factory's
> dup_features().

I added it to dup_features().

> +    /* Hidden properties */
> +    GHashTable *available_socket_types;
> 
> For string properties it is obvious that they are borrowed from
> immutable_properties table because they are "const gchar *" but you should
> comment that this GHashTable is borrowed too, was wondering why it is not
> unreffed in dispose/finalize. Note that you could actually ref it (that's
> cheap,  unlike strings).

I added a comment.

> TpFileTransferChannel:content-type:
> 
> This is actually a MIME type according to spec. This property name is confusing
> because in GLib world content-type != mime-type: "A content type is a platform
> specific string that defines the type of a file. On unix it is a mime type, on
> win32 it is an extension string like ".doc", ".txt" or a percieved string like
> "audio"." See for example g_content_type_from_mime_type().

Good catch; I renamed it to mime-type.

> +  /**
> +   * TpFileTransferChannel:size
> +   *
> +   * A 64-bit guint holding the size of the file to be transferred.
> s/A 64-bit guint/A guint64/ ? Should be a

fixed.

(In reply to comment #23)
> Same comment for TpFileTransferChannel:transferred-bytes

fixed.

> Overall I find the doc minimalistic to what the value really means. The tp spec
> is more useful and I don't think we should rely on reading the spec for each
> property... Maybe copy/paste a bit of the spec into the gtk-doc would be
> useful. I think especially about filename property, the spec describe much
> better what it really means. "filename" could mean an absolute path, etc...

I improved the doc.

>         $(srcdir)/text-channel.c $(srcdir)/text-channel.h \
> +    $(srcdir)/file-transfer-channel.c $(srcdir)/file-transfer-channel.h \
> 
> Indentation seems wrong

fixed.

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