GNOME Bugzilla – Bug 310089
Can ~/.gnome2/share/fonts in gnome-settings-daemon be removed ?
Last modified: 2008-11-03 19:15:47 UTC
For Xservers with no XCursor support, gnome-settings-daemon tries to add ~/gnome2/share/cursor-fonts and ~/.gnome2/share/fonts to fontpath using XSetFontPath (). When user tries to change the mouse cursor through the mouse capplet, ~/gnome2/share/cursor-fonts will have a symlink to respective .pcf file in $DATADIR/gnome/cursor-fonts. But ~/.gnome2/share/fonts is empty. On solaris X86, with Xorg, the XSetFontPath () is failing because ~/.gnome2/share/fonts is having 0 entries, hence no cursor fonts are found and the mouse cursor remains unchanged. This happens on XFree86 as well. If ~/.gnome2/share/fonts is not added to fontpath, things work as expected. So, - what is the use of ~/.gnome2/share/fonts? - who installs cursor font files here (if at all)? If there is no use of it, can the peice of code adding ~/.gnome2/share/fonts to fontpath be removed in g-s-d ?
Jody: Could you kindly throw some light on this ?
Jody: ping :)
Rodrigo: Can you look at this with the performance stuff for 2.14? Thanks.
Could be related to #319125?
Created attachment 83228 [details] [review] drop ~/.gnome2/share/fonts Might be related to bug 397504 as well which means it should be fixed in 2.17.91. However, I don't see anyone actually using .gnome2/share/fonts either, so... This patch removes the dir and also cleans up the XSetFontDir procedure a bit since we don't need to do that if it already looks the way we want it.
Created attachment 85139 [details] [review] don't create fonts dir on new installations Here's a new patch that still adds the fonts directory to the path if it exists but doesn't create it on new installations, so we should be fully backwards compatible.
I guess this can be committed, anyone has anything against it? If not, Jens, please commit before the end of this week (for 2.19.91 release)
I'm not really convinced it should be applied. As I see it, the main reason for removing that stuff is making the code simpler. All the conditional compatibility stuff in my last patch actually makes everything even more complicated. IMO, we should decide to either keep the directory supported or dump it.
I have a cleanup patch in bug 559163 that fixes the issues raised in this bug, without making the logic more complicated. It simplifies it actually. *** This bug has been marked as a duplicate of 559163 ***