Author Topic: A categorized desktop menu for i3 using dmenu (or rofi or something else)  (Read 9885 times)

0 Members and 1 Guest are viewing this topic.

Offline torvic9

  • Sr. Mitglied
  • ****
  • Posts: 253
  • Hello world!
  • Branch: stable
  • Skill: Intermediate
I've been absent from the forums for a week, and then I see that boruch presents us with a very promising tool.
I'm still using rofi for the moment, but I'm going to test morc and report back, thanx boruch!
i3: i7-5820K | 32 GB | GeForce GTX 960, nvidia | linux44-custom
KDE: i7-920 | 12 GB | GeForce GTS 450, nouveau | linux44
Gnome: Thinkpad X200s | linux41

Offline boruch

  • Jr. Mitglied
  • **
  • Posts: 85
  • Skill: Intermediate
I got curious about PKGBUILD, so I wrote and tested one that seems to work, but when I tried to add an advanced feature, I came across a frustration I haven't been able to solve yet.
Code: [Select]
# Emacs! -*- mode:shell-script; mode:visual-line; -*-
# Maintainer: Chrysostomus @forum.manjaro.org
# Maintainer: boruch @forum.manjaro.org

pkgname=morc_menu
pkgver=1.0
pkgrel=1
pkgdesc="A categorized applications menu using dmenu and bash"
arch=(any)
url="https://github.com/Boruch-Baum/morc_menu"
license=(GPL3)
depends=('dmenu'
'bash')
optdepends=(
'wmutils: Spawn menu on cursor'
'xdotool: Spawn menu on cursor'
'dmenu-manjaro: Support for mouse, xft fonts and menu placing'
'rofi: Alternative frontend'
'zenity: Alternative frontend'
'rootmenu: Spawn menu by clicking desktop')
# changelog=()
install=morc_menu.install
source=("https://github.com/Boruch-Baum/morc_menu/archive/master.zip")
sha256sums=('56efe1d2010107fe102b5f3580e3bf7776e693efc1e610ef9555123eb9b3cecd')

package () {
    srcdir="morc_menu-master"
    install -Dm755 "$srcdir/morc_menu" "$pkgdir/usr/bin/morc_menu"
    install -Dm644 "$srcdir/morc_menu_v1.conf" "$pkgdir/etc/skel/.config/morc_menu/morc_menu_v1.conf"
    install -Dm644 "$srcdir/morc_menu_v1.conf" "$pkgdir/usr/share/morc_menu/morc_menu_v1.conf"
    install -Dm644 "$srcdir/morc_menu.1" "$pkgdir/usr/share/man/man1/morc_menu.1"
    gzip "$pkgdir/usr/share/man/man1/morc_menu.1"
}
The major change in this PKGBUILD is that instead of cloning an entire git repository, it just dowloads the github zip file of the current state of the master branch. In the case of morc_menu, that's not a big savings in bandwidth / time, but for projects with long / large commit histories, the savings could be huge.

UPDATE: I want to clarify the intention of using the github zip file, because it can easily be misused in conjunction with the sha236sum. The way the above PKGBUILD file is written, it will fail when the next commit is made to the github repository, because the checksum will fail. If PKGBUILD is going around cloning the current state of github repositories, it's apt to try installing snapshots that are temporarily broken or even working but in flux and not suitable for distribution. From the side of the repository maintainer, the solution is to create branches for working release versions. From the side of PKGBUILD, the solution is to point to those github zip files. In the morc_menu case, I'm basically ready to do that, but the project has benefited from delaying a bit, and I kind of want to solve or figure out Oberon's trouble with response time before cementing version 1.0.

Now, the part that's giving me trouble. I created a .install file, put it in the same folder as PKGBUILD, the same folder from which I execute makepkg:
Code: [Select]
post_install() {
  pacman -Q dmenu-manjaro wmutils xdotool \
  && sed -i -e '/^menu_cmd=/s/=.*$/="dmenu -i -l MENU_LINES -x X_POSITION -y Y_POSITION -w MENU_WIDTH "/' -e '/^error_cmd=/s/=.*$/="dmenu -i -l 40 -x 500 -y 150 -w MENU_WIDTH -nb red -nf black -fn DejaVu"/' "$pkgdir/usr/share/morc_menu/morc_menu_v1.conf"
  }
1] The indivual lines of the script work fine outside of makepkg.
2] The trouble may be the path of the sed input file, but I've tried all kinds of paths for the sed target, including absolute paths, and paths using $srcdir instead of $pkgdir.
3] The trouble seems to be that the function is never being called, because when I replace the function contents with 'touch ${HOME}test, the file is not created,.

Any help would be appreciated. Also, if this question belongs on another part of the forum, let me know and I will repost there.
« Last Edit: 17. March 2016, 14:23:58 by boruch »

Offline Chrysostomus

  • Maintainer
  • ***
  • Posts: 1634
  • Neckbeards are cool
    • Git
  • Branch: unstable
  • Desktop: Gnome, bspwm
  • GPU Card: Intel HD4000
  • GPU driver: free
  • Kernel: linux44-x64
  • Skill: Intermediate
Comparing it with my own pkgbuild that had install script (bspwm-manjaro https://github.com/manjaro/packages-community/tree/master/bspwm-manjaro), only difference I noticed is that my script has
Code: [Select]
#!/bin/bash
In it and my install script is single quoted in the pkgbuild:
Code: [Select]
install='bspwm-manjaro.install'
I used to get similar issue, that the function was not called when it should have. Then it just started working at some point, I'm not sure what it was that I changed that made the difference. But I would try quoting
Code: [Select]
install='morc_menu.install'It might be that "install" should be an array and not a variable. Or something.

Offline Chrysostomus

  • Maintainer
  • ***
  • Posts: 1634
  • Neckbeards are cool
    • Git
  • Branch: unstable
  • Desktop: Gnome, bspwm
  • GPU Card: Intel HD4000
  • GPU driver: free
  • Kernel: linux44-x64
  • Skill: Intermediate
I think this is okay place to discuss this. Another possibility would be programming subforum.

Offline boruch

  • Jr. Mitglied
  • **
  • Posts: 85
  • Skill: Intermediate
[SOLVED] Trouble with PKGBUILD post_install
« Reply #34 on: 17. March 2016, 15:37:28 »
The trouble was that I misuderstood the mechanics and timing of the .install file. The file is NOT invoked when running makepkg; it is used by makepkg to create a file named '.INSTALL', which is put int the tar.xz created by makepkg. The contents of this '.INSTALL' script are run by pacman at the time of actual install.

So finally, the following file morc_menu.install checks for the presence of what's required for the extra features of dmenu-manjaro, and if those are all available, will auto-magically alter the morc_menu config file at install time to use those features! How user-friendly is that!
Code: [Select]
post_install() {
  pacman -Q dmenu-manjaro wmutils xdotool \
  && sed -i -e '/^menu_cmd=/s/=.*$/="dmenu -i -l MENU_LINES -x X_POSITION -y Y_POSITION -w MENU_WIDTH ${DMENU_OPTIONS} "/' -e '/^error_cmd=/s/=.*$/="dmenu -i -l 40 -x 500 -y 150 -w MENU_WIDTH -nb red -nf black -fn DejaVu"/' /usr/share/morc_menu/morc_menu_v1.conf /etc/skel/.config/morc_menu/morc_menu_v1.conf
  }

post_upgrade() {
  post_install
  }
« Last Edit: 17. March 2016, 15:54:46 by boruch »

Offline Chrysostomus

  • Maintainer
  • ***
  • Posts: 1634
  • Neckbeards are cool
    • Git
  • Branch: unstable
  • Desktop: Gnome, bspwm
  • GPU Card: Intel HD4000
  • GPU driver: free
  • Kernel: linux44-x64
  • Skill: Intermediate
Cool  :)

Offline boruch

  • Jr. Mitglied
  • **
  • Posts: 85
  • Skill: Intermediate
SUCCESS! Successful install from start to finish
« Reply #36 on: 17. March 2016, 15:54:07 »
I used the PKGBUILD and the .install file as recorded below in this thread to run makepkg, then ran pacman -U on the .xz file, and placed the following line in my personal ~/.i3/config file:
Code: [Select]
bindsym $mod+z exec morc_menu
And . . . it totally totally works. Even the part of the post_install script recognizing the presence of the augmented dmenu and its dependencies and modifying the default config file for the nicer display features.

Do note that I've modified the .install file below to include ${DMENU_OPTIONS} so morc_menu will import the manjaro i3 'skin' for dmenus.

Offline oberon

  • Core Team
  • *****
  • Posts: 3858
  • I'm nice. Be new!
  • Branch: unstable
  • Desktop: i3, Deepin, Cinnamon
  • GPU Card: Intel ValleyView Gen7
  • GPU driver: Intel
  • Kernel: 4.1 / 4.4
  • Skill: Intermediate
Looks great! Congratulations! :)
If you send a pull request at manjaro/packages-community I will package it tonight.
manjaro is addictive ::)
* manjaro-i3  * manjaro-cinnamon  * manjaro-deepin

Offline oberon

  • Core Team
  • *****
  • Posts: 3858
  • I'm nice. Be new!
  • Branch: unstable
  • Desktop: i3, Deepin, Cinnamon
  • GPU Card: Intel ValleyView Gen7
  • GPU driver: Intel
  • Kernel: 4.1 / 4.4
  • Skill: Intermediate
Re: [SOLVED] Trouble with PKGBUILD post_install
« Reply #38 on: 17. March 2016, 17:10:06 »
pacman -Q dmenu-manjaro wmutils xdotool
I don't  understand how this 'checks' for the install status of the three packages. How are you processing the output here? ???
manjaro is addictive ::)
* manjaro-i3  * manjaro-cinnamon  * manjaro-deepin

Offline oberon

  • Core Team
  • *****
  • Posts: 3858
  • I'm nice. Be new!
  • Branch: unstable
  • Desktop: i3, Deepin, Cinnamon
  • GPU Card: Intel ValleyView Gen7
  • GPU driver: Intel
  • Kernel: 4.1 / 4.4
  • Skill: Intermediate
Oh, I see.you just precede when there is no error :)
Maybe divert the output to dev/null?
manjaro is addictive ::)
* manjaro-i3  * manjaro-cinnamon  * manjaro-deepin

Offline Chrysostomus

  • Maintainer
  • ***
  • Posts: 1634
  • Neckbeards are cool
    • Git
  • Branch: unstable
  • Desktop: Gnome, bspwm
  • GPU Card: Intel HD4000
  • GPU driver: free
  • Kernel: linux44-x64
  • Skill: Intermediate
Pacman -Q returns 1 as exit status if one of th packages is not installed. Stuff after && happens only if exit status of previous command is 0.

Offline boruch

  • Jr. Mitglied
  • **
  • Posts: 85
  • Skill: Intermediate
Screenshots and walk-through!
« Reply #41 on: 18. March 2016, 07:22:50 »

Offline torvic9

  • Sr. Mitglied
  • ****
  • Posts: 253
  • Hello world!
  • Branch: stable
  • Skill: Intermediate
Finally got around to do some basic testing.

morc_menu works with rofi, just use "rofi -dmenu" as menu_cmd in morc_menu's config file.

However, I lose the functionality to just type in the first letters of a given application. I can search the categories, but not the entries inside each category: if I type "aud", audacious doesn't show up. I first have to go to 'audio' sub-menu and only then can I enter "Aud". Same with dmenu instead of rofi.

morc_menu seems to look in the applications' descriptions, but not in the applications' names?

Here are two screenshots, one with dmenu and one with rofi:

« Last Edit: 21. March 2016, 21:59:10 by torvic9 »
i3: i7-5820K | 32 GB | GeForce GTX 960, nvidia | linux44-custom
KDE: i7-920 | 12 GB | GeForce GTS 450, nouveau | linux44
Gnome: Thinkpad X200s | linux41

Offline boruch

  • Jr. Mitglied
  • **
  • Posts: 85
  • Skill: Intermediate
@torvic9: Could you post a screenshot of morc_menu using an "application description" instead of an "application name"? If you feel like double-checking or possibly saving some time, first check the content of the .desktop file for the application - it may be using a 'dumbed-down' entry for its name parameter. If the "application description" you're noticing is "foo", then a command you can use to find the desktop file and its entry would be 'grep "foo" /usr/share/applications/*'.

Finally got around to do some basic testing.

morc_menu works with rofi, just use "rofi -dmenu" as menu_cmd in morc_menu's config file.

However, I lose the functionality to just type in the first letters of a given application. I can search the categories, but not the entries inside each category: if I type "aud", audacious doesn't show up. I first have to go to 'audio' sub-menu and only then can I enter "Aud". Same with dmenu instead of rofi.

morc_menu seems to look in the applications' descriptions, but not in the applications' names?

Here are two screenshots, one with dmenu and one with rofi:


Offline boruch

  • Jr. Mitglied
  • **
  • Posts: 85
  • Skill: Intermediate
However, I lose the functionality to just type in the first letters of a given application. I can search the categories, but not the entries inside each category: if I type "aud", audacious doesn't show up. I first have to go to 'audio' sub-menu and only then can I enter "Aud". Same with dmenu instead of rofi.

Was that functionality ever there, to be lost? Oh yes, I understand what you mean. The default dmenu command offers a single uncategorized list of ALL commands available on the system. Since it limits itself to displaying on only one line at the top the screen, the user only sees the first few of those items, but all are on that single list. Therefore, you can start typing and be sure that any GUI application or command line command will present itself. morc_menu is doing something else (at least, at this point). It's first sending only categories of applications, so the only choices you have is to navigate those categories.

Let me ask you, and anyone else reading - would it be useful to have a catch-all category, let's call it for now 'All', which would do what I think you were expecting? The downside is that you would still need to select a category, the 'All' category, so in order to save keystrokes, you might as well just invoke dmenu directly. I'm not sure what the up-side would be. Maybe just having a single keybinding to remember, or a single method of choosing an app. I don't mind adding that feature as an option.

Also, for everyone reading, I've received a request for an option to record and prominently display recently used commands and frequently used commands. Any opinions on the matter?