GNOME Bugzilla – Bug 754731
Use standard::display-name for Google Drive items
Last modified: 2015-09-12 07:56:44 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.
Created attachment 310917 [details] [review] EogMetadataSidebar: Use standard::display-name when showing the parent
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.
(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.
Created attachment 310960 [details] [review] EogMetadataSidebar: Use standard::display-name when showing the parent
(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.
(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.