Yet another start menu

o9000 · 2017-04-07 09:32:45

Applications installed in $HOME are installed from source, not by the package manager. So the hook won't be executed.

ohnonot · 2017-04-07 19:30:05

archlinux pacman hooks definitely work in the desired manner:

i can define a custom hook that is run after each un/install and update
the update process, and so also the hook, runs as superuser
the hook calls a script that calls e.g. 'sudo -u ohnonot fbmenugen'
so menu generation is executed as a normal user and will pick up menu entries both in /usr/share as well as in ~/.local/share

my question was if hooks like that can be designed for apt.

Last edited by ohnonot (2017-04-07 19:33:03)

o9000 · 2017-04-08 17:10:53

johnraff wrote:

Is it possible to add an option for a menu without icons? (but still dynamically checking the .desktop files)

I've added an option to support this. Although I'd rather optimize by caching the icon/menu lookups instead of turning them off. Personally I don't like menus without icons.

It still has some quirks. @malm has pointed out that I do not handle correctly .desktop files that contain Terminal=true (for example midnight commander). That would require knowing which terminal to run (or a generic symlink to whatever the user has configured). I suppose there is a way to get that on BL, but I'm not sure how and if it works on other distros.

o9000 · 2017-04-09 12:13:30

Thanks. "x-terminal-emulator -e '...'" works just fine in debian-based distros. I will stick to this, since it's a simple yet elegant way of setting the default terminal.

PackRat · 2017-04-17 14:39:05

Anyone trying to launch pmenu.py from a key binding?

I've been trying it with tiling winodw managers (spectrwm and i3) as well as fluxbox in Void Linux, and it's erratic; launching it from a terminal or dmenu always works though.

ps_mem (screenshot) and htop show several instances (the python 2.7) of it running, but the menu doesn't display:

Maybe it's an incompatibility in Void.

o9000 · 2017-04-17 14:51:23

Does it work when started as: sh -c 'pmenu.py 1>/dev/null 2>/dev/null' ?

PackRat · 2017-04-17 15:09:35

Not from a key binding.

Does work in a terminal.

o9000 · 2017-04-17 15:17:13

From openbox it seems to work properly, at least on my machine. It might be helpful to run it as:

sh -c 'pmenu.py 1>>~/pmenu.log 2>>~/pmenu.log'

then trigger the fail. In that case pmenu.log should contain a stack trace, if pmenu has crashed. Assuming that's the problem.

Edit: fix typo in command

Last edited by o9000 (2017-04-17 15:24:40)

PackRat · 2017-04-17 16:40:26

pmenu.log

** (process:1765): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:1765): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:1765): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
sh: 1: pmenu.py: not found
sh: 1: pmenu.py: not found

The first 3 entries are from running the command in a terminal. The last two are from the keybinding.

Edit -

If I use the full path

/home/<user>/bin/pmenu.py 1>>~/pmenu.log 2>>~/pmenu.log

It appears to work. I'll test more after I pick up the kids from school.

Last edited by PackRat (2017-04-17 16:43:22)

o9000 · 2017-04-17 16:43:36

It is quite simple: it's not in $PATH (the environment variable value as seen by the WM). If you enter the full path (you can obtain it with which pmenu.py), it should work.

PackRat · 2017-04-17 18:52:21

Thanks

It's working now with any window manager.

PackRat · 2017-04-17 19:47:04

o9000 wrote:

It is quite simple: it's not in $PATH (the environment variable value as seen by the WM). If you enter the full path (you can obtain it with which pmenu.py), it should work.

It doesn't work from either /usr/bin or /usr/local/bin unless I use the full path. Other scripts don't require the full path.

PackRat · 2017-04-17 22:18:58

Thanks.

Head_on_a_Stick · 2017-04-17 22:52:21

PackRat wrote:

Anyone trying to launch pmenu.py from a key binding?

Works for me under OpenBSD -current with dwm:

static const char *pmenucmd[]  = { "pmenu.py", NULL };
static Key keys[] = {
        { MODKEY|ShiftMask,             XK_p,      spawn,          {.v = pmenucmd } },
};

The pmenu.py script is in ~/bin and $PATH is set in ~/.profile thusly:

PATH="$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:/usr/local/jdk-1.8.0/jre/bin:."

The shell is ksh(1) for both logins and interactive use.

Last edited by Head_on_a_Stick (2017-04-17 22:56:08)

PackRat · 2017-04-18 02:09:35

^ thanks

I dug a little deeper and found that my ~/.profile was messed up. Fixing that up now.

o9000 · 2017-04-18 19:19:43

I don't know anything about fluxbox, but I think "killall fluxbox" is a bit extreme for logging out. Apparently this could be done via fluxbox-remote, but it needs to be turned on: http://fluxbox.org/help/man-fluxbox-remote.php http://www.linuxquestions.org/questions … ox-864919/

Maybe it would make sense to make pmenu load JSON menu contents from a file? Maybe with options like --prepend, --append and --merge? This way it wouldn't have to be forked for any little change. But I would have to figure out how to deal with translations (or maybe it's not necessary?)

Last edited by o9000 (2017-04-18 19:20:27)

ohnonot · 2017-04-19 05:05:55

o9000 wrote:

I don't know anything about fluxbox, but I think "killall fluxbox" is a bit extreme for logging out.

it sounds extreme but really it just sends TERM to the process.
i would, however, try to use kill instead of killall.
i saw some script use this:

kill -s USR1 `xprop -root _BLACKBOX_PID | awk \'{print $3}\'`

(yes, for fluxbox).

o9000 · 2017-04-19 08:05:49

ohnonot wrote:

o9000 wrote:
I don't know anything about fluxbox, but I think "killall fluxbox" is a bit extreme for logging out.
it sounds extreme but really it just sends TERM to the process.

I guess it would have been extreme if killall sent Terminator after the process. But that may have been overkill.

PackRat · 2017-04-30 15:28:31

o9000 wrote:

I don't know anything about fluxbox, but I think "killall fluxbox" is a bit extreme for logging out. Apparently this could be done via fluxbox-remote, but it needs to be turned on: http://fluxbox.org/help/man-fluxbox-remote.php http://www.linuxquestions.org/questions … ox-864919/
Maybe it would make sense to make pmenu load JSON menu contents from a file? Maybe with options like --prepend, --append and --merge? This way it wouldn't have to be forked for any little change. But I would have to figure out how to deal with translations (or maybe it's not necessary?)

That's a bit of a security flaw because it will open up fluxbox to other remote commands not related to the window manager.

I have pmenu.py working now OOTB.

Last edited by PackRat (2017-04-30 15:29:00)

#21 2017-04-07 09:32:45

Re: Yet another start menu

#22 2017-04-07 19:30:05

Re: Yet another start menu

#23 2017-04-08 17:10:53

Re: Yet another start menu

#24 2017-04-09 12:13:30

Re: Yet another start menu

#25 2017-04-17 14:39:05

Re: Yet another start menu

#26 2017-04-17 14:51:23

Re: Yet another start menu

#27 2017-04-17 15:09:35

Re: Yet another start menu

#28 2017-04-17 15:17:13

Re: Yet another start menu

#29 2017-04-17 16:40:26

Re: Yet another start menu

#30 2017-04-17 16:43:36

Re: Yet another start menu

#31 2017-04-17 18:52:21

Re: Yet another start menu

#32 2017-04-17 19:47:04

Re: Yet another start menu

#33 2017-04-17 22:18:58

Re: Yet another start menu

#34 2017-04-17 22:52:21

Re: Yet another start menu

#35 2017-04-18 02:09:35

Re: Yet another start menu

#36 2017-04-18 19:19:43

Re: Yet another start menu

#37 2017-04-19 05:05:55

Re: Yet another start menu

#38 2017-04-19 08:05:49

Re: Yet another start menu

#39 2017-04-30 15:28:31

Re: Yet another start menu

Board footer