So I've been messing around in an antix 13.2 full virtual machine, trying to make the icewm menu update when new packages are installed. I tore open a bunch of .postinst files for various packages, particularly those with a gui, and noticed that most of them call"update-menus" during the post installation process.

so....

I created a new folder in / etc called antix-menu

Then created a blank file called icewm-application in there.

I then removed ~/.icewm/menu-application and replaced it with a symlink called menu-application that links back to / etc / icewm-application .

I then replaced /usr/bin/update-menus with another symlink called update-menus that links to /usr/local/bin/auto-icewm-menu.sh

I also edited /usr/local/bin/auto-icewm-menu.sh to make the menu file in / etc / antix-menu/icewm-application and removed cp line at the end.

Installed a new package (gedit in this case for want of a package to install) . and lo and behold the link was in the menu without any further ado.

downsides: I have no idea if update-menus is something that would ever get updated during a dist-upgrade, but I would expect breakage if it did.

right now installing a new package only updates the icewm menu, but the link could be replaced with a script that updates all three supported window managers without to much hassle I would think.

I also couldn't readily tell if xdg-menus requires the debian"update-menus" for anything. As I said I'm just messing around.

food for thought. An auto-updating menu would be cool.

iIrc, I was sent something not too long ago for testing, that updated menus as you installed stuff.

So... I think something is being worked on?

cool, because I was fairly sure something would break later on my system.

lol, so, it would work as usual, in my case then...

But it might be useful for someone building from core, I guess?
Where you only have 1 wm to worry about?

how many ways to skin a cat? Here are 4 python-powered updaters I've bookmarked:

Automatically generated and self updating menu system for Fluxbox

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/kendalltristan/fm3"
linktext was:"https://github.com/kendalltristan/fm3"
====================================


XFCE -> FluxBox automatic menu updater daemon

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/evilsocket/BBFlux"
linktext was:"https://github.com/evilsocket/BBFlux"
====================================


Algorithm for updating the IceWM menu

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/swiftlinux/z-antix-menu-update"
linktext was:"https://github.com/swiftlinux/z-antix-menu-update"
====================================


auto-updated applications menu for Openbox

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/ansdor/nekomenu"
linktext was:"https://github.com/ansdor/nekomenu"
====================================

couldn't readily tell if xdg-menus requires the debian"update-menus"

requires? no. Including a call to the latter will catch .desktop files for which a debian maintainer has specified a"Debian-specific, extended" category.
There are relatively few extended categories, though, and few if any menu-managing apps are saavy enough to detect and remove duplicates.
(what==duplicate? [Exec] may point to same path, but different/multiple categories... )

if update-menus is something that would ever get updated during a dist-upgrade

Check the changelog for update-menus package. It's mature/stable.
Unlikely to change significantly + I trust the maintainer would strive to assure backward compatibility.

script that updates all three supported window managers

three? more like"eleventeen ...and counting"
A separate, dedicated script for each WM seems like a more reasonable (perhaps necessary) approach.

Not holdin' my breath, but what I'd like to see is (regardless which WM I'm using) is a launcher for each of the most recent
(4?6? configurable)"recently installed" applications displayed to the menu's topmost level. A reduntant categorized copy may be autocreated (or not), but allow me to drag the entry into the category/subcategory _I_ feel is appropriate. Also, empower me to drag/delete/hide entries from within the menu ui (xfce's latest menu is providing the latter)(drag to a 'favorites' category + checkmark to hide an entry). Although I've seen nothing to suggest the forthcoming lxde-qt menu will offer these (draggable reordering) features, I'm hopeful that it will.

edit:
the problem with a"dock" or"panel" containing custom launchers with ability to drag/reorder
is that it's"always loaded" and each launcher item is"always listening for click event"
(tested: each item placed to a custom xfce panel adds 1Mb+ RAM overhead to your session!)
(due to caching the bitmapped content of the icon associated with each launcher?)

I was just trying to make the existing menu updating system for jwm, fluxbox, and icewm to automatically update when installing a package. My method is a little ugly because of the symlink between update-menus (debian's system) and the auto-icewm-menu.sh script. The three scripts already exist, so a master script would just need to call each of the three in turn. Then all three wm's would have up to date application menus. The way the scripts work, the wm's don't need to be running to have their menu's updated.

My concern is that I since I make a fake"update-menus", that an upgrade of the actual package that contains it would break the symlink. If we were actually using"update-menus" for anything, my ugly tweak wouldn't work.

Mostly just playing around though.

I like your wishlist of"recently installed". I also like"recently used". Its one of the things I like about the whisker xfce menu.

The nice thing about the plain text menu files in fluxbox and icewm is they are so bone simple to customize.

Hmm, yes a recently installed section would be nice!
I will see what can be done, should be easily achieved with the apt hook mechanism I am currently favouring / testing / finalizing.....

Recently used may prove a bit more difficult, would it be acceptable to have this recent.... as in the last session login / log out? If so that might be able to be incorporated into the new way of starting /stopping sessions that is currently under development.