| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The gdata_documents_entry_get_path API doesn't work with Drive v2
because each entry's JSON only has its immediate parents, not the full
chain.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GDataDocumentText is bound to application/vnd.google-apps.document,
which represents native Drive-specific text documents. Anything that's
not a Drive-specific type, except PDFs, are meant to be represented as
GDataDocumentsDocument.
Trying to upload an ODT as a GDataDocumentText confuses things. We
pass the ODT's MIME type to the GDataUploadStream, which is not the
MIME type of the associated entry. The updated GDataEntry that is
obtained as a side-effect of the upload is set to match the stream's
MIME type. Therefore it is a GDataDocumentDocuments, which isn't the
same type as the initial entry we started with.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
|
|
|
| |
We are uploading the ODT as a GDataDocumentsDocument, but somehow
expect it to become a GDataDocumentsText when downloading. That's a
bit bizarre. More importantly, in Drive v2, only PDFs and
Drive-specific content types are supposed to be represented by the
GDataDocumentsDocument sub-classes. Therefore, it is wrong to expect
an ODT to somehow become a GDataDocumentsText.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
| |
Don't attempt including other headers only to be blocked by their
individual header guards.
https://gitlab.gnome.org/GNOME/libgdata/merge_requests/3
|
|\
| |
| |
| |
| | |
Remove use of foreach with wrong function prototype and use g_list_free_full
See merge request GNOME/libgdata!1
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Only build the GTK+ examples if enabled explicitly with --enable-gtk, or
if --enable-gtk is not specified and GTK+ is available.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787210
|
|
|
|
|
|
|
|
|
| |
GDataDocumentsFolders' resource IDs should have the "folder:" prefix,
not "documents:".
Fallout from d93279623e34c7b275ae3f989b54c6f3a30d5658
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
| |
This will be used by GDataDocumentsDocument and GDataDocumentsFolder to
set their resource IDs right after parsing the JSON.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
| |
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793367
|
|
|
|
|
|
|
|
|
| |
It requires network access, so is not suitable for running on build
machines as per Debian policy. Skip it unless running ‘slow’ tests.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838530
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems the server permits empty websites (with an empty URI) to be
added to contacts. This seems to contradict the specification (or, at
least, is not mentioned as allowed).
https://developers.google.com/google-apps/contacts/v3/reference#gcWebsite
Rather than accepting such nonsensical websites and exposing them to the
user of libgdata to deal with, it seems better to drop them from the
XML. This means that we don’t round-trip perfectly, but I can’t see how
that can cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=790671
|
|
|
|
|
|
|
|
| |
In some situations, it makes sense to ignore child elements if they fail
to parse properly, rather than propagating that error up to the parent.
See the following commit for an example of such a situation.
https://bugzilla.gnome.org/show_bug.cgi?id=790671
|
|
|
|
|
|
| |
Do. Not. Push. Without. Compiling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
|
| |
Use the right pagination type to avoid an assertion failure.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=786532
|
|
|
|
|
|
|
|
| |
See also https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration
Signed-off-by: Niels De Graef <nielsdegraef@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787252
|
|
|
|
|
|
| |
Signed-off-by: Niels De Graef <nielsdegraef@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787252
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The former is for the build system to use; the latter is for the user to
override what the build system says.
See
https://www.gnu.org/software/automake/manual/html_node/Checking-the-Distribution.html.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
| |
See a9c8516b4380a213cd92d83a11f9793414588319 for the rationale.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
| |
Based on similar code found elsewhere in the test suite.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
|
|
| |
parse_json() unref's the passed in GDataParsable, but it does not own a
reference to it. This was causing runtime warnings/criticals when
testing a youtube URL with grilo-test-ui-0.3
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787872
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d10155034b0fa2e43e2889e55157798ce073f807.
It looks like Google may now have fixed the timezone formatting bug in
their Tasks services (they had previously fixed it in their other services;
see bug #780067).
https://bugzilla.gnome.org/show_bug.cgi?id=785952
|
| |
|
|
|
|
| |
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
|
|
| |
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
|
|
|
|
|
| |
I don’t think it likes the mixture of attributes after the argument
list. Changing the line wrapping seems to fix it.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
|
|
|
|
|
| |
Also relabel the ‘Documents API’ to ‘Documents/Drive API’ to make it a
bit clearer that it now covers Google Drive.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
|
|
| |
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Querying a feed of Drive entries using Drive v2 leads to:
CRITICAL **: _gdata_query_set_next_uri: assertion
'self->priv->pagination_type == GDATA_QUERY_PAGINATION_URIS'
failed
When the support for pagination using page tokens was landed in
commit 38b934a9ef9dab89, the code in GDataDocumentsService::parse_feed
that added the next and previous URIs from the feed to the GDataQuery
was generalized and moved to GDataService::parse_feed, and
GDataDocumentsQuery was set to use pagination tokens.
The intention was to use pagination tokens for GDataDocuments* using
only the generic parsing code in the base classes.
However, the code in GDataDocumentsFeed::parse_json that added the
GDataLinks for the next URI to the feed wasn't removed. This tricks
GDataService::parse_feed into using pagination URIs with the
corresponding query.
This reverts commit fa3e219eff1d4617463a86deb14cb3b1f5fb9a19.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
| |
In Drive v2, we can only remove an entry from a folder if it had
multiple parents to start with. If there was only a single parent, then
the request is just ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
| |
These are the last instances of GSimpleAsyncResult. Die!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
| |
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
| |
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
| |
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|