Hi, The Menu VFS code has to do a number of things when the panel first reads it as well: 1) Locate and read all .menu files in /etc/xdg/menus 2) Parse these menus and locate all .desktop/.directory directories 3) Parse all .desktop/.directory files from (2) to find out their categories, names, and OnlyShowIn values 4) Create the actual menu structure from the data in (2) and (3) There is definitely room for improvement and optimization here in the menu code, but 1 - 4 have to happen in any case, which includes a lot of hitting the disk. So if you're doing something disk intensive at the time you first click, it might take a couple seconds. Also, if the directories or files in (1) and (2) get touched or changed, the whole menu structure is currently rebuilt to make it aware of changes, which means invalidating a lot of cache and reloading many bits of info. Dan On Tue, 2004-05-11 at 13:30 +0100, Mark McLoughlin wrote: > Hi, > > On Tue, 2004-05-11 at 13:30, Alexander Larsson wrote: > > On Fri, 2004-05-07 at 17:08, Julien Olivier wrote: > > > On Wed, 2004-05-05 at 22:11, Will Cohen wrote: > > > And, from time to time, clicking on the main menu takes ages to display > > > the menu (where ages really mean up to 10 seconds) > > > > I think the panel loads the menu "on-demand" to save memory, and once > > its loaded its forgotten if not used for a while. Or something like > > that. > > I haven't quite figured out whats going on here yet. There are a number > of options: > > 1) We check and re-read the menu on click > > 2) The menu has been swapped out by that stage > > 3) Destroying the GTK+ menu takes a long time (this was a problem at > one point with GTK+ 2.3.x, but that got fixed) > > It needs profiling. > > Cheers, > Mark. > > > -- > > Fedora-desktop-list@xxxxxxxxxx > http://www.redhat.com/mailman/listinfo/fedora-desktop-list
