Hi list, 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 xml merging. 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 everytime. 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 and handy. 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.
Pros: 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. Cons: 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 on it. 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 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
