When working on the Nextcloud server and apps it is quite useful to run separate version branches besides each other. Until now I had cloned the server repository to separate folders, making it hard to share a commit between two major branches, since it always required a push to a remote first. Today I stumbled upon a git command that makes this fairly easy.
The command git worktree allows you to have separate working directories for multiple branches, that all use the same repository. Assuming that you are in the cloned directory of the server repository, the following command will checkout the stable13 branch at a new directory called stable13:
git worktree add ../stable13 stable13
After committing some changes in the main repo directory, you can easily cherry-pick those changes in the stable13 working directory.
Of course you can also do the same thing for any app, so it is much easier to check the compatibility to older server versions.
So why is this better than just switching branches? In terms of Nextcloud it is quite handy to have a separate directory that will be served by your webserver so you can check without migrating between versions or reinstalling your development setup all the time. On top of that you don’t store the git metadata multiple times (which is around 400MB for each clone of the Nextcloud server).
I hope that some of you might find this useful. It really improved my backporting/testing workflow a lot.
The Google Summer of Code is almost over and I want to give you a quick update on what has been done in the last months.
You can have a look on how the integration of the Nextcloud client looks like in Nautilus in the following video. As GNOME will drop the support for status icons on the near future this will be the way for sync clients to give the user a way to access their functionally in the context of the synced folder.
On the Nextcloud side I have implemented a proof of concept API for account registration right from within the client. That way even new users who don’t have a clue about how Nextcloud is working can easily pick a provider to host their data and setup an account there. They don’t need to care about entering a server url.
I’m currently still at the Nextcloud Conference in Berlin, where some discussion on how the client patches will be used is still going on.
Although I had planned some more features to be implemented on the Nextcloud client, the library for cloud providers and especially getting a good understanding of DBus and gdbus required more time than I initially thought. But we now have a solid basis to offer a desktop independent API that can easily integrated by both, desktop environments and cloud providers clients.
I really enjoyed working together with two great open source projects that are both backed by an awesome community with a lot of really great people. I also want to thank Carlos Soriano, my GNOME mentor as well as Roeland Douma, my Nextcloud mentor for guiding me through the project.
If you are interested in the code that has been produced, you can find it here:
A quick update of the account registration feature for the Nextcloud client I am currently working on during my GSoC project. In case providers offer an endpoint for account registration, users can just click the button and fill out a form as you can see in the video below.
The registration app will include a basic PoC implementation of the registration API. Since most hosting providers will likely have separate instances for each client they will need to implement that API to integrate it with their own deployment/order systems. Any feedback from providers is welcome at this stage of the project, so we can make sure there is nothing important missing.
The next step for the client is to check the status of the finished registration and add an account if the provider has verified the users request.
So some time has passed since the coding period started and I want to give you a quick update on how things are going so far.
I started working on the improved setup experience of the Nextcloud client, by adding a list of providers that offer hosted Nextcloud installations for their customers. As a second step support for a registration API will be integrated so that users can create an account right from within the setup wizard. A proof of concept implementation for that API is almost ready for the Nextcloud registration app.
I also started migrating Carlos proposal of a cloud providers API to a gtk-independent library that provides basic DBus interfaces for cloud providers and software that wants to access the functions provided by those, like Nautilus.
Although it required quite some time to wrap my head around gdbus and especially the generated code of gdbus-codegen, its getting clearer and I took some notes in order to write a HowDoI entry for the GNOME wiki to help others getting started with it in the future.
Over the next 2 weeks I’ll be continuing migrating the cloud providers library to use gdbus-codegen as well as adding support for the cloud providers API to the GtkPlacesSidebar.
So far for now, I’ll keep you updated on the progress, of course. Thanks for reading.
During this summer I’ll take part in the Google Summer of Code, working together with GNOME and Nextcloud to improve the out of the box cloud experience on the Linux desktop.
The integration of Nextcloud services within the GNOME desktop environment is already quite good, as gnome-online-services provides file browsing as well as calendar/contact/task sync with existing GNOME apps. Nevertheless the integration of the Nextcloud desktop client for file synchronization still has lot of room for improvement. Especially the initial setup of file synchronization is a high barrier for non-technical users.
Tasks during GSoC
By now the client demands that the user already has an account on a Nextcloud instance. Providing the setup wizard with a simple list of hosting providers will allow users to find a provider they trust and register an account from within the client.
Furthermore the integration with the GNOME desktop environment will be improved by extending the existing file context menu and file icon overlays. Also basic integration the the cloud providers API proposed by Carlos Soriano will be added, which will be a first step to remove desktop environment specific code. I’ll also work with Carlos in order to extend the existing API draft, to provide more functions that might be useful to certain cloud providers.
GNOME as well as KDE both provide a simple sign-on service that allows users to enter their credentials for web services like Nextcloud (gnome-online-accounts and accounts-sso). The Nextcloud client should make use of the accounts created there as well as add accounts when setting them up in the client.
Depending on the remaining time I’ll also dig into the notifications integration of the Nextcloud client. With the upcoming Nextcloud 12 release, notifications become an even more essential part of the user interaction. Since the current client implementation is quite minimal there is a lot of room for improvement.
Working in the open
All work on the Nextcloud client will be done in public over at the Nextcloud GSoC repo, where you can also find some more details on the different steps that will be implemented during GSoC. Everyone who would like to discuss or has some ideas on how we could further integrate Nextcloud with the Linux desktop and especially with GNOME, feel free to head over to GitHub and join the discussion.
I’d also like to thank Roeland Douma from Nextcloud as well as Carlos Soriano from GNOME who will be mentoring me during the coding period. I’m really looking forward to the upcoming months.