Age | Commit message (Collapse) | Author |
|
It now sends kDownloadEndedCmd on success without waiting to be
destructed.
|
|
Now it doesn't stop on 100 % on last file and it ignores the
directories, so it doesn't "jump" suddenly as there are no directories
to skip.
|
|
|
|
|
|
|
|
It now shows a MessageDialog (its message label is hidden in some
cases).
|
|
It uses Networking::Browser::openUrl().
|
|
Only Windows' shellExecute() now.
|
|
Now NetworkReadStream, which is used in DownloadRequest, which is used
in FolderDownloadRequest, returns progress information provided by
libcurl.
|
|
Uses dynamically allocated buffer now.
|
|
It now uses a dynamically allocated 1 MB buffer.
|
|
|
|
It now derives from IdStorage, so lots of GoogleDrive*Request classes
are removed and replaced with generic IdStorage*Request ones.
|
|
Box uses POST multipart/form requests for uploading. Such requests could
be sent with libcurl if we either have a file available or a buffer with
this file's contents.
SavesSyncRequest was using Storage::upload(ReadStream *), which couldn't
be implemented in BoxStorage. Thus I've added a method to test whether
such upload is supported and, if it's not, SavesSyncRequest uses the
other.
|
|
|
|
Now those support POST multipart/form upload.
|
|
|
|
Used for downloading files in Box.
|
|
|
|
Box gets createDirectoryWithParentId(), so now creating directories
works there.
|
|
This is a special base class for Storages which are using ids instead of
paths in their APIs, like Box or Google Drive.
This commit makes Box derived from IdStorage.
|
|
And used in it BoxResolveIdRequest.
TODO: make some generic ResolveIdRequest and ListDirectoryRequest for
id-based storages. It's really similar, I just had to change a few
details in GoogleDrive ListDirectory and ResolveId requests.
|
|
Similarly to Google Drive, Box uses only ids of files. That means id
resolving would be slow.
|
|
BoxTokenRefresher does refresh if HTTP 401 is returned by the server.
To test refresher, BoxStorage::info() was added.
|
|
"/" is used to receive "?code", but when there is no such parameter
passed, it's safe to redirect user to the "/files".
|
|
|
|
As it's controlled by ScrollContainer also, we have to explicitly
setVisible(true) for "always" visible widgets.
|
|
Now it calls Launcher directly, so it updates games list on success.
|
|
Works on Linux too. And, well, I'm bad in adding backends, so it's just
#ifdefed there.
|
|
The attribute is Chrome-only.
|
|
|
|
I should've done these in PR, I guess.
|
|
|
|
Now it respects outer code's decision to hide or move some widgets
around. Outer code must be CommandReceiver which is set as
ScrollContainer's target.
|
|
It has a visibility issue, but we're already working on it.
|
|
If that's the game, that is.
Method is copy-pasted from Launcher, but fixed not to ask the directory
and thus doesn't contain the loop.
|
|
Still doesn't support directories uploading.
|
|
It was starting over every 100vh (each screen).
|
|
|
|
|
|
Simplified some stuff here and there by using HandlerUtils static
methods.
|
|
|
|
|
|
|
|
Adds Client::noMoreContent() and Reader::noMoreContent(), which return
true when whole client's request was read.
|
|
|
|
Now Client reads the first headers block, then LocalWebserver decides
which Handler to use. In case of "/upload", UploadFileHandler is used.
But now it only knows the "path" parameter. If that's valid, actual
UploadFileClientHandler is created, which reads the contents of the
request and, when finds there an "upload_file" field, starts saving it
in the directory specified by "path".
With that we don't need temp files approach from Reader class.
|
|
|
|
|
|
|