Awesome stuff! Where were you all these years?
Before I wrote mint-fm2 I asked for help to write this in Python... since I don't know Python. No one stepped up so I wrote it in Bash. (I am not a programmer)
Version 2 was really more reinventing of the wheel than v3. It actually went through and parsed the .desktop files and built the menu. v3 uses libmenu-cache which builds using the standard xdg libraries. It then parses the output and basically formats it for Fluxbox... which is what python-xdg seems to be doing.
I tried to make the Bash code as abstracted and recursive as possible to keep it short and highly configurable by editing variables which are stored separately and imported on the fly. This is most probably why it seems complicated... but I'd like to think that it isn't. My approach is probably not the greatest but it's what I thought up in order to provide the functionality I wanted.
As for the daemons, I am all for fewer background processes. Currently there are 2 that are run. And the daemons are really only inotify commands watching directories for changes... nothing more. Of course some preliminary checks are performed before running inotify and they do the proper daemon thing of forking twice, storing PID, outputting logs, bla, bla, etc. Inotify is the lightest tool I could find to monitor for changes since it runs at the kernel level.
- The root daemon - This monitors for power management triggers from the exit dialog. This makes mint-fm2 independent of GDM or other DMs while still providing the user the ability to shutdown/reboot without having to input an admin password... which I think is important for usability. Keeping the option of being able to do without a DM is something I wanted as well. Also, I didn't want to have a script editing sudoers... which would be another option. If you can think of a better way to do this I am open to suggestions.
- The user daemon. This is run when the user logs in... 'mint-fm2 start'. This monitors for new applications also using inotify. I thought of using dpkg triggers but there were some things I couldn't solve using this method.
1) I wanted each user to have the menu customized to his/her own liking. Dpkg triggers are run as root and generating the menu as root meant that the user could not edit it and that the same menu was shared by all users. This is why in v3 I just have a single user daemon to monitor, generate and update the menu... as opposed to v2 which used a series of triggers and monitors to do the same thing.
2) Dpkg triggers are limited in that they are effective only when applications are installed by dpkg. If the user were to install using some non standard script or if a WINE application was installed in the user's $HOME then a menu update would not be triggered. Using a user daemon allows for this to happen.
3) I wanted the menu to be portable to other distros
Most definitely, there is a lot of room for improvement. Most importantly, in the fact that it is written in Bash. Implementing the same code in Python or C would boost performance I am sure. But that is beyond my skill set right now.
On a smaller note - the detection of application icons. Right now, when the menu is generated, an mlocate database of icons is created. This does take some time. But after that, finding an icon is done by searching the database and that is fast... and in the long run makes it all faster and lighter, I hope. There should be a better and faster way of doing this.
Anyways, I hope you understand better my goals when I wrote up that convoluted script...
If you need any more clarification, do let me know... but more importantly, if you have more suggestions, corrections or ideas... I want to hear them.
Cheers and thanks for taking the time to post back here.