xfdesktop menu cache

[Olivier]

Brian,

Before upgrading 35 seconds, after 20 seconds. That's definitely a great
improvement IMHO. 

This with Benny's new session management code, that's just great.
Congrats!

Plus, it seems to me the menu is not blocking anymore (thanks to
g_idle?) so now, I agree, the thread is not necessary; you are right.

Cheers,
Olivier.

On Fri, 2004-07-16 at 22:04, 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).
> 
> Cheers,
> Olivier.
-- 
 - Olivier Fourdan - fourdan at xfce.org - http://www.xfce.org -