Re: [Lxde-list] About Menu-Cache

[Joost v. d. H. <2no...@gm...>]

I think this sounds like a good idea as long as the menu definition file generator is easy enough to use. I suggest having it compile all mdf's by default when not giving any arguments, and also provide an option to call it from the right-click menu of any app that uses an mdf (call it 'refresh menu' or something). That way when the packager fails to call the tool the user can easily correct the mistake by manually calling the tool.

Of course, I am assuming the user notices the incorrectness of the menu and is smart enough to know a manual refresh fixes it, which may not hold for the compurer-illiterate. Even though very few (if any) of those actually use linux (or any other OS which an run LXDE), this makes my idea an ugly workaround at best.

Another option would be to declare an alias or something which calls the package manager and then this tool, and everytime the package manager is called have that alias run instead. Do the same for make install (or if that is impossible for every call to make). Dirty solution, I know, but the user probably won't notice and it is ignorant-packager-proof.

I know my solutions both are not exactly great. It seems to me the problem here does not have any really good solutions, though I hope someone comes up with a solution which is at least less bad than the two I have suggested.

2noob2banoob

PCMan <pcm...@gm...>schreef:

>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
>Lxd...@li...
>https://lists.sourceforge.net/lists/listinfo/lxde-list