xfdesktop menu cache

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

On Fri, 16 Jul 2004, Olivier wrote:

> On Fri, 2004-07-16 at 21:21, Brian J. Tarricone wrote:
> > 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.
> I disagree with this point of view. The goal is not necessarily to make
> it faster, but to allow the user to use its environment earlier.
> Lemme try to explain: I have the menu in the panel and the desktop. When
> booting for the first time, the system "feels" frozen for maybe 1 minute
> before I can actually run anything. At first, I don't necessarily need
> to use the menu, so I wouldn't care if it was loading while I'm able to
> start my mail, terminal, browser, and so on, from the regular panel
> launchers.
> See, I don't want to make it faster (I guess your cache system will do
> the job btw, we don't need anything more), I want it to be non blocking
> (that's where a separate thread will help).

ah, i see what you mean.  well, there's always the poor-man's 
non-blocking tool:


interspersed every now and then....


More information about the Xfce4-dev mailing list