Never tested it, actually. It requires Storage to implement upload()
method and me to find some way to get saves' ReadStream.
The saveTimestamps() and loadTimestamps() part should be tested, other
parts should work fine.
OneDriveTokenRefresher is a CurlJsonRequest replacement for
OneDriveStorage methods. It behaves very similarly, but checks received
JSON before passing it to user. If it contains "error" key, it attempts
to refresh the token through OneDriveStorage, and then restarts the
original request, so user won't notice that there ever was an error.
Knows how to OAuth already.
This commit also adds CloudManager::addStorage(), so OneDriveStorage can
add newly created Storage and CloudManager can save it in the
configuration file.
It reads the passed NetworkReadStream and prints its contents onto
console (for now). It would be writing contents into file.
To simplify work with raw NetworkReadStream there is a new CurlRequest.
It basically does nothing, but as ConnMan handles transfers only if
there is an active Request, you need some Request to get
NetworkReadStream working. Thus, there is a CurlRequest, which is active
until NetworkReadStream is completely read. CurlRequest also has useful
addHeader() and addPostField() methods in order to customize the request
easily. Use execute() method to get its NetworkReadStream.
DropboxStorage implements streamFile() and download() API methods. As
DownloadRequest is incomplete, it is not actually downloading a file,
though.
With ConnectionManager singleton one can start their Requests without
creating Storage instance. Moreover, Storage instance should contain
cloud API, not Requests-related handling and timer starting methods.
Thus, these methods were moved into ConnectionManager itself.
Now we can do REST API request by creating CurlJsonRequest and waiting
for it to call our callback. Passed pointer is Common::JSONValue.
This commit also does some minor variable renaming fixes.
Now it is based on MemoryReadWriteStream, which is introduced by this
commit. This stream is using ring buffer and is dynamically increasing
its size when necessary.
NetworkReadStream actually saves whole response in the memory now.
There is a pause mechanism in libcurl, but if libcurl is requesting
something compressed, it would have to uncompress data as it goes even
if we paused the request. Even though our own stream won't be notified
about this data when when "pause" the request, libcurl's own buffer
wound be expanding.
CurlRequest uses own multi_handle, in which it creates an easy_handle to
make a request.
Every time `handle()` is called it checks whether request is complete
and, if it is, stops.
This commit introduces Common::CloudManager, which can be accessed from
OSystem.
The backend for this manager is Cloud::Manager (defined in
backends/cloud/manager.h). It should load all users storages from
configs and provide access to current Storage instance. For now it just
creates a new one.
Cloud::Storage (backends/cloud/storage.h) provides an API to interact
with cloud storage, for example, create new directory or sync files.
Right now it's not ready and has only two dummy methods: listDirectory()
and syncSaves().
There is Cloud::Dropbox::DropboxStorage backend
(backends/cloud/dropbox/dropboxstorage.h) for Cloud::Storage. Right now
it implements both listDirectory() and syncSaves() with starting timer
task and handling it by printing out some JSON examples.
This allows us to use various framebuffer settings easily. Now the GPU
accelerated CLUT8 surface implementation does not need to query former
framebuffer state anymore.
Formerly we relied on static linkage. However, in the presense of modern
OpenGL (ES) implementations it is not easily identifable which library to link
against. For example, on Linux amd64 with nVidia drivers and SDL2 setup to
create a GLES 1.1 context one would need to link against libGL.so. However,
traditionally GLES 1.1 required to link against libGLESv1_CM.so. To prevent a
huge mess we simply resolve the OpenGL functions on run-time now and stop
linking against a static library (in most cases).
GLES support needs to be enabled manually on configure time for now.
Tizen changes have NOT been tested.
Since Mac OS X Carbon/Cocoa API isn't stable (in that it's changed multiple times over the years). Maintaining two versions of the same code (one in some foreign language with overly long names) isn't very appealing to me.
This is needed because it is not possible to keep absolute paths to the iOS document directory, because a part of its name change between each installation / update.
This implements count badge, progress bar, and icon overlay.
It uses the NSDockTile API which is available since OS X 10.5.
The code compiles and run on older system but without doing
anything.
