GNOME Bugzilla – Bug 524896
clean .recently-used.xbel periodically
Last modified: 2008-04-01 16:17:02 UTC
Here is an initial patch to extend the housekeeping plugin to tidy the .recently-used.xbel file by: 1) deleting bookmarks older than X days 2) imposing a limit of Y items per mime type 3) deleting bookmarks for URIs that no longer exist The main issues are: a) is this worth doing? b) what parameter should be used to judge age? added, modified, or visited? c) are the proposed gconf key names OK? - Mike
Created attachment 108198 [details] [review] .recently-used.xbel purge patch v1
Created attachment 108199 [details] [review] .recently-used.xbel purge patch v2 Fixed a small omission.
As I mentioned in the other bug, I'm not convinced this is the right place to do it. The main argument Emmanuele gave in his blog (http://log.emmanuelebassi.net/archives/2008/03/time-to-build/) for not doing it in the toolkit is that some apps (e.g. gimmie) might want to have a more extensive history than others. Well, if we clean up the history on a desktop level, gimmie won't get a longer history either (unless you introduce per app limits which doesn't seem like something we would want to do). Therefore you'd get exactly the same result as with adding the functionality to GTK, plus the disadvantage that plain GTK apps not running under Gnome won't benefit. Adding Emmanuele for comments.
There may be a place for both approaches... some apps could clean their own lists, and the desktop could enforce much looser limits to tidy up those apps that don't clean up themselves. Right now we have no cleaning, of course. Anyway, I'll let the rockstar developers argue it out... - Mike
(In reply to comment #3) > As I mentioned in the other bug, I'm not convinced this is the right place to > do it. The main argument Emmanuele gave in his blog > (http://log.emmanuelebassi.net/archives/2008/03/time-to-build/) for not doing > it in the toolkit is that some apps (e.g. gimmie) might want to have a more > extensive history than others. no. my point in that blog post is that gtk+ doesn't allow neither configuration nor policy, and I advocated that the expiration age of the recently used files list should be a configurable setting. since gtk+ cannot depend on gconf, and GSettings is not yet here, GNOME needs a way to set that configuration parameter and enforce that policy. gnome-settings-daemon is a long running process on the session, so it's an ideal candidate for this - but it's not the only one. if the (old|new) session management allows some process to be run at the end of a session then it's perfectly legitimate to install a handler that does exactly this - with the advantage of being cross platform. the important thing to note is: we (GNOME) need a configuration option and a policy enforcement. since gtk+ doesn't fit with the current configuration platform that GNOME ships we need a place where cleaning up the recently used files list in a configurable way fits.
Emmanuele, What about managing two files?: - recently-used; and - recently-used-history Both of them accesible by the same API. From the application's point of view it would be transparent. The fist one could be loaded in memory and the second one just on demand. Just like every cache. None historical information will be lost and the recently-used file still will be small enough to provide a quick access. So, the cleaner may be called to move entries from recently-used to recently-used-history. And it can be *cough* hardcoded *cough, cough* in 25 (which still is still very conservative).
I think we can close this bug - there's a patch in bug 488507; even though I don't particularly like the GtkSettings approach, this is what we have, and this is what we need to cope with.
I was going to ask about GtkSettings... *** This bug has been marked as a duplicate of 488507 ***