On Mon, May 12, 2008 at 5:28 AM, John Summerfield <debian(a)herakles.homelinux.org&gt; wrote: Please file a bug report against icewm. - Gilboa

On Mon, May 12, 2008 at 7:32 AM, Gilboa Davara <gilboad(a)gmail.com&gt; wrote: I assume that you're using icewm-xdgmenu, right? I managed to reproduce the problem, but a simple login-logout solved the problem. Weird. - Gilboa

On Mon, 2008-05-12 at 15:28 +0800, John Summerfield wrote: OK. Assigned to me. (NEEDINFO) Undeclared, by design. Some people might want to define the menus manually. Indeed. Problem is - I don't have any means to detect if the GNOME/KDE menu have been changed since the last login. More-ever, even on my laptop (a PII/366, 256Mhz), rebuilding the menus eats ~1-3 seconds (being executed in the background). If you want to disable the auto-rebuild, just edit the /usr/share/icewm/startup script. Guess so. P.S. IceWM is also a part of Fedora's EPEL repository. (RHEL/CentOS) - Gilboa

On Mon, 2008-05-12 at 22:58 +0800, John Summerfield wrote: 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 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.) By design. I rather not block the login process while the menus are being built in the background. Triggers? Do we have DB like triggers in RPM? Please explain. 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

On Mon, 2008-05-12 at 21:36 +0530, Rahul Sundaram wrote: Ummm... I'll need to think about it. As much as I like the idea of auto-magically adding and removing menu-items, it goes against the very nature of IceWM. Fast, text-based-configured, super-fast WM. - Gilboa

On Tue, 2008-05-13 at 08:02 +0800, John Summerfield wrote: (Aggregation) I don't doubt it. The icewm-xdgmenu is not the ideal solution - hence, it's not installed by default. ... Feel free to produce patches. If they are sane, I'll be happy to include them. I have no idea how your setup looks like. I'm using ssh with private/public keys to propagate settings (and menus) around my network using automated scripts. I beg to differ. ... Again, I beg to differ. You cannot hold IceWM, fluxbox and rest of the light WM crowed to the same requirements as GNOME and KDE. (let alone fvwm and mwm). As I said before, IceWM was never designed to compete with GNOME/KDE/XFCE; By design IceWM uses easy to modify (and understand) text configurations; If you rather not edit them yourself, IMO you are using the wrong tool for job. Having said all that, if you have a solution that perform (far?) better then the -optional- icewm-xdgmenu without adding additional load to the system and/or slowing down icewm once the menus are generated (E.g.: icewm-gnome2) - I'm open to ideas. First, thanks for timing icewm-xdgmenu. 7 seconds is indeed too much. Never the less, I have no viable solution that generates up-to-date menus without eating additional CPU/IO time. E.g. I've considered counting the desktop files - regenerating the menus if the count changes - but even this concept is far from ideal. (Counting files is slow; one application might be replaced by another; etc) OK. May I suggest the following. A. Create a master image under VMWare/KVM. B. Install everything you need. C. Generate the menus one using icewm-xdgmenu; disable it once you done. D. Put the master's public key in the local user's home. E. Create an image of the host and install it on N machines. F. On the master, create a small cron based script that: - Regenerated the menus. - Propagates them to all the client machines. G- Profit. Point taken. Sadly enough, icewm's own documentation doesn't include anything about using icewm-menu-gnome2. I should write something up and add it to %doc. In the mean time, you should add something like that [1] to your menu file. - Gilboa [1] menuprog "Gnome" folder icewm-menu-gnome2 --list /usr/share/applications

Gilboa Davara wrote: These are not really standards http://www.freedesktop.org/wiki/Specifications?action=show&redirect=S... Desktop Entry Specification http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec Desktop Menu Specification http://www.freedesktop.org/wiki/Specifications/menu-spec That implies I have to keep track of when it ought be done. Thanks, but no thanks. It could become a pretty hefty maintenance burden. One can. Some organisations have thousands of computers, so it might take some time. There's no point in accepting user input before it's ready for it, and little point to storing it if it's going to be rebuilt next time. Menus for KDE and Gnome get updated as new packages are installed. I've not explored how it's done, but it's much more convenient than logging off/logging on. /usr/share/doc/rpm-4.4.2.3/triggers They've been there for years. However, I've never used them and I'm not sure of just what one can do with them. 2 Gbytes RAM. SATA disk. Machine basically idle, it's my system for testing (Xen haha and KVM), and not ordinarily busy unless I'm logged on, installing CentOS 5 or rebuilding Knoppix or installing a Windows domain or something. Of course, when someone's logging in there might be other things happening. I'm not sure that this measures the same thing. However, [root@potoroo ~]# time /usr/share/icewm/startup real 0m7.565s user 0m7.462s sys 0m0.073s [root@potoroo ~]# time /usr/share/icewm/startup real 0m7.514s user 0m7.432s sys 0m0.074s [root@potoroo ~]# uptime 07:48:42 up 9:18, 2 users, load average: 0.13, 0.03, 0.01 [root@potoroo ~]# rpm -qa | wc -l 1733 [root@potoroo ~]# [root@potoroo ~]# find /usr/share/apps -name \*.desktop | wc -l 63 [root@potoroo ~]# find /usr/share/applications/ -name \*.desktop | wc -l 366 [root@potoroo ~]# -- Cheers John -- spambait 1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)

Gilboa Davara wrote: A bit about my background, it will help you see my perspective. I currently work at a school. I look after a network of Windows (including AD), Apple Mac and Linux computers. The students use Windows and they are tied down very firmly with Windows group policy. They don't get popup menus, the don't get command windows or the run menu item, they don't get to examine the local disk's contents. If a computer misbehaves, I simply reinstall Windows. Or junk it. The teachers are much like the teachers you and I had when young, they're mostly nice people (but able to convince students they're not), competent at what they do, but mostly clueless about computers. If they can't print, "The Internet's down," and I get a call. If it's not straightforward when the computer's put in their hands, the are lost. In a previous life, I used to be a sysprog on IBM mainframes at the Department of Social Security, and these days I hang out on a list for Linux on zSeries. The school's a small shop, the folk on with the zSeries are from big shops, as DSS was then, is now. I don't like lots of computers that need individual attention. I would expect that DSS and other major departments, and companies, count their computers in tens of thousands, big multinationals in hundreds of thousands. I expect that they lock down their staff as firmly as we lock down the students. Running around giving computers individual attention isn't something that scales or that they would do. Ha! I didn't see a problem with the menus because there isn't a programs menu. However, icewm isn't what I was testing, I don't really have a usable system - graphics is a right mess. Doesn't scale. Contemplate 10,000 computers and 10,000 users. Contempate hot desks (I want a desk, nobody's using that computer, I'll use that one). That system is likely to get nuked. If SLE{D,S} works that might get a go. I've ruled out FreeBSD, it apparently doesn't install on that system. Ubuntu LongLife is a chance. I removed the first, removed ~/.icewm. installed icewm-gnome, logged in/out a few times. No ~/.icewm. .xession-errors mentions files in the directory, but it never gets created and there's no error message. There's no documentation for /usr/bin/icewm-menu-gnome2, and no information on what might be good values to complete this: [root@potoroo ~]# /usr/bin/icewm-menu-gnome2 --help icewm-menu-gnome2: Usage: /usr/bin/icewm-menu-gnome2 [ --open PATH | --list PATH ] [root@potoroo ~]# /usr/bin/icewm-menu-gnome2 icewm-menu-gnome2: Usage: /usr/bin/icewm-menu-gnome2 [ --open PATH | --list PATH ] [root@potoroo ~]# Note that square brackets are ordinarily used to denote optional information, so according to the help info, it should do something useful with no operands. -- Cheers John -- spambait 1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)

On Mon, 2008-05-12 at 20:59 +0530, Rahul Sundaram wrote: I'm not sure that this is that-uncommon (given the target user-base of IceWM - very-low-end-machines - such as my 10 y/o laptop...) - again, generating the menus is a CPU and I/O intensive task. In theory, I can install this icewm-xdgmenu by default, have it run @post, and let the users regenerate the menus manually - but then I would most likely get a lot of "why-isn't-program-X-in-my-menu" bug reports. It would have been nice if I had an apt-like "suggest" feature built into yum/rpm/etc. - Gilboa

On Mon, 2008-05-12 at 21:34 +0530, Rahul Sundaram wrote: I have timed it. On machines ranging from PII/266/256MB to 16-core-Xeon/256GB RAM... ... Needless to say, the Xeon fared much better :) OK. Let me start from the beginning. Icewm's support for desktop files is problematic. It's far slower then normal (manual) menus and you have a lot of missing icons/applications/etc. In essence, icewm works best with text-based menus - mostly because it was designed around it. In-order to get full menus, with user-selectable icon themes, without sacrificing performance, I used Konstantin Korikov xdg-to-icewm menu generator. (Credit where credit is due) You should understand that unlike GNOME/KDE/XFCE Icewm is essentially a text-file driven WM. Menus, toolbars, WM options, startup scripts are all text based. IMHO, having an opt-in automated menu generation system is -big- plus. Never the less, maybe I should do some documentation and drop a README file in %docs. I know. ... But it will give me the option, at least in interactive modes, to offer xdgmenu support. - Gilboa

Gilboa Davara wrote: In the scale common/uncommon, you're ignoring the common case - someone installs the software and expects it to "Just Work(TM)." Once they have some skills, then they might fiddle with it. And, you will impose less load by only doing it when needed (ie there's been a s relevant system change), and speedier login by not doing it at all at that time. -- Cheers John -- spambait 1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)