mint-fm2 code enhancements suggestions

Questions about applications and software
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Locked
ju1ius

mint-fm2 code enhancements suggestions

Post by ju1ius »

Hello MintBoxers !

As I migrated from MintFluxbox to Debian Sid + Openbox, I ported mint-fm2 to Openbox.
All was fine until the last version of mint-fm2. The code became too complicated for me, so I decided to roll my own.
After a few days of research, I come back with a few suggestions that, IMHO could benefit the mint-fm2 project.
The code is here.
The keys concepts are:
  • Use of dpkg triggers: this allows the package using them to specify directories to monitor each time another package is install/removed. This completely removes the need for a menu daemon. See the triggers file and postinst script. Here is a tutorial about dpkg triggers.
  • Use the python-xdg library: it is maintained by freedesktop.org and implements most of the specs. No need to reinvent the wheel in bash, and the code to generate the menu is minimal.
  • Use the gdm-control commands for the endsession script. Once again this removes the need for the ciao daemon. Example here
What do you think ?

Thanks for taking time to read, and by the way congrats for all the good work you've all made so far ! :D
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
User avatar
shane
Level 5
Level 5
Posts: 940
Joined: Sun Feb 25, 2007 11:15 pm
Contact:

Re: mint-fm2 code enhancements suggestions

Post by shane »

Hi ju1ius!

Awesome stuff! Where were you all these years? :P 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... :P 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.
Last edited by shane on Sun Aug 29, 2010 7:06 am, edited 1 time in total.
viking777

Re: mint-fm2 code enhancements suggestions

Post by viking777 »

Use of dpkg triggers: this allows the package using them to specify directories to monitor each time another package is install/removed. This completely removes the need for a menu daemon. See the triggers file and postinst script. Here is a tutorial about dpkg triggers.
Don't know what it means.
Use the python-xdg library: it is maintained by freedesktop.org and implements most of the specs. No need to reinvent the wheel in bash, and the code to generate the menu is minimal.
AAAAAGGGGGHHHHH!!!!!

Never, ever,ever do this to Fluxbox. The main reason I use Flux is to avoid the untold damage that 'freedesktop.org' has done to Linux. I would put the inventors of this 'standard' up against a wall and machine gun them.
Use the gdm-control commands for the endsession script
I already do that.
ju1ius

Re: mint-fm2 code enhancements suggestions

Post by ju1ius »

shane wrote: Awesome stuff! Where were you all these years? :P 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)
Lost in the MacOS limbo... I came to Linux a year ago when my mac died, and all I had left was an old wheezy PC.
And I'm not a programmer either. :wink:
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.
Strange, this is not the case on my setup...
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.
Yeah, you're definitely right on this. Then I suppose it must be a design decision then. Use a daemon, lose a few Mb of RAM, but fully automate the menu. No daemon, save RAM, but force the user to "manually" update the menu when they installing in a non-standard way. I'd prefer not to have a daemon, but that's my personal taste.
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...
Yes mlocate is fast. But bash is veeeery slow. I implemented an SQLite cache for the python version, and benchmarked with a menu containing 166 entries.
  • First generation:
    • Bash version: approx. 12.5sec
    • Python version: approx. 3sec
  • Others generations:
    • Bash version: approx. 1.5sec
    • Python version: approx. 0.5sec
Here's the new menu code.

shane wrote: If you can think of a better way to do this I am open to suggestions.
Well, for the reboot/shutdown stuff, you don't need a daemon (nor gdm) if you use DBus:

Code: Select all

# restart
dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager \
    org.freedesktop.ConsoleKit.Manager.Restart
#shutdown
dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager \
    org.freedesktop.ConsoleKit.Manager.Stop
#suspend
dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower \
    org.freedesktop.UPower.Suspend
#hibernate
dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower \
    org.freedesktop.UPower.Hibernate
See: ConsoleKit and UPower, and also PolicyKit.
I hacked an example based on oblogout.
Here's the main app, and here's the DBus wrapper
Last edited by ju1ius on Mon Aug 30, 2010 1:14 pm, edited 1 time in total.
User avatar
shane
Level 5
Level 5
Posts: 940
Joined: Sun Feb 25, 2007 11:15 pm
Contact:

Re: mint-fm2 code enhancements suggestions

Post by shane »

If you can implement the what mint-fm2 does with your menu system I would vote for its inclusion over mint-fm2.

I didn't go through it thoroughly... but how does the dpkg trigger create user editable menu files?
ju1ius

Re: mint-fm2 code enhancements suggestions

Post by ju1ius »

shane wrote:how does the dpkg trigger create user editable menu files?
A few resources:

Code: Select all

man dpkg-trigger
man deb-triggers
Or see: /usr/share/doc/dpkg-dev/triggers.txt.gz

You need first to specified the trigger(s) in the debian/triggers file of your package.
The syntax is:

Code: Select all

interest [file|dir|command]
Here we want to monitor directories so we add

Code: Select all

interest /usr/share/applications
interest /usr/share/desktop-directories
interest /usr/local/share/applications
interest /usr/local/share/desktop-directories
interest /home/*/.local/share/applications
interest /home/*/.local/share/desktop-directories
interest /etc/xdg/menus/lxde-applications-merged
interest /home/*/.config/menus/lxde-applications-merged
When dpkg installs our package, these interests are added to the file: /var/lib/dpkg/triggers/File, like this:

Code: Select all

/path/to/directory  packagename
/path/to/other/directory  packagename
and our debian/postinst script is copied to /var/lib/dpkg/info/packagename.postinst.
From now on, each time another package is touched by dpkg and that this package installs/remove something in one of our "interest" directories, dpkg will execute:

Code: Select all

/var/lib/dpkg/info/packagename.postinst  triggered 
Example: /var/lib/dpkg/info/fluxdgmenu.postinst

Code: Select all

#!/bin/sh
case "$1" in
    # This is triggered by any installation of a desktop entry
    triggered)
      echo DEBUG: processing trigger "'$2'"
      /usr/lib/fluxdgmenu/build
    ;;
    configure|abort-upgrade|abort-remove|abort-deconfigure)
      /usr/lib/fluxdgmenu/build
    ;;
    *)
        echo "postinst called with unknown argument \`$1'" >&2
        exit 1
    ;;
esac
exit 0
This is the way Debian's "menu" app works, except it looks for debian-specific menu files.

But here maybe we should ask users feedback about this question:
:?:Do you prefer a fully automated menu at the cost of having to run a daemon, or do you prefer to save a few megs of RAM at the cost of having to push a putton each time you install in a non-standard way ?
ju1ius

Re: mint-fm2 code enhancements suggestions

Post by ju1ius »

Good Morning ! :D
I pushed a new version of mint-fluxdgmenu with:
  • a new logout menu, in 2 versions: fancy (with Mint logo and pseudo transparency) and simple (just text and buttons)
  • the daemon revisited, with commands to switch on/off the dpkg triggers and regenerate the menu

Code: Select all

# update the menu
/usr/lib/fluxdgmenu/fxm-daemon update
# remove dpkg triggers
/usr/lib/fluxdgmenu/fxm-daemon remove-triggers
# restart dpkg triggers
/usr/lib/fluxdgmenu/fxm-daemon add-triggers
xazax
Level 1
Level 1
Posts: 23
Joined: Thu Jan 21, 2010 1:44 pm

Re: mint-fm2 code enhancements suggestions

Post by xazax »

Sounds interesting. So the menu with triggers would work with any distro + openbox/fluxbox if that distribution uses dpkg?
ju1ius wrote: :?:Do you prefer a fully automated menu at the cost of having to run a daemon, or do you prefer to save a few megs of RAM at the cost of having to push a putton each time you install in a non-standard way ?
What about a configurable solution? For example: the default behaviour is that the daemon is running, however if somebody doesn't need the daemons features ( for the non-standard way install ), or need some extra resources he or she could turn it off and switch to the trigger mode, and manually start/reenable the daemon later if it is neccessary.

This way it would be configurable to one's taste whether he perfer the user friendly or the resource friendly way.
ju1ius

Re: mint-fm2 code enhancements suggestions

Post by ju1ius »

xazax wrote:Sounds interesting. So the menu with triggers would work with any distro + openbox/fluxbox if that distribution uses dpkg?
Yep
xazax wrote: What about a configurable solution? For example: the default behaviour is that the daemon is running, however if somebody doesn't need the daemons features [...] he or she could turn it off and switch to the trigger mode.
Yes Ithink this is the way to go
ju1ius

Re: mint-fm2 code enhancements suggestions

Post by ju1ius »

Allright, I pushed a few changes to the github repo...
  • The daemon:
    • Supports both the daemon mode and the dpkg-triggers mode.
    • Event stack: if several events are fired in less than 5secs, the menu is generated only once.
    • Python version of the daemon (still experimental, so suggestions are welcomed).
  • Configuration
    • - The logout app and menu can be configured globally (in /etc/fluxdgmenu/menu.conf & /etc/fluxdgmenu/logout.conf) or locally (in ~/.fluxbox/fluxdgmenu/menu.conf & ~/.fluxbox/fluxdgmenu/logout.conf).
    • Configuration for the menu: menu file, show icons, icon theme(s), icon size
    • Configuration for the logout: buttons to display and their associated commands, switch DBus on/off. If on (default), the app will use ConsoleKit for reboot/shutdown, UPower for suspend/hibernate, and PolicyKit to gain required permissions (ie in case of reboot if several users are connected).
About the bash daemon, I'm wondering if it is a good idea to use nohup, since it's a userspace daemon.
Shouldn't it be a child of the fluxbox process rather than the init process, so that it could be killed with the session, along with all it's child processes ?
My guess is that if the process is attached to init, it isn't killed on logout, so if if you log in as another user, you'll be running two instances of the daemon, which is useless.
Unless fluxbox sends a sigkill to all programs launched in startup, even if they "belong" to init...

Any ideas on this ?
ju1ius

Re: mint-fm2 code enhancements suggestions

Post by ju1ius »

Hi,
I was unsatisfied with the performance of the bash and python versions of the daemon, so i ported the monitoring part of the code to C. The daemon now hardly uses more than 500kB of RAM. 8)
I think the whole thing is now usable, but as I'm new to the arcanes of compiling/packaging, I'd like to ask you to try and install the debian package I uploaded on github, quickly read the wiki page and report any issues.
I might also need help for i18n someday, since features have been added to the logout application.
:wink:
User avatar
shane
Level 5
Level 5
Posts: 940
Joined: Sun Feb 25, 2007 11:15 pm
Contact:

Re: mint-fm2 code enhancements suggestions

Post by shane »

Have you gotten in touch with Kendall? He maintains Mint Fluxbox now, so it would probably be better for you guys to collaborate... if you want this in Mint Fluxbox that is...

Just an observation... Having it in C now means that it is architecture specific. So to run in 64bit you'd either have to recompile or install lib32.

You make a good point about nohup and the daemon. I wanted it to do the proper daemon thing of forking twice to allow startfluxbox to exit without errors. Else that script remains running until the daemon exits. Multiple instances of the daemon started by different users manages completely different menus... each user's.
jeffreyC

Re: mint-fm2 code enhancements suggestions

Post by jeffreyC »

I am running Linux Mint Fluxbox 9 (Isadora) it is up to date, but when I tried to install Mint-FluXDGMenu GDebi says it cannot because of an unresolved dependency, it needs python-xdg 0.19 or higher and I have 0.18 installed.
So what is this intended for ?
User avatar
shane
Level 5
Level 5
Posts: 940
Joined: Sun Feb 25, 2007 11:15 pm
Contact:

Re: mint-fm2 code enhancements suggestions

Post by shane »

This is still under development. If you need to ask that question then it would be better you avoided this for now.
jeffreyC

Re: mint-fm2 code enhancements suggestions

Post by jeffreyC »

Perhaps I should have been more clear in what I wrote

Linux Mint Fluxbox is based on Ubuntu 10.04 which is based on Debian SID
The current version of python-xdg is 0.18 in Linux Mint Fluxbox 9
But for some odd reason in Debian Squeeze (which has been frozen since ? forever ) is python-xdg 0.19-2

What I was asking is what release or distro is this meant to be used ? Since it requires python-xdg 0.19 or greater.
xazax
Level 1
Level 1
Posts: 23
Joined: Thu Jan 21, 2010 1:44 pm

Re: mint-fm2 code enhancements suggestions

Post by xazax »

Will any part of this work be included in the next release? It would be awesome to have a python or c applet instead of the bash one. And the ability to switch to dpkg trigger mode from the daemon mode would also be great.
Locked

Return to “Software & Applications”