mint-fm2 code enhancements suggestions

Forum rules
Before you post please read this

mint-fm2 code enhancements suggestions

Postby ju1ius on Sat Aug 28, 2010 6:11 pm

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
ju1ius
Level 1
Level 1
 
Posts: 35
Joined: Wed Jul 29, 2009 11:40 am
Location: Marseille, France

Linux Mint is funded by ads and donations.
 

Re: mint-fm2 code enhancements suggestions

Postby shane on Sun Aug 29, 2010 6:52 am

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.
User avatar
shane
Level 6
Level 6
 
Posts: 1300
Joined: Sun Feb 25, 2007 11:15 pm

Re: mint-fm2 code enhancements suggestions

Postby viking777 on Sun Aug 29, 2010 6:56 am

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.
Fujitsu Lifebook AH532. Intel i5 processor, 6Gb ram, Intel HD3000 graphics, Intel Audio/wifi. Realtek RTL8111/8168B Ethernet.Lubuntu 13.10,Ubuntu12.10 (Unity), Mint16 (Cinnamon), Manjaro (Xfce).
Image
User avatar
viking777
Level 14
Level 14
 
Posts: 5153
Joined: Mon Dec 01, 2008 11:21 am

Re: mint-fm2 code enhancements suggestions

Postby ju1ius on Mon Aug 30, 2010 3:35 am

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.
ju1ius
Level 1
Level 1
 
Posts: 35
Joined: Wed Jul 29, 2009 11:40 am
Location: Marseille, France

Re: mint-fm2 code enhancements suggestions

Postby shane on Mon Aug 30, 2010 4:28 am

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?
User avatar
shane
Level 6
Level 6
 
Posts: 1300
Joined: Sun Feb 25, 2007 11:15 pm

Re: mint-fm2 code enhancements suggestions

Postby ju1ius on Mon Aug 30, 2010 12:14 pm

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
Level 1
Level 1
 
Posts: 35
Joined: Wed Jul 29, 2009 11:40 am
Location: Marseille, France

Re: mint-fm2 code enhancements suggestions

Postby ju1ius on Tue Aug 31, 2010 1:25 am

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
ju1ius
Level 1
Level 1
 
Posts: 35
Joined: Wed Jul 29, 2009 11:40 am
Location: Marseille, France

Re: mint-fm2 code enhancements suggestions

Postby xazax on Tue Aug 31, 2010 6:58 am

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.
xazax
Level 1
Level 1
 
Posts: 23
Joined: Thu Jan 21, 2010 1:44 pm

Re: mint-fm2 code enhancements suggestions

Postby ju1ius on Wed Sep 08, 2010 10:32 pm

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
Level 1
Level 1
 
Posts: 35
Joined: Wed Jul 29, 2009 11:40 am
Location: Marseille, France

Re: mint-fm2 code enhancements suggestions

Postby ju1ius on Wed Sep 08, 2010 11:14 pm

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
Level 1
Level 1
 
Posts: 35
Joined: Wed Jul 29, 2009 11:40 am
Location: Marseille, France

Re: mint-fm2 code enhancements suggestions

Postby ju1ius on Tue Sep 28, 2010 11:48 pm

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:
ju1ius
Level 1
Level 1
 
Posts: 35
Joined: Wed Jul 29, 2009 11:40 am
Location: Marseille, France

Re: mint-fm2 code enhancements suggestions

Postby shane on Wed Sep 29, 2010 2:36 am

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.
User avatar
shane
Level 6
Level 6
 
Posts: 1300
Joined: Sun Feb 25, 2007 11:15 pm

Re: mint-fm2 code enhancements suggestions

Postby jeffreyC on Sat Oct 02, 2010 5:19 pm

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 ?
Get Dropbox and an extra 250 mb http://db.tt/wAizqw0
jeffreyC
Level 4
Level 4
 
Posts: 318
Joined: Mon Jun 07, 2010 9:34 pm

Re: mint-fm2 code enhancements suggestions

Postby shane on Sat Oct 02, 2010 5:42 pm

This is still under development. If you need to ask that question then it would be better you avoided this for now.
User avatar
shane
Level 6
Level 6
 
Posts: 1300
Joined: Sun Feb 25, 2007 11:15 pm

Re: mint-fm2 code enhancements suggestions

Postby jeffreyC on Thu Oct 07, 2010 9:24 pm

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.
Get Dropbox and an extra 250 mb http://db.tt/wAizqw0
jeffreyC
Level 4
Level 4
 
Posts: 318
Joined: Mon Jun 07, 2010 9:34 pm

Re: mint-fm2 code enhancements suggestions

Postby xazax on Mon Oct 25, 2010 12:38 pm

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.
xazax
Level 1
Level 1
 
Posts: 23
Joined: Thu Jan 21, 2010 1:44 pm

Linux Mint is funded by ads and donations.
 

Return to Others

Who is online

Users browsing this forum: No registered users and 4 guests