GNOME Bugzilla – Bug 541276
XDG directories should have their own icons
Last modified: 2010-02-16 21:17:49 UTC
new that we have XDG directories we should attach icons to them, like the desktop icon. Other information:
Created attachment 113870 [details] [review] icons patch This could be a start. Don't look at the icons I chose, since there are no default icons for these directories
I don't think this is adaequate. If you really think this is the right thing to do, proper names for those places should be added to the icon-naming spec.
What do you mean with "I don't think this is adequate?" I cannot understand if you think that XDG directories should not have different icon than normal directory, or if you think that this is not the correct place. If the latter, this should be the right place to insert icons, since in the line before the patch, there is the statement to attach "user-desktop" icon is attached to the desktop directory. P.S. - Nautilus shows the icons without any additional change!
I meant that the chosen icon names are not adaequate. Thats why I said there should be proper names like user-desktop. A bookmark-new icon may not look at all like a place to store templates... But I'm also somewhat unconvinced that it is really desirable to have special icons for _all_ of those. home and desktop are somewhat special
I am convinced that at least documents, video, music, pictures and downloads should have different icons. Maybe public and templates should keep the normal one, but since they are special directories maybe the user should be visually informed about this, so he does not have the idea to remove or rename them. What do you think? I will repost the patch with new icon names soon.
Created attachment 113922 [details] [review] xdg-directory-icons I changed all the icons to "xdg-directory-*" (with * the name of the xdg directory). As regards the possibility to not change the icon for some special directories the solution is simple: create a theme in which the special icon is linked to the "folder" icon file. What do you think?
you need to go to xdg-list and propose adding names for these places to the icon naming spec.
I've forwarded the request to the xdg ML
Maybe I didn't request the right thing... they told me that they prefer that nautilus implements it using emblems, but I tried to point out that if it is implemented here, every GIO filemanager will benefit of this feature without adding complexity to all filemanagers to do the same thing. They replied that they have no idea on which is the way to request adding new icons. do you know it?
Sending mail to xdg-list is the right way. Just give it some time...
5 days passed without any response. Showld I try something else? thanks
1 month passed now. Matthias, can you suggest me something else?
Getting icon names in any spec seems sort of tricky atm. I don't think using custom icons for these locations is a bad idea. In fact, i prefer it over emblems, since emblems cannot do some of the things you can do with full custom icons (for instance, the desktop folder icon can't be done as an emblem, and the home one is problematic too). However, i'm a bit worried about how this will work when the xdg directories change. Nautilus handles this, and in fact it automatically updates the prefs when the user moves or renames on of the dirs. We would need a way to invalidate the glib cache of the config for this to work. Also, the patch needs to handle the g_get_user_special_dir calls returning NULL.
You are right, the glib spec on xdg dirs says that you cannot change xdg dirs at runtime. you need to log out. "Depending on the platform, the user might be able to change the path of the special directory without requiring the session to restart; GLib will not reflect any change once the special directories are loaded." This is of course really a limit! Currently nautilus is cool, since it automatically changes the file .config/user-dirs.dirs, but of course icons will change after a logout :( About the NULL return, I really cannot understand why strcmp cannot handle NULL arguments... this is sad :( so we could use g_strcmp0 which handles NULL arguments
Created attachment 120268 [details] [review] xdg-directory-icons.patch
Created attachment 120296 [details] [review] glib-xdg-cache-reloaded.patch Ok I could propose this patch to glib to automatically reload xdg data if the asked directory does no more exist. Unfortunately this adds IO every time someone asks for a xdg_user_special_dir, but this shouldn't be a problem, since when you ask for it you will probably do some IO!
Anyway it's also very simple to add a glib function g_invalidate_user_special_dir_cache() and/or g_set_user_special_dir() why is it not present? Is there a motivation?
Invalidating userdirs is not really possible, due to memory mgmt issues. There is no api for setting special dirs, since these are _user_ special dirs, not something for apps to mess with.
I cannot understand. If they are user special dirs they should not be "read-only". And if not how can a user modify them without an app? Now they are treated as system special dirs (such as /usr which is of course "read-only"). It seems that the special dirs are stored in a gchar* array. It is possible to free the array entries and than call again load_user_special_dirs(). I don't see any memory management problem, but I've just had a quick look at the code. Are you sure?
Yes, I'm sure. > * Return value: the path to the specified special directory, or %NULL > * if the logical id was not found. The returned string is owned by > * GLib and should not be modified or freed. We have no control over how long applications keep the pointers around that are returned by g_get_user_special_dir, so there is no way that we can free them in the library...
Ok, thank you very much for the explanation! Now I understood! Anyway, the xdg-directory-icons.patch to GIO can be considered, even if glib does not let a xdg-directory to be changed runtime. This is not a real problem, because the user will see back its beautiful icons after the logout, if he changes the directory name/path, exactly as it happens with the desktop dir. Do you think that the new icons will be accepted by xdg-spec? And if so, how to make them answer to this request, since xdg-list ignored it?
I know this is not an important problem, but this improvement could be very appreciated by users! Is it possible to commit the patch, so that maybe someone will add the new icons? it has been fixed to handle NULL returns, so there is no problem now. And there's no need to support dynamyc xdg directories now.
Any intention to fix it in this unstable release cycle?
I think it might be a bit late to change this at this late point in the cycle. However, the glib-xdg-cache-reloaded.patch patch is just wrong. We can't just keep doing blocking i/o in a function like this. Apps expect it to be fast and not block, so it could be called from any sort of place at any time. IMHO we should add some invalidation call for this and have nautilus call that when it knows that the settings changed. Then we should take care when we update the internal settings so that we only leak the strings that really needed changing. I don't think such a minor leak in a very uncommon situation matters. Also, we should probably make the gtk file selector call this cache invalidation function when its displayed so that regular apps can get updated directories.
Created attachment 129558 [details] [review] xdg_user_dirs_icons_with_emblems.patch Ok. In the mean time I'm attaching the new patch with emblems, so new icons will not have to be designed
I don't think using emblems for this is a good idea. Its already overloaded with way to many things, and as I said above you can't do what we want for e.g. the desktop and homedir icons with an emblem.
Emblems seems a good compromise for the rest of xdg directories. Anyway if you think that plain icons are better, who will draw them? I've already contacted the xdg-list several times, without any answer.
Alex proposal in comment #24 sounds ok to me (have an invalidate function that just leaks changing strings)
like void g_change_user_special_dir(GUserDirectory directory, const char* new_value) or void g_invalidate_user_special_dir(GUserDirectory directory) ? The former does not require disk access, the latter instead does. But the former might also be not good, because maybe now applications can thing that changing a special directory is something that they can normally Anyway it's quite easy to implement both...
Created attachment 129676 [details] [review] move_user_special_dirs.patch What about this patch?
Created attachment 129677 [details] [review] move_user_special_dirs.patch What about this patch?
Attached twice, sorry :(
I think what we want here is void g_invalidate_user_special_dirs (void) As Alex said, it needs to be careful to only leak the strings that are actually changed. As for asking for icons, http://live.gnome.org/GnomeArt/ArtRequests is a good place to go.
After easter I will work on the patch to submit a better one. In the mean time can you file the art request pointing to this page? Anyway apps that have the old pointer, won't work. Can you think of a way to handle this? Maybe a signal to which apps will register in glib?
Created attachment 132458 [details] [review] reload_cache.patch Hello, this is me again. I've done another try, tell me how can I improve it. What I do is the following: - create a new array - reload the dirs using load_user_special_dirs() - compare the old dirs with the new ones - use the old pointers if the dir didn't change - keep track of how much memory is leaked
I filed the artwork request in the page http://live.gnome.org/GnomeArt/ArtRequests I hope someone will see it
Created attachment 132606 [details] XGD directories with an emblem icon for each folder Used icon theme: gnome-colors by perfectska04 http://www.gnome-look.org/content/show.php/GNOME-colors?content=82562
because of icons: why don't you just use the "emblems" icons? "emblem-documents" for the "Documents" folder and so on... having a folder AND the special type like documents or pictures in front of it as icon (like windows) may be a nice idea but nobody needs it. everybody knows it's a folder so why also show it. also the icons in the sidebar are very small. the desktop has it's own icon in the "Places" sidebar in nautilus and it is also a simple folder but there is no folder icon, just the desktop icon. i attached a mockup to show what i mean. the default gnome icon theme does not offer enough emblem icons so i used the gnome-colors icon theme which has beautiful icons for just everything.
A small reference to a folder image should be included. not everybody knows that it's a folder, as you suppose.
that may be, but in 16x16 size? i think it's much cleaner without the folder icon. also i think the user doesn't really have to know that it's actually a folder. if you want to get to your music, click on music; and not on the music folder.
Can't you differentiate the icon basing on its size?
Before this bug "dies" again (it was started in July 2008), and since I can't set it to a "needinfo" status (I don't have the permissions), I would like a comment to my last patch by Matthias Clasen.
Where can we have a discussion about icons where lots of icon developers are involved, so it's not only me and you two?
I also filed the icons request in bug #584286 as suggested by Lapo Calamandrei in a private conversation
Created attachment 135682 [details] [review] attach-icons-to-xdg-folders.patch This new patch passed the icon naming spec review. Icon names are now "folder-foo"
Created attachment 136405 [details] [review] icons-glib-patch.patch This patch adds an important feature: - fallback "folder" icon when the current theme does not have the requested icon (nautilus has problems with it, so we need nautilus developers to fix it before committing this patch) - changed from "folder-foo" to "user-foo" as it makes more sense (thanks alex) still need a comment from the icon naming spec developer
No, it's better to keep to folder-foo to use default fallbacks. I will update the patch as soon as I'm back home
Created attachment 136424 [details] [review] icons-with-auto-fallback.patch This should be the final. It is applicable even if the theme does not have the "folder-foo" icons, because it fallsback to "folder" icon using an automatic GIO function.
I commited a fixed up version of g_reload_user_special_dirs_cache and code in nautilus to use it.
Works great, but I wonder if folders XDG folder icons should also show up in the path bar? The special icons for home and Desktop are shown, others are not.
Created attachment 137184 [details] Screenshot Desktop VS Download
I don't know how nautilus handles this, sorry
Same for GTK's file chooser btw. Do both share the same code/widget or are they individual implementations?
Nicolò, for GTK file chooser you have to look in http://git.gnome.org/cgit/gtk+/tree/gtk/gtkpathbar.c, there is a special case for root, home and desktop (see ButtonType enum at the beginning of the source code). For Nautilus http://git.gnome.org/cgit/nautilus/tree/src/nautilus-pathbar.c.
I'm afraid I don't have time to propose another patch. can someone else fix this? I guess it's very simple. I'm sorry, but I have to study for a very hard exam.
*** Bug 610192 has been marked as a duplicate of this bug. ***