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.
On Mon, May 12, 2008 at 5:28 AM, John Summerfield debian@herakles.homelinux.org 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.
- Gilboa
On Mon, May 12, 2008 at 7:31 AM, Gilboa Davara gilboad@gmail.com wrote:
On Mon, May 12, 2008 at 5:28 AM, John Summerfield debian@herakles.homelinux.org 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.
- Gilboa
On Mon, May 12, 2008 at 7:32 AM, Gilboa Davara gilboad@gmail.com wrote:
On Mon, May 12, 2008 at 7:31 AM, Gilboa Davara gilboad@gmail.com wrote:
On Mon, May 12, 2008 at 5:28 AM, John Summerfield debian@herakles.homelinux.org 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.
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
Gilboa Davara wrote:
On Mon, May 12, 2008 at 7:32 AM, Gilboa Davara gilboad@gmail.com wrote:
On Mon, May 12, 2008 at 7:31 AM, Gilboa Davara gilboad@gmail.com wrote:
On Mon, May 12, 2008 at 5:28 AM, John Summerfield debian@herakles.homelinux.org 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
I assume that you're using icewm-xdgmenu, right?
? What's icewm-xdgmenu, and how would I know to use it?
Oh: apt-cache show icewm-xdgmenu Package: icewm-xdgmenu Section: User Interface/Desktops Installed Size: 7682 Packager: Fedora Project Version: 1.2.35-3.fc9 Depends: icewm = 1.2.35-3.fc9, pyxdg, /bin/sh, /usr/bin/python Provides: icewm-xdgmenu = 1.2.35-3.fc9 Architecture: x86_64 Size: 7682 MD5Sum: 15caf26270607ee693bd5feed21d6255e77e7637 Filename: icewm-xdgmenu-1.2.35-3.fc9.x86_64.rpm Summary: Automatically generate the main IceWM menu Description: IceWM-xdgmenu generates static IceWM menu files from the existing freedesktop.org .desktop files. Files are re-generated each time the user logs-in.
[root@potoroo ~]#
Okay, it seems to me an undeclared dependency.
Note, the description says "each time the user logs _in_."
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.
I managed to reproduce the problem, but a simple login-logout solved the problem. Weird.
Since my problem seems explained by the lack of a menu generator, and presumably you do have said generator, you and I might be seeing different problems.
It will be a while before I test it, atm I'm trying to virtually install CentOS5 using KVM and I'm wondering whether it's emulating the CPU.
- Gilboa
ps Those are interesting names you have; I've "wasted" a pleasant hour or so (time flies) googling both, travelling the world from my desktop. I particularly like this one: http://www.flickr.com/photos/archanasr_2000/2171405876/
pps On VNC alternatives, I use TightVNC on Windows (native Windows binaries) but not on Linux (Crashes coming out of -fullscreen, or was it going into -fullscreen? Not good either way).
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@gmail.com wrote:
On Mon, May 12, 2008 at 7:31 AM, Gilboa Davara gilboad@gmail.com wrote:
On Mon, May 12, 2008 at 5:28 AM, John Summerfield debian@herakles.homelinux.org 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.
Note, the description says "each time the user logs _in_."
Indeed.
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. 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.
I managed to reproduce the problem, but a simple login-logout solved the problem. Weird.
Since my problem seems explained by the lack of a menu generator, and presumably you do have said generator, you and I might be seeing different problems.
Guess so.
It will be a while before I test it, atm I'm trying to virtually install CentOS5 using KVM and I'm wondering whether it's emulating the CPU.
P.S. IceWM is also a part of Fedora's EPEL repository. (RHEL/CentOS)
- Gilboa
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@gmail.com wrote:
On Mon, May 12, 2008 at 7:31 AM, Gilboa Davara gilboad@gmail.com wrote:
On Mon, May 12, 2008 at 5:28 AM, John Summerfield debian@herakles.homelinux.org 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.
As one who supports users' computers, I see grief for sysadmins in the current implementation. Sysadmins like computers to all be the same.
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.
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.
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.
If you want to disable the auto-rebuild, just edit the /usr/share/icewm/startup script.
I managed to reproduce the problem, but a simple login-logout solved the problem. Weird.
Since my problem seems explained by the lack of a menu generator, and presumably you do have said generator, you and I might be seeing different problems.
Guess so.
It will be a while before I test it, atm I'm trying to virtually install CentOS5 using KVM and I'm wondering whether it's emulating the CPU.
P.S. IceWM is also a part of Fedora's EPEL repository. (RHEL/CentOS)
atm I have SL5 on two systems, I have IceWM on one of them. It seemed pretty quick (and I didn't see a problem with the menus), that was (in part) why I installed it on Fedora.
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@gmail.com wrote:
On Mon, May 12, 2008 at 7:31 AM, Gilboa Davara gilboad@gmail.com wrote:
On Mon, May 12, 2008 at 5:28 AM, John Summerfield debian@herakles.homelinux.org 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
- It should, in the first instance, share the global definitions,
- 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
Gilboa Davara wrote:
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.
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch05s03.html
Rahul
On Mon, 2008-05-12 at 21:36 +0530, Rahul Sundaram wrote:
Gilboa Davara wrote:
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.
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch05s03.html
Rahul
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
Gilboa Davara wrote:
On Mon, 2008-05-12 at 21:36 +0530, Rahul Sundaram wrote:
Gilboa Davara wrote:
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.
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch05s03.html
Rahul
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.
Seems to me that this approach might be quicker in users' hands - it might be ready for me seven seconds sooner.
For users' private menus while logged in, there's FAM (File Alteration Monitor) or its successor to see when you need to reread the file.
The menu created by icewm-xdg-menu looks like it's easily extended to allow an include to insert/merge a menu from users' home directory. For sysadmins' sanity, I'd suggest that each include would create a submenu, not replace or change any existing menu. Any includes would need to be preserved over a rebuild, but that doesn't look difficult.
- Gilboa
On Tue, 2008-05-13 at 08:02 +0800, John Summerfield wrote: (Aggregation)
Seems to me that this approach might be quicker in users' hands - it might be ready for me seven seconds sooner.
I don't doubt it. The icewm-xdgmenu is not the ideal solution - hence, it's not installed by default.
For users' private menus while logged in, there's FAM (File Alteration Monitor) or its successor to see when you need to reread the file.
The menu created by icewm-xdg-menu looks like it's easily extended to allow an include to insert/merge a menu from users' home directory. For sysadmins' sanity, I'd suggest that each include would create a submenu, not replace or change any existing menu. Any includes would need to be preserved over a rebuild, but that doesn't look difficult.
...
Hopefully, the work to do it is light and educational.
Feel free to produce patches. If they are sane, I'll be happy to include them.
One can. Some organisations have thousands of computers, so it might take some time.
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.
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.
I beg to differ.
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.
...
I don't have a problem with it sticking with its existing menu/options/startup etc. I do think it should respect the conventions that apply in Fedora (and its relatives), and my cursory reading of RPM's triggers suggests that the triggers mechanism provides a way of keeping properly synchronised.
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.
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
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)
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.
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.
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 ]
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
On Tue, 2008-05-13 at 08:02 +0800, John Summerfield wrote: (Aggregation)
Seems to me that this approach might be quicker in users' hands - it might be ready for me seven seconds sooner.
I don't doubt it. The icewm-xdgmenu is not the ideal solution - hence, it's not installed by default.
For users' private menus while logged in, there's FAM (File Alteration Monitor) or its successor to see when you need to reread the file.
The menu created by icewm-xdg-menu looks like it's easily extended to allow an include to insert/merge a menu from users' home directory. For sysadmins' sanity, I'd suggest that each include would create a submenu, not replace or change any existing menu. Any includes would need to be preserved over a rebuild, but that doesn't look difficult.
...
Hopefully, the work to do it is light and educational.
Feel free to submit patches. If they are sane, I'll be happy to include them.
One can. Some organisations have thousands of computers, so it might take some time.
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.
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.
I beg to differ.
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.
...
I don't have a problem with it sticking with its existing menu/options/startup etc. I do think it should respect the conventions that apply in Fedora (and its relatives), and my cursory reading of RPM's triggers suggests that the triggers mechanism provides a way of keeping properly synchronised.
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.
Never the less, if you have solution that yields a better of-of-the-box experience without eating too much CPU and/or IO (Unlike, say, icewm-gnome2), I'll be happy include them.
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
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 and I/O intensive; one application might be replaced by another keeping the count constant; etc)
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.
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.
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 ]
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:
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@gmail.com wrote:
On Mon, May 12, 2008 at 7:31 AM, Gilboa Davara gilboad@gmail.com wrote: > On Mon, May 12, 2008 at 5:28 AM, John Summerfield > debian@herakles.homelinux.org 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
- It should, in the first instance, share the global definitions,
- Maybe allow per-user overrides.
It is possible - but to be honest, it's far, far, too complicated to be worth while.
These are not really standards http://www.freedesktop.org/wiki/Specifications?action=show&redirect=Stan...
Desktop Entry Specification http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
Desktop Menu Specification http://www.freedesktop.org/wiki/Specifications/menu-spec
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.
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.
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.)
One can. Some organisations have thousands of computers, so it might take some time.
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.
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.
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.
/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.
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.
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.
Can you time it? *
- Gilboa
- time /usr/share/icewm/startup
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 ~]#
On Mon, 2008-05-12 at 22:58 +0800, John Summerfield wrote:
atm I have SL5 on two systems, I have IceWM on one of them. It seemed pretty quick (and I didn't see a problem with the menus), that was (in part) why I installed it on Fedora.
Here's what I do on my VM's: Install the both the icewm and the icewm-xdgmenu. Login once. (To generate the program list.) Create a local startup ($HOME/.icewm/startup) file that will only regenerates the menus if programs.programs.autogen is N days old. Shazam! icewm logs in within 1 second.
As for SL5, I'd venture and guess that are using IceWM's built-in gnome and/or KDE support. Sadly enough, I found that under Fedora, neither one generated satisfying results. (Missing applications; missing icons; etc) Only xdgmenu gave me the necessary flexibility I needed. (E.g. use custom font-sets)
... You could try icewm-gnome (also in the repos) and see if it works better for you.
- Gilboa
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.
On Mon, 2008-05-12 at 22:58 +0800, John Summerfield wrote:
atm I have SL5 on two systems, I have IceWM on one of them. It seemed pretty quick (and I didn't see a problem with the menus), that was (in part) why I installed it on Fedora.
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.
Here's what I do on my VM's: Install the both the icewm and the icewm-xdgmenu. Login once. (To generate the program list.) Create a local startup ($HOME/.icewm/startup) file that will only regenerates the menus if programs.programs.autogen is N days old. Shazam! icewm logs in within 1 second.
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).
As for SL5, I'd venture and guess that are using IceWM's built-in gnome and/or KDE support.
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.
Sadly enough, I found that under Fedora, neither one generated satisfying results. (Missing applications; missing icons; etc) Only xdgmenu gave me the necessary flexibility I needed. (E.g. use custom font-sets)
... You could try icewm-gnome (also in the repos) and see if it works better for you.
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.
On Mon, 2008-05-12 at 20:59 +0530, Rahul Sundaram wrote:
Gilboa Davara wrote:
Undeclared, by design. Some people might want to define the menus manually.
You are optimizing for the uncommon use cases which is the wrong thing to do IMO.
Rahul
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
Gilboa Davara 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.
We have timed this?
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.
Every properly packaged program (MUST in Fedora packaging guidelines) would have a .desktop file and the program would show up as defined by xdg spec. This is what we should support out of the box regardless of the desktop environment. If the programs don't show up on the menu automatically, wouldn't that indicate a packaging bug?
It would have been nice if I had an apt-like "suggest" feature built into yum/rpm/etc.
Suggest is probably going to rpm.org upstream soon and has been patched by various distros for a while now. However it can be a pain for automated installations (do you install soft deps or not?), QA (test with and without the optional dependencies) and should be used very carefully.
Rahul
On Mon, 2008-05-12 at 21:34 +0530, Rahul Sundaram wrote:
Gilboa Davara 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.
We have timed this?
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 :)
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.
Every properly packaged program (MUST in Fedora packaging guidelines) would have a .desktop file and the program would show up as defined by xdg spec. This is what we should support out of the box regardless of the desktop environment. If the programs don't show up on the menu automatically, wouldn't that indicate a packaging bug?
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.
It would have been nice if I had an apt-like "suggest" feature built into yum/rpm/etc.
Suggest is probably going to rpm.org upstream soon and has been patched by various distros for a while now. However it can be a pain for automated installations (do you install soft deps or not?), QA (test with and without the optional dependencies) and should be used very carefully.
I know. ... But it will give me the option, at least in interactive modes, to offer xdgmenu support.
Rahul
- Gilboa
Gilboa Davara wrote:
On Mon, 2008-05-12 at 21:34 +0530, Rahul Sundaram wrote:
Gilboa Davara 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.
We have timed this?
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 :)
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.
Every properly packaged program (MUST in Fedora packaging guidelines) would have a .desktop file and the program would show up as defined by xdg spec. This is what we should support out of the box regardless of the desktop environment. If the programs don't show up on the menu automatically, wouldn't that indicate a packaging bug?
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.
I don't have a problem with it sticking with its existing menu/options/startup etc.
I do think it should respect the conventions that apply in Fedora (and its relatives), and my cursory reading of RPM's triggers suggests that the triggers mechanism provides a way of keeping properly synchronised.
Hopefully, the work to do it is light and educational.
Gilboa Davara wrote:
On Mon, 2008-05-12 at 20:59 +0530, Rahul Sundaram wrote:
Gilboa Davara wrote:
Undeclared, by design. Some people might want to define the menus manually.
You are optimizing for the uncommon use cases which is the wrong thing to do IMO.
Rahul
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 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.
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