On Mon, 09 Jul 2012 14:15:22 +0200 Stephen Smally <[email protected]> wrote:
> Il 09/07/2012 13:40, PCMan ha scritto: > > 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 :-( > My two cents: As far as i know, apt and other popular package managers > have the triggers script which let you do something anytime a folder is > changed (file added, removed, rename). we use it for lubuntu software > center. If an user has choosen a distro with a simple package manager > (e.g. Arch Linux with pacman, which is my second choice distro), he will > probably take care of this "happily" (i mean, it doesn't bother him). > > So IMO make menu-cache (or menu-whatever) to be as simple as possibile > is a good idea. Do you plan using xml .menu-like files or something > else, like .ini/keyfile files (i think parsing keyfiles is far simpler > than xml)? > > Count on me if you need help. > > Regards, > Stephen Smally Hi, I am not quite sure how things will turn out for a pipe menu having for name openbox-menu if menu-cache is not continued. openbox-menu is a very little program I have been using for a long long time (and many other people too, I don't know how many but I am sure several hundred downloads must have been performed up to now) and it relies on menu-cache. openbox-menu home page is here: http://mimasgpc.free.fr/openbox-menu_en.html Along with it, I used some of the Lxde components, such as Lxpanel (in PCLinuxOS Education), PCManFM in several versions using Openbox as a full environment, which allows to have dynamic menus as in the LXpanel menu. Here a few shots to show how it looks, in Archlinux, PCLinuxOS, Ubuntu, and Sabayon: Archlinux: http://melodie.minus.com/lpNlKuTlCJr25 Ubuntu built from a Mini: http://meets.free.fr/debian/images/2-Ubuntu-Openbox-desktop.png PCLinuxOS Education (fr) http://melodie.minus.com/lI63pkWDjFpXW PCLinuxOS KDE Openbox Christmas : http://melodie.minus.com/lQ0C0MoOaTkIF and I hope to start new spinoffs, built on Ubuntu next, with the same type of setups. I have learned how to package openbox-menu especially for this purpose. (Available at debian-mentors and at Ubuntu PPA). So, if you start making a deep change, I wish it would not be too fast, so that it could be possible to continue relying on libs similar to menu-cache and hopefully that the dev of the openbox-menu program will have an idea about this. Regards, Mélodie ------------------------------------------------------------------------------ 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
