GNOME Bugzilla – Bug 557540
/etc/favicon.png support
Last modified: 2009-01-12 21:42:34 UTC
Some time ago Colin introduced the concept of /etc/favicon.png http://cgwalters.livejournal.com/19030.html Now that we have GVfsIcon and GIcon serializatoin it's almost trivial to implement for the sftp backend; just to a few changes to make the GVfsBackend class use the gicon serialization bits. The way it works is that we stat /etc/favicon.png on start-up. If that file exists the GIcon for the mount will be a GVfsIcon with the id favicon:/etc/favicon.png. Otherwise we fallback to folder-remote as usual. Finally we implement open_icon_for_read() and pass that through after checking the icon_id is of the correct form. I wonder if it's a problem that it's going to take some time to load the icon. IIRC GTK+ uses blocking i/o (but I might be wrong) when being passed a GLoadableIcon. In practice it might not be a big problem, /etc/favicon.png is probably guaranteed to be small (you kinda implicitly trust the server since it's sftp, not dav, and all) and, hey, GTK+ should probably know that it's bad to use blocking i/o (granted, that's a lot easier said than done). Here's the mandatory screenshot http://zelenka.fubar.dk/~davidz/etc-favicon-support.png
Created attachment 121173 [details] [review] proposed patch Hope I got the patch right; there's 2-3 other patches in my local tree so shout if it doesn't apply or something is missing...
An idea if performance is a concern: we could do the /etc/favicon.png stat + load in the background.... And then just change the icon when loaded (need some gvfs protocol changes I think). Maybe even store the loaded icon in a cache on the local disk (but what is "local" anyway?)... A related thought: maybe we want a fallback GIcon on the GLoadableIcon interface that can be used a) while the real icon is being loaded; or b) if the icon _can't_ be loaded. (While b) sounds far fetched, it's not impossible that some security mechanism on the host (like SELinux) prevents loading the icon data but still allowing you to stat the file making you believe it's readable.)
I'd argue that it should check for ~/.face as the first icon.
(In reply to comment #3) > I'd argue that it should check for ~/.face as the first icon. Not sure. And I'm not sure how to resolve ~, it may not be /home/<username>... can the SFTP protocol do this?
I'm pretty sure it'll work, just like when I do: scp file bnocera@foobar:~/public_html You could argue that ~/.face isn't great if you have more than one machine, to be honest. Maybe setting up the icon along the hostname would be nice?
g_vfs_backend_set_icon_name should use g_themed_icon_new_with_default_fallbacks as the old client code did. Otherwise it looks ok. Commited.
We probably also want support for /etc/favicon.svg - I just talked to Colin on IRC and he said this was fine <davidz> walters: we probably need something like /etc/favicon.svg in your "favicon spec" <davidz> walters: 16x16 isn't really good enough now that http://bugzilla.gnome.org/show_bug.cgi?id=557540 is fixed.... <walters> fine by me (note, there's no real "spec" for /etc/favicon.png)