On Mon, 2008-05-12 at 22:58 +0800, John Summerfield wrote: > Gilboa Davara wrote: > > On Mon, 2008-05-12 at 15:28 +0800, John Summerfield wrote: > >> Gilboa Davara wrote: > >>> On Mon, May 12, 2008 at 7:32 AM, Gilboa Davara <gilboad@xxxxxxxxx> wrote: > >>>> On Mon, May 12, 2008 at 7:31 AM, Gilboa Davara <gilboad@xxxxxxxxx> wrote: > >>>>> On Mon, May 12, 2008 at 5:28 AM, John Summerfield > >>>>> <debian@xxxxxxxxxxxxxxxxxxxxxx> wrote: > >>>>>> System: HP DC7700 > >>>>>> OS fedora-release-9-2, AMD-64. > >>>>>> Last updated within the past two houes. > >>>>>> > >>>>>> "Programs" menu in icewm is absolutely empty. Essentially, it's unusable. > >>>>>> > >>>>> Please file a bug report against icewm. > >>>> ... And post the BZ# here. > >>>> > >> 446022 > > > > OK. Assigned to me. (NEEDINFO) > > > >>> I assume that you're using icewm-xdgmenu, right? > > > > > >> Okay, it seems to me an undeclared dependency. > > > > Undeclared, by design. > > Some people might want to define the menus manually. > > Seems to me that > 1. It should, in the first instance, share the global definitions, > 2. Maybe allow per-user overrides. It is possible - but to be honest, it's far, far, too complicated to be worth while. If you rather generate the menus manually, just remove the icewm-xdg-menu line from your system-wide /usr/share/icewm/startup file, or generate a private startup file in ~/.icewm/startup. > > As one who supports users' computers, I see grief for sysadmins in the > current implementation. Sysadmins like computers to all be the same. As long as all machines share the same application list, the menus should be the same. ... BTW, you can always generate the menus on your master machine, and copy the generated ~/.icewm/programs.autogen to each client machine. (-Without- installing the xdgmenu sub package.) > > > >> Note, the description says "each time the user logs _in_." > > > > Indeed. > > As I noted in the bug report, it does happen when one logs in, it > happens asynchronously and had me a bit puzzled when I saw it twice > before it was fully built. > By design. I rather not block the login process while the menus are being built in the background. > > > >> I'd be happier if the menus were built by a script run by rpm; I've > >> never looked at triggers, but I expect that this is the sort of thing > >> they deal with. > > > > Problem is - I don't have any means to detect if the GNOME/KDE menu have > > been changed since the last login. > > Look at what the triggers do. What (I think) you need is to know when > the packages reflected in the menus get installed/removed, maybe updated. Triggers? Do we have DB like triggers in RPM? Please explain. > > > > More-ever, even on my laptop (a PII/366, 256Mhz), rebuilding the menus > > eats ~1-3 seconds (being executed in the background). > > I managed to see it not completed, twice, on a Core 2 Duo system. Umm... weird. Just timed it on a CentOS5 VM running under an Athlon64/X2/5000 host and it took ~2.5-4 seconds. Slower disks maybe? More applications? Worth checking. Can you time it? * - Gilboa * time /usr/share/icewm/startup -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
