Nautilus | Debarshi's den

Archive for the ‘Nautilus’ Category

I spent last weekend at the Core Apps Hackfest in Berlin. The agenda was to work on GNOME’s core applications: Documents, Files, Music, Photos, Videos, Usage, etc.; to raise their overall standard and to make them push beyond the limits of the framework. There were 19 of us and among us we covered a wide range of modules and areas of expertise.

I spent most of my time on the plumbing necessary for Documents and Photos to use GtkFlowBox and GtkListBox. The innards of Photos had already been overhauled to reduce its dependency on GtkTreeModel. Going into the hackfest we were sorely lacking a widget that had all the bells and whistles we need — the idiomatic GNOME 3 selection mode, and seamlessly switching between a list and grid view. So, this is where I decided to focus my energy. As a result, we now have a work-in-progress GdMainBox widget in libgd to replace the old GtkIconView/GtkTreeView-based GdMainView.

gnome-photos-flowbox

In fact, GtkListBox and GtkFlowBox was a recurring theme at the hackfest. Carlos Soriano and Georges were working on using them in Files, and whenever anybody uses them in a non-trivial manner there is the inevitable discussion about performance. Good thing that Benjamin was around. He spent the better part of a tram ride and more than an hour at the whiteboard, sketching out a strategy to make GtkListBox more efficient than it is today.

Like last year, Øyvind joined us. We talked about GEGL, and I finally saw the new GIMP in action. I rarely use GIMP, and I am not sure I have ever built it from source, but I have been reading its sources on a semi-regular basis for almost a year now. It was good to finally address this aberration. Øyvind had with him a cheap hand-held DLNA media renderer that was getting stuck when trying to render more than one image with dleyna-render and Photos. Zeeshan helped me poke at it, but unfortunately we didn’t get anywhere.

Other than that, Petr Stetka impressed everyone with his progress on the new Usage application. Georges refreshed his patches to implement the new Online Accounts Settings panel, Carlos Garnacho helped me with GtkGesture, and I reviewed various patches and branches that had been on my list for a while.

Many thanks to Red Hat for sponsoring me; to Carlos Soriano and Joaquim for organizing the event; to Kinvolk for being such gracious hosts; and to Collabora for the nice dinner.

Written by Debarshi Ray

3 December, 2016 at 20:02

Posted in Blogroll, Documents, GNOME, GTK+, Hackfest, Nautilus, Photos

Content Apps Hackfest 2015: report

with one comment

I spent most of the previous week attending the Content Apps Hackfest in Madrid. The agenda was to work on GNOME’s content applications: Documents, Files, Music, Photos and Videos; to identify missing features and sore points; and raise the standard of the overall content experience in GNOME. Of these, I focused mainly on Documents and Photos.

The first day was spent discussing high-level goals:

Previews – should the content applications take over the role played traditionally by Evince and Eye of GNOME?
Status and plans about sharing. We are still waiting for a platform-wide sharing framework, but since it is a crucial feature for some of the applications, it has become a case of perfection being the enemy of good.
Porting away from GtkIconView to GtkFlowBox. GtkIconView has some very visible problems – it becomes terribly slow when the images are updated; the grid’s content doesn’t re-flow when the size of the widget changes leading to an awkward gutter appearing on the side; cannot pack any GTK+ widget into a GtkCellRenderer.

I set up a live Google Hangouts stream on my laptop to let those who couldn’t attend in person to join us remotely. With Andreas’ help, I fixed the HiDpi breakage in Photos’ cropping tool, Bastien fired some new LibreOffice builds, while the other Bastian revamped Documents’ wiki page.

The second day started with breakfast in Florian’s flat. It was less chatty with people quietly hacking away, presumably, to rest their tired throats. Bastien picked up Pranav’s patches to integrate LOKDocView widget in Documents. I worked a bit on polishing rough edges in Photos’ editing code, and tried to keep up with the endless stream of patches from Alessandro and Umang.

Discussions picked up a bit on the third and final day. Allan spent a lot of time talking to the developers of each application. UX reviews were done, new designs were made, and future plans were sketched out. I spent some time with him working on a roadmap for Photos. We are still cleaning up our rough notes and transferring them to the wiki, but I think it is good enough for others to take a look. Øyvind paid us a surprise visit, and we grabbed the opportunity for some impromptu chat.

Many thanks to Red Hat for letting me attend and sponsoring me, and to Medialab-Prado for being such wonderful hosts.

Written by Debarshi Ray

8 December, 2015 at 11:24

Posted in Blogroll, Documents, GNOME, Nautilus, Photos

Google Drive and GNOME — what is a volatile path?

with 6 comments

TL;DR: If you are using any GFile API that can create a new file or directory, then please take care of “volatile” paths. Look at standard::is-volatile, g_file_output_stream_query_info and g_file_query_info. Read further if you don’t trust me, or if you develop file management software.

Like other cloud storages, Drive is database-based. Every file or folder is identified by an opaque, server generated, immutable, blob (say “0B9J_DkziBDRFTj1TRWLPam9kbnc”), and has a human-readable title that can be displayed in the user interface (say “Summer Vacation”). This is unlike POSIX filesystems where a file is identified by its path and, barring encoding issues, the basename of that path is its name. ie., the name of the file “/home/alice/Summer\ Vacation” is “Summer Vacation”. Sounds like an innocuous distinction at first, but this is at the heart of the issue.

Let’s look at a few operations to get a feel for this.

Rename

POSIX:
mv /home/alice/foo /home/alice/bar
We need the paths to carry out the operation and once successfully finished, the file’s path changes. Since files are identified by their paths, the operation would fail if there existed another file called “bar” in the same location.

Google Drive:
set_title (id_of_foo, bar)
We only need the identifier (or ID) and the new title for the operation and once successfully finished, the title changes but the ID remains the same. Since IDs are unique and immutable, you can have two files with the same title in the same location. That’s a bit strange, you might think, but not so much.

Creating a New File

POSIX:
touch /home/alice/foo
If you want a file named “foo” in a certain location, barring encoding issues, you ask for a path that has “foo” appended to the path of the location. It will work as long as there isn’t another “foo” in the same location.

Google Drive:
create_file (id_of_parent_folder, foo) → id_of_new_file
Notice that we cannot specify the ID of the new file. We provide a title and the server generates the ID for it. Again, there is no restriction on having two files with the same title in the same location. This is where it starts getting weird.

GIO and GVfs

The file handling APIs in GIO are based on the POSIX model, with some room to accommodate minor diversions. They are ill-equipped to deal with a case like this.

As a quick aside, both MTP and PTP are somewhat similar in this regard. Both use IDs to refer to objects (think of them as files) stored on the phone or camera, and we have backends implementing them in GVfs. These backends construct POSIX-like paths using the human-readable titles of the files, and have an internal cache mapping IDs to paths and vice-versa. Easy enough, but there are two important differences:

MTP allows no parallelism. You can only perform one operation at a time — a new one won’t start until the earlier has finished. So, the GVfs backend can assume complete control over the storage. Google Drive, on the other hand, is massively parallel. You might be modifying it via GVfs, via a web browser, from a different computer, or someone might be sharing something to you from yet another computer. It is better to rely on the server generated IDs to identify files as much as possible, and let the server worry about keeping the data consistent.
MTP and PTP are usually backed by a traditional filesystem on the device. eg., FAT12, FAT16, FAT32, exFAT or ext3. Therefore the issue of duplicate titles doesn’t arise.

So, how do we deal with this?

Assuming that we are only doing read-only operations, the URIs used by GVfs’ Google Drive backend look like:
google-drive://foo@gmail.com/0B9J_DkziBDRFTj1TPam9kbnc/0B9J_GlyfBDRBHj1TRWL9khrc
The backend has its own scheme, the account is mentioned, and the path is made up of identifiers. Quite easy. The server doesn’t care about having a POSIX-like path, but we create one to fit into GIO’s POSIX-like world view.

These IDs are decidedly ugly and unreadable, so we use the standard::display-name attribute to tag them with the titles. If you run g_file_query_info on one of these URIs, you will get the ID as the standard::name and the title as the standard::display-name. Thus, the user won’t encounter any ugliness unless she deliberately went looking for it.

It gets complicated when we go beyond read-only access.

Let’s look at creating new files again. Since the GIO and GVfs APIs are designed around the POSIX model, a GVfs backend receives the request as:
create ("/id1/id2/some-title")

Even though the application thinks that it has created a new file named “some-title” inside “/id1/id2” that can be accessed by the path “/id1/id2/some-title”, the new file’s identifier is not “some-title”. It is whatever the server generated for us, say “id3”. If the application has to carry on the illusion of accessing the file as “/id1/id2/some-title”, then the backend has to map this “fake” path back to “/id1/id2/id3”; and this has to happen somewhat recursively because if we are copying a directory, then multiple elements in the file path can be “fake”. eg., “/id1/id2/title-of-subdir/title-of-file”, and so on.

We call these volatile paths. These are identified by the standard::is-volatile attribute and you can use standard::symlink-target to find the actual ID that it maps to. It is recommended that applications map volatile paths to the real IDs as soon as possible because the mapping can break if a parallel operation changes the title of the file.

In the specific case where you have created a new file and writing to it through a GFileOutputStream, then it is better to use g_file_output_stream_query_info instead of g_file_query_info. The output stream knows exactly which file it is writing to, and doesn’t have to do the mapping based on the volatile path, which could fail if the contents of the Drive changed out of band.

For working examples, see Nautilus.

Written by Debarshi Ray

13 September, 2015 at 01:21

Posted in GNOME, Google Drive, GVfs, Nautilus, Online Accounts

Google Drive and GNOME: 6 years later

with 25 comments

GNOME 3.18 is going to be another milestone in our journey to bring various online services closer to the desktop, but this is one that took us 6 years to reach. You can now access your Google Drive through your favourite GNOME applications and the usual GIO APIs

Thibault Saunier started working on this way back in 2009 as a Google Summer of Code project. I picked it up a year ago, and after a few hiccups along the way and some head scratching — more on that later — it is finally here for you to enjoy. You can either wait for distributions like Fedora Workstation 23 to ship GNOME 3.18, or try the 3.17.92 release candidate tarballs that are coming out next week.

Thanks to Alexander Larsson, Philip Withnall and Ondrej Holy for the endless discussions, code reviews and testing for the last one year.

Written by Debarshi Ray

10 September, 2015 at 11:22

Posted in GNOME, Google Drive, GVfs, Nautilus, Online Accounts

GNOME meets ownCloud

with 13 comments

Now that we are in the middle of the various freezes in preparation for GNOME 3.8, it is a good time to talk about some of the things that happened over the last six months. One such thing is the integration of ownCloud in GNOME. Go to the Online Accounts panel in Settings (hit the super key or the Activities button and type “online”) to enable your ownCloud account, and you will be able to access your calendars, contacts and files from GNOME.

Calendars and contacts can be accessed via CalDAV and CardDAV from their respective tabs in Evolution. Files in your ownCloud storage show up as volumes via WebDAV in Nautilus and GtkFileChooser.