| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
| |
These were using the unsupported ClientLogin API. The OAuth2 authoriser
has its own async authorisation tests, so porting the existing YouTube
tests would gain us nothing.
|
| |
|
| |
|
|
|
|
|
| |
This required a way of deleting videos once we’re done with them, plus a
tweak to the upload parts parameter.
|
| |
|
| |
|
|
|
|
| |
Set but unused variables.
|
|
|
|
|
|
| |
This should make YouTube comments work again. They have been ported to
JSON from XML, and the GDataCommentable implementations updated to use
the correct comment URIs.
|
|
|
|
| |
This will be useful for YouTube comments, coming up shortly.
|
|
|
|
| |
From way back in 2009. Time flies!
|
|
|
|
|
|
|
| |
This simplifies the code and fixes a problem where if both
region_restriction_allowed and region_restriction_blocked were not
spcified, the GDataYouTubeVideo would behave as if restricted for all
regions, which is most likely not the intention.
|
|
|
|
|
|
|
|
| |
A lot of the media:group parsing stuff has gone, and was not tested
properly to begin with, so that test can be dropped. Similarly, the
error handling test can be dropped because the JSON parser code is
deliberately a lot more tolerant now that arbitrary ratings boards are
supported.
|
|
|
|
|
|
|
| |
Unfortunately the YouTube category list is no longer localised to the
region passed in to the query — the category names are now always in
English. So the only way we can detect differences caused by changing
region is to look at how many categories are returned.
|
|
|
|
|
|
|
|
| |
The GDataAPPCategories parser used to take in the GType of the
GDataCategory subclass to construct when parsing its category list; in
the port to JSON, it was accidentally changed to always construct
GDataCategory instances. This broke the YouTube code, which was hoping
to see GDataYouTubeCategory instances be constructed.
|
|
|
|
| |
It’s a private header and shouldn’t be in the documentation.
|
| |
|
|
|
|
|
| |
If they have a recordingDetails section, but no recordingDate, the
parser was crashing.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Now testing that GDataYouTubeService no longer claims to support batch
operations, rather than testing that they work.
https://developers.google.com/youtube/v3/guides/implementation/deprecated#Batch_Processing
https://bugzilla.gnome.org/show_bug.cgi?id=750914
|
|
|
|
|
|
|
| |
It is no longer supported in version 3 of the API, so implement the new
GDataBatchable.is_supported API and return FALSE for everything, meaning
that all batchable operations on GDataYouTubeService will now fail with
GDATA_SERVICE_ERROR_WITH_BATCH_OPERATION.
|
|
|
|
|
|
| |
This new API is intended to be used by GDataYouTubeService to allow it
to indicate which batch operations it supports (since this has changed
since v3 of the API — now batch operations are no longer supported).
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=750914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only way to implement some of the standard feeds in the YouTube
service is now to query filtering against the current date, which means
that a custom message comparison function has to be installed into the
uhttpmock code to ignore that query parameter when replacing HTTP
traces.
Use some new convenience API in libuhttpmock to achieve this.
Dependency changes:
• libuhttpmock ≥ 0.5.0
https://bugzilla.gnome.org/show_bug.cgi?id=750914
|
|
|
|
|
|
|
| |
There is no point in sending microsecond datestamps to the server. This
also makes the API more testable, since the unit tests no longer need to
guess the date stamp with microsecond accuracy. (They are still open to
second-accuracy race conditions, though.)
|
| |
|
|
|
|
|
| |
This fixes a crash on finalisation of GDataYouTubeVideo if it has
keywords set.
|
|
|
|
|
|
| |
The api-index-full.xml and api-index-deprecated.xml files already define
those two IDs, so we can’t define them again in gdata-docs.xml. Use role
instead, whatever that is.
|
| |
|
|
|
|
|
|
|
|
|
| |
The new gvfs backend will enable nautilus and the gtk+ file chooser to
interact with Google Drive. This means that GOA accounts in Google
will get a "files" switch, which we should check when deciding whether
to enable the documents service.
https://bugzilla.gnome.org/show_bug.cgi?id=751782
|
|
|
|
|
|
|
|
|
| |
There is a bug in the Drive web UI where the preview doesn't get
updated with the new content, but if you download or go through the
revisions then things are as they should be. I could reliably reproduce
it with plain/text content.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
| |
This is a unit test for the fix in commit
5ca05e195f7cecd63d6616aeef8410df8eee978c.
|
|
|
|
|
|
| |
We will need this for creating folders and copying files.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
| |
A Drive v2 folder is a file with the MIME type
application/vnd.google-apps.folder (and with no extension). Therefore,
setting the MIME type is crucial for creating new folders.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
|
| |
The constructed vfunc is the idiomatic place to access construct
properties, which is what we are doing in this case. The constructor
is more intrusive and is usually used for implementing things like
singletons.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add new API to allow the refresh token from an OAuth 2 authorizer to be
stored by an application and restored into a new GDataOAuth2Authorizer
instance (a cold start). This adds the following new API:
• GDataOAuth2Authorizer:refresh-token
• gdata_oauth2_authorizer_dup_refresh_token()
• gdata_oauth2_authorizer_set_refresh_token()
It does not add any new tests.
https://bugzilla.gnome.org/show_bug.cgi?id=750746
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
| |
This is enough to upload a file to the root folder, but you can't
select a specific location.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
| |
We will need this in gdata_documents_service_finish_upload.
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new sub-class was introduced to set JSON as the content-type for
Drive v2. It was a good opportunity to move the Drive-specific JSON
parsing code from the base class.
New API added:
• GDataDocumentsAccessRule
This new class must be used in place of GDataAccessRule for any
interactions with the Drive API. This is essentially a soft API break,
but it’s unavoidable.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
| |
This will be used by GDataDocumentsAccessRule when parsing the JSON.
https://bugzilla.gnome.org/show_bug.cgi?id=684920
|
|
|
|
|
|
|
|
| |
We need to pass the a GDataAuthorizationDomain to
gdata_service_insert_entry, and we should not unref the GDataLink
returned by gdata_entry_look_up_link.
https://bugzilla.gnome.org/show_bug.cgi?id=750395
|
|
|
|
|
|
| |
This fixes implicit enumeration type conversion.
https://bugzilla.gnome.org/show_bug.cgi?id=750480
|
|
|
|
|
|
|
| |
We can end up with an infinite loop if end_num is G_MAXUINT. Let's use
‘<’ instead of ‘<=’ to avoid this.
https://bugzilla.gnome.org/show_bug.cgi?id=750335
|