Files: Use new Cloud Providers stuff [$360]

[codygarver]

link: https://csorianognome.wordpress.com/2015/07/07/cloud-providers/

It's a DBus API. FTA:

– GetIcon: which retrieves the cloud provider brand icon.

– GetPath: which retrieves the folder where the cloud provider stores its files.

– GetName: which retrieves the name of the cloud provider

– GetStatus: which retrieves the status (idle, syncing, error) of the cloud provider

And finally, it can expose a full GMenuModel through DBus for its use for any action.

The expected implementation in Files should probably be the same as described in the article: Showing cloud drives as mounts in the sidebar. In our case however, they should be sorted under the "Network" category

---

There is a $360 open bounty on this issue. Add to the bounty at Bountysource.

[benwaffle]

https://gitlab.gnome.org/External/libcloudproviders

[diego-d5000]

what exactly is expected ? The implementation of the workflow in this article ("Use cases and workflow" section) using this GTK DBus API ?

[gideondsouza]

@codygarver yea it's not too clear to me either.
This DBus api is cool but what do you expect to be done specifically.

[oreach]

So, no traction? I'll take on the task then. I expect to have the Files plugin done by Monday, then I'll spend a week making a cloud provider or two.

[cassidyjames]

@oreach any update?

[cassidyjames]

@Philip-Scott this is the issue we were talking about at LAS.

[peteruithoven]

This might be an interesting example, result of GSoC, what the integration of the Nextcloud client looks like in Nautilus:
https://www.youtube.com/watch?v=Px3TpCWLmbI
Mre info: https://blog.juliushaertl.de/index.php/2017/08/28/gsoc-final-report/

[naaando]

I'm working on this, not sure how much time I'll take because I want to add unit tests(I never done unit testing in vala before) and make sure it's working roundly.

[skewty]

Is it possible for Files to show "badges" to reflect a synced / unsynched state over top of the icon / folder itself?

[naaando]

Hi people, libcloudproviders seems to be broken, the test client and library aren't working, I'm not good in C language to fix these issues.
I've made the bindings to Vala already and I'm waiting for a response to my merge requests.
My best bet is to implement a client in Vala that connects directly to the server, that solution would be ok?

[tristanrobert]

I wonder if a different solution would be better, a solution based on gnome-online-accounts integrated in switchboard-plug-onlineaccounts and gvfs integrated in pantheon-files like nautilus is. This solution with gvfs seems to me more mature. It does not depend on gnome desktop packages, although it is two GNOME projects. What do you think about it @danrabbit ?

[tintou]

Files is already using GVFS as it uses the Gio library (as well as the whole OS). We made the choice to not use GNOME-Online-Accounts because of their lack of modularity.

[naaando]

It was tricky to deal with C but I managed to fix the problems related to Vala binding and memory management on bindings in general, I'm waiting for the approval of my merge requests but now I can begin to work on implementing the client integration.

Btw, the problems I found early were mistakes on installation steps caused by my misunderstanding of how the library was done and lack of documentation, libcloudproviders developers and I are discussing how to improve it too.

[naaando]

@skewty If Files already has the badge feature would be possible for the folder but not files inside because the API of the library doesn't cover syncing status for each file. Maybe a hacky way to determine it is listening to file descriptors, so it could be used to notify users about files being written even off of cloud folders.

[naaando]

I'd split major changes into PRs.
Related PRs: #648 #649 #650 and have more commits to cherry-pick to another branch before pushing.

Current status

• The Open* actions still don't work
• The first time the plugin context menu opens it is inverted
• I still don't know if the menu is supposed to be inactive or is a problem
• Should 'syncing' be represented by a spinner?

[peteruithoven]

Looks like those PR's were merged. I see also #659 #660 were merged, which seem to enable the kind of plugin API you need in Files. Quite amazing the amount of work you put in just to get ready for the actual plugin.
I'm assuming then that https://github.com/elementary/files/pull/656 is the actual plugin? It has a label In progress, does that mean you're still working on it? (I noticed the CI checks are failing)

[naaando]

@peteruithoven I'm almost done, couldn't make the tests yet, and am not sure how it should be done too. The CI is failing because the plugin requires the library libcloudproviders.

This dependency should be included on deb-packaging's control file and installed by CI script, but the available package won't work for compiling 'cause it doesn't ship the bindings patches. So the lib must be compiled from the master branch or wait for a new release.

[cassidyjames]

@naaando according to @tintou, we should be able to bundle the .vapi file as we do for other libraries without .vapi files. He can help with that if you need, or someone else may be able to. I'll ask around for someone from @elementary/desktop-developers. :smile:

[peteruithoven]

Looks like the libcloudproviders-dev dependency has been successfully added.
Was there any progress on including those .vapi files?

[naaando]

Hi @peteruithoven, unfortunately adding the .vapi was not enough due to other changes that are required to binding work, so I think I am blocked until a new release of the library.
The libraries generally have a main header including all the source files, but it didn't so I had to create one and it didn't get upstream yet.

[naaando]

I opened an issue a few weeks ago but didn't get a response yet.

[danrabbit]

Sent a DM to @csoriano1618 on Twitter to see if we can get his attention. Let you know when I hear anything back :)

[danrabbit]

@naaando Just heard back. Should be done soon :)

[codygarver]

@naaando I built the libcloudproviders package, it's in the OS Patches PPA available on elementary OS Juno now.

[peteruithoven]

@naaando could you maybe clarify some things.
The pantheon-files-cloud plugin you've made is a cloud provider client?

But this also requires a cloud provider server?
Currently the libcloudproviders gitlab page lists the Nextcloud client as a server:
https://gitlab.gnome.org/World/libcloudproviders#server
Which means you still need to install the Nextcloud desktop client and run it in the background?
(ppa (linux packaging status) / appimage / flatpak / snap)

Do we know if people are working on other servers, for example to support Google Drive or Dropbox?
(I understand we need to start somewhere. Hopefully more cloud provider clients like your Files plugin will stimulate more progress)

[csoriano1618]

Hey @peteruithoven, I'm the creator of libcloudproviders.

I plan to work on the Dropbox plugin sooner rather than later, given that their Nautilus plugin (only supported file manager they have) is open source, located here.

If someone wants to help with this one out I will be more than glad to give reviews and advice any time!

[peteruithoven]

@csoriano1618 whow pretty cool that you're keeping your eyes on things here.

The term "plugin" is a bit confusing in this case.
Do you mean a plugin for Files? Shouldn't implementing the libcloudprovider plugin make that unnecessary?

[csoriano1618]

Do you mean a plugin for Files?

Yeah

Shouldn't implementing the libcloudprovider plugin make that unnecessary?

Exactly. The Dropbox repo contains how to connect to Dropbox protocol and all as part of the Nautilus plugin, so it "just" needs to wire that to libcloudproviders instead.

[karim-inabi]

they have only supported file managers

On Mon, Feb 11, 2019 at 10:21 AM, Peter Uithoven
[e-mail] wrote:

@naaando could you maybe clarify some things.
The pantheon-files-cloud plugin you've made is a cloud provider
client?

But this also requires a cloud provider server?
Currently the libcloudproviders gitlab page lists the Nextcloud
client as a server:
https://gitlab.gnome.org/World/libcloudproviders#server
Which means you still need to install the Nextcloud desktop client
and run it in the background?
(ppa (linux packaging status) / appimage / flatpak / snap)

Do we know if people are working on other servers, for example to
support Google Drive or Dropbox?
(I understand we need to start somewhere. Hopefully more cloud
provider clients like your Files plugin will stimulate more progress)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[naaando]

libcloudproviders provide a protocol like MPRIS for media players, that said;

The pantheon-files-cloud plugin you've made is a cloud provider client?

From libcloudproviders README

libcloudproviders is a DBus API that allows cloud storage sync clients to expose
their services. Clients such as file managers and desktop environments can then
provide integrated access to cloud providers services.

Shortly yes, but libcloudproviders already ships a client so what I did was wiring this client to the UI components

But this also requires a cloud provider server?

No, in libcloudproviders terminology a server refers to a program that expose an API whose clients connects to query updates, the client(the file manager and the desktop environment in this case) can list servers and query information on the server(cloud provider client which is exposing the API) like the path the is syncing your files.

Currently the libcloudproviders gitlab page lists the Nextcloud client as a server:
https://gitlab.gnome.org/World/libcloudproviders#server
Which means you still need to install the Nextcloud desktop client and run it in the background?

Yes.

(ppa (linux packaging status) / appimage / flatpak / snap)

Do we know if people are working on other servers, for example to support Google Drive or Dropbox?

I don't know for sure.

(I understand we need to start somewhere. Hopefully more cloud provider clients like your Files plugin will stimulate more progress)

@csoriano1618 whow pretty cool that you're keeping your eyes on things here.

The term "plugin" is a bit confusing in this case.

I made it as a plugin to not hard depend on that, integrating it as a plugin looks cleaner.

Do you mean a plugin for Files? Shouldn't implementing the libcloudprovider plugin make that unnecessary?

I think he means a server to expose Dropbox client to DBus so it can be listed on Files, and yes this plugin makes unnecessary to build specific plugins for each cloud service provider if they are using libcloudproviders DBus API.

[csoriano1618]

If there are things I can clarify on the README or documentation, feel free to point them to me, I will be glad to clarify them.

[naaando]

Is https://github.com/elementary/files/pull/656 enough to finish this?