Isn't there a trigger already for GNOME/KDE/Xfce to update the menu after an application was installed?
That could be used to call the update program (with a symbolic link)
PCManFM is marching toward its 1.0 release. So let's talk about others.
We all know that, menu-cache is used by several parts of LXDE, but
it's not stable.
Why the hell is menu-cache needed?
The main idea behind this is loading an application menu according to
freedesktop.org menu spec is very resource hungry.
It involves loading and parsing of hundreds of desktop entry files
(more than 200 usually) and several xml files along with complicated
We do quite a lot of disk I/O just to generate a small application menu.
However, the content of the menu rarely changes. It only changes when
new applications are installed or old applications are uninstalled. So
it's a waste to generate the rarely changed data with so much disk I/O
That's why I did cache for it. KDE does the same in kbuildsycoca. KDE
Sycoca is a binary cache file.
Doing cache, however, causes problems because we need to sync with new changes.
To get notified when files change, we have to monitor 10~20
directories at the same time, for one menu.
This is what we currently do, but why we need to waste so much
resources just to keep a small menu which rarely changes?
A simple menu definition file used by old window managers looks simple
Though you have to edit the menu definition file with a text editor,
ironically, with freedesktop.org spec, menu editing becomes far more
difficult. Nobody knows exactly how to edit these xml files and there
is no user-friendly menu editor after so many years.
I really think the freedesktop.org approach is wrong and it's the
wrong direction to go.
Generating a simple menu definition file based on content of
applications dirs, just like what other window managers did in the
past, is good enough.
So, I'm actually consider the possibility of deprecating menu-cache
and replace it with a simple menu definition file.
Then, we add a program to read xdg menu and generate the menu
definition file based on installed applications.
However, we don't do any directory monitoring.
The packagers need to call the menu generation program in post-install
scripts of the installed programs.
1. We only have one single simple menu definition file which loads really fast.
2. We don't need to monitor tons of files just for small and rare changes.
3. Menu editing can become much simpler and more flexible.
1. Some distros or other OSes may have no post-install hooks
2. For manually compiled and installed programs, the user needs to
call the menu generation tool, which is very bad.
3. It's hard to let every packages containing a *.desktop to call our
menu generating tool after their installation
4. It's not possible to drop freedesktop.org menu completely as it
provides much useful info. So we still need to generate the menu based
Please, I need comments and suggestions, especially those from packagers.
Nowadays KISS in LInux desktop becomes more and more difficult.
So sad :-(
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
Lxde-list mailing list