After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754731 - Use standard::display-name for Google Drive items
Use standard::display-name for Google Drive items
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: general
3.17.x
Other All
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks: 739008
 
 
Reported: 2015-09-08 16:16 UTC by Debarshi Ray
Modified: 2015-09-12 07:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
EogMetadataSidebar: Use standard::display-name when showing the parent (2.68 KB, patch)
2015-09-08 16:18 UTC, Debarshi Ray
none Details | Review
EogMetadataSidebar: Use standard::display-name when showing the parent (2.81 KB, patch)
2015-09-09 09:10 UTC, Debarshi Ray
none Details | Review

Description Debarshi Ray 2015-09-08 16:16:04 UTC
We now have a GVfs backend for Google Drive (see bug 739008). Google Drive is a database-backed storage, which means that the fundamental identifier is a cookie/blob, not a path. We create POSIX-like paths out of these IDs to fit into the GIO/GVfs world view. eg., google-drive://debarshi.ray@gmail.com/0B9J_DkaiBDRFSHJzeTdCX1hxd3c

This doesn't work well if we use the URI's basename for showing the parent folder's name, because we will be seeing a human unreadable string (eg., 0B9J_DkaiBDRFSHJzeTdCX1hxd3c) instead of the folder's title. We need to use standard::display-name instead.

In any case, we should always be using standard::display-name when showing anything in the UI because it is guaranteed to be UTF-8.
Comment 1 Debarshi Ray 2015-09-08 16:18:30 UTC
Created attachment 310917 [details] [review]
EogMetadataSidebar: Use standard::display-name when showing the parent
Comment 2 Felix Riemann 2015-09-08 17:47:23 UTC
Review of attachment 310917 [details] [review]:

Interesting. So, on Google Drive it won't show the processed URI but rather the folder name as it is defined in the cloud.
How fast is getting the display name in remote scenarios? On local files it's likely a matter of validating the filename, but asking Google for the folder name probably requires another query.
Shouldn't the label be cleared/disabled then while the async operation is ongoing or is it just a (fast) local operation as well?

::: src/eog-metadata-sidebar.c
@@ +107,3 @@
+	} else {
+		display_name = g_strdup (
+			g_file_info_get_display_name (file_info));

I think the file_info needs to be unref'ed here.
Comment 3 Debarshi Ray 2015-09-08 22:46:39 UTC
(In reply to Felix Riemann from comment #2)
> Review of attachment 310917 [details] [review] [review]:
> 
> Interesting. So, on Google Drive it won't show the processed URI but rather
> the folder name as it is defined in the cloud.

Yes. Although, it is always advisable to use standard::display-name when showing the string in the UI because anything else is not guaranteed to be UTF-8.

> How fast is getting the display name in remote scenarios? On local files
> it's likely a matter of validating the filename, but asking Google for the
> folder name probably requires another query.

The GVfs backend caches the Drive's entire metadata. So, if the item is already there, which it should be in most cases because you just opened the file for reading, then it will be very fast.

Otherwise, it can be slow because it will have to hit the network to fetch the information.

> Shouldn't the label be cleared/disabled then while the async operation is
> ongoing or is it just a (fast) local operation as well?

Yes, we could do that.

> ::: src/eog-metadata-sidebar.c
> @@ +107,3 @@
> +	} else {
> +		display_name = g_strdup (
> +			g_file_info_get_display_name (file_info));
> 
> I think the file_info needs to be unref'ed here.

Yes, and I also forgot to unref the sidebar object that was passed as user_data.
Comment 4 Debarshi Ray 2015-09-09 09:10:59 UTC
Created attachment 310960 [details] [review]
EogMetadataSidebar: Use standard::display-name when showing the parent
Comment 5 Felix Riemann 2015-09-11 19:10:08 UTC
(In reply to Debarshi Ray from comment #3)
> (In reply to Felix Riemann from comment #2)
> > Review of attachment 310917 [details] [review] [review] [review]:
> > 
> > Interesting. So, on Google Drive it won't show the processed URI but rather
> > the folder name as it is defined in the cloud.
> 
> Yes. Although, it is always advisable to use standard::display-name when
> showing the string in the UI because anything else is not guaranteed to be
> UTF-8.

Okay, that UTF-8 guarantee seems nice to be had. So, I took a quick look on eog's code and noticed that the image properties dialog used the same logic as the metadata sidebar to produce an "Open Folder"-button. Adapting your patch was pretty straight forward that way.

commit 68a5a0d842d993da6957dee74535ee15c8742394
Author: Felix Riemann <>
Date:   Fri Sep 11 21:00:19 2015 +0200

    EogPropertiesDialog: Use standard::display-name when showing the parent
    
    This simply adapts the changes from commit fff55c6a to the
    properties dialog, which shares some code with the EogMetadataSidebar.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=754731

I'll see if I can remove the code duplication in the next cycle.

> > How fast is getting the display name in remote scenarios? On local files
> > it's likely a matter of validating the filename, but asking Google for the
> > folder name probably requires another query.
> 
> The GVfs backend caches the Drive's entire metadata. So, if the item is
> already there, which it should be in most cases because you just opened the
> file for reading, then it will be very fast.
> 
> Otherwise, it can be slow because it will have to hit the network to fetch
> the information.
>
> > Shouldn't the label be cleared/disabled then while the async operation is
> > ongoing or is it just a (fast) local operation as well?
> 
> Yes, we could do that.

Thanks, for including this.

> > ::: src/eog-metadata-sidebar.c
> > @@ +107,3 @@
> > +	} else {
> > +		display_name = g_strdup (
> > +			g_file_info_get_display_name (file_info));
> > 
> > I think the file_info needs to be unref'ed here.
> 
> Yes, and I also forgot to unref the sidebar object that was passed as
> user_data.

Ah, I didn't notice that one. :)

So let's do it! Thanks for the patch.

commit fff55c6afdd1c159c1ec554316fa6170f561cbe1
Author: Debarshi Ray <>
Date:   Tue Sep 8 18:18:00 2015 +0200

    EogMetadataSidebar: Use standard::display-name when showing the parent
    
    https://bugzilla.gnome.org/show_bug.cgi?id=754731
---
This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
Comment 6 Debarshi Ray 2015-09-12 07:56:44 UTC
(In reply to Felix Riemann from comment #5)

> Okay, that UTF-8 guarantee seems nice to be had. So, I took a quick look on
> eog's code and noticed that the image properties dialog used the same logic
> as the metadata sidebar to produce an "Open Folder"-button. Adapting your
> patch was pretty straight forward that way.

Thanks for doing that. I was going to write a patch for EogPropertiesDialog yesterday, but never got around to it.