xfdesktop menu cache

[Brian J. Tarricone]

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:

while(gtk_events_pending())
	gtk_main_iteration();

interspersed every now and then....

	-brian