You are not logged in.

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

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Yet another start menu

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

Offline

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

ohnonot
...again
Registered: 2015-09-29
Posts: 5,592

Re: Yet another start menu

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)

Offline

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

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Yet another start menu

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.

Offline

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

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Yet another start menu

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.

Offline

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

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 2,660

Re: Yet another start menu

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:

scrot-shot-mon171492439147.jpg

Maybe it's an incompatibility in Void.


You must unlearn what you have learned.
    -- yoda

Offline

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

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Yet another start menu

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

Offline

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

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 2,660

Re: Yet another start menu

Not from a key binding.

Does work in  a terminal.


You must unlearn what you have learned.
    -- yoda

Offline

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

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Yet another start menu

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)

Offline

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

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 2,660

Re: Yet another start menu

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)


You must unlearn what you have learned.
    -- yoda

Offline

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

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Yet another start menu

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.

Offline

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

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 2,660

Re: Yet another start menu

Thanks

It's working now with any window manager.


You must unlearn what you have learned.
    -- yoda

Offline

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

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 2,660

Re: Yet another start menu

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.


You must unlearn what you have learned.
    -- yoda

Offline

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

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 2,660

Re: Yet another start menu

Thanks.


You must unlearn what you have learned.
    -- yoda

Offline

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

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 9,093
Website

Re: Yet another start menu

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)

Offline

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

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 2,660

Re: Yet another start menu

^ thanks

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


You must unlearn what you have learned.
    -- yoda

Offline

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

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Yet another start menu

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)

Offline

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

ohnonot
...again
Registered: 2015-09-29
Posts: 5,592

Re: Yet another start menu

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).

Offline

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

o9000
tint2 developer
From: Network Neighborhood
Registered: 2015-10-24
Posts: 417
Website

Re: Yet another start menu

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.

Offline

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

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 2,660

Re: Yet another start menu

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)


You must unlearn what you have learned.
    -- yoda

Offline

Board footer

Powered by FluxBB