xfdesktop menu cache

Brian J. Tarricone bjt23 at cornell.edu
Fri Jul 16 23:24:23 CEST 2004


just noticed something - there was a bug in XfceAppMenuItem that i fixed 
but forgot to commit - the net effect is that the cache will record menu 
item title as the icon string as well, which sucks.  so, if you use 
icons in the menu, update libxfcegui4 (should be out on anoncvs in an 
hour or 2), and then delete your cache files and run 'xfdesktop 
-reload'.  sorry 'bout that.

	-brian

On Fri, 16 Jul 2004, Brian J. Tarricone wrote:

> hi all-
> 
> i just committed a caching system for the xfdesktop menu.  basically, as 
> it's creating the menu, the cache creates a tree structure (using 
> GNodes) to describe the menu.  after the menu's done, the tree gets 
> written to an XML file, in the same format as ~/.xfce4/menu.xml.  in 
> another file, i store a list of all the relevant menu files and .desktop 
> directories along with their mtimes, to check for cache validity.  on 
> startup, xfdesktop reads this file, checks the mtimes, and matches them 
> against the values in the file.  if there are filesystem changes, we 
> redo the menu, if not, we simply parse the cached XML file instead of 
> ~/.xfce4/menu.xml.
> 
> just to confuse the issue (^_~), the cache files are stored in 
> ~/.cache/xfdesktop.  i'll change it when we decide on what to do about 
> the config dir structure.
> 
> this could use a lot of testing, though it appears to work ok for me.  
> happy bug-hunting!
> 
> on a side note, i've been urged to do the menu generation in a separate 
> thread.  i don't think this will buy us anything, because the menu 
> generation is very gtk-heavy, so i'd have to wrap the _entire_ thing in 
> a big gdk_threads_enter()/gdk_threads_leave() pair, and any other 
> gtk-related stuff in the main thread would get blocked anyway.  as it 
> stands, the initial menu generation (when xfdesktop starts) is idled via 
> g_idle_add(), and xfdesktop connects to the session manager before this 
> runs, so it's about as fast as it can be, IMO.  if anyone has any better 
> ideas (aside from rewriting it to be faster - hah), please let me hear 
> them.
> 
> 	-brian
> 
> 




More information about the Xfce4-dev mailing list