I’d like terminal applications opened via rofi dmenu to use a terminal of my choice (termite), but I cannot seem to get them to open in anything but uxterm.
I’ve tried export TERMINAL=termite in my ~/.profile (most recently used to solve the same issue here, and setting the terminal field in .config/rofi/rofi.conf. Neither of these fixed things, but when I run i3-sensible-terminal it opens termite as expected.
I can probably hack the ranger.desktop file if needed, but I’d like to use the simpler, cleaner, wider reaching solution of $TERMINAL that has worked for others. Any ideas about why it isn’t working for me or what I can check to resolve the issues are greatly appreciated. Let me know if I can provide any more information, thanks.
I probably just misremembered this file path since I attempted this fix a long time ago and have since reverted it. I no longer have a rofi.rasi file in .config.
Did not know this, thanks. rofi-sensible-terminal finds $TERMINAL (termite in my case) with no problem, but rofi still opens ranger and htop in uxterm.
I use rofi -modi drun -show drun -config ~/.config/rofi/rofidmenu.rasi, which I think is from the stock i3 config of EOS. In my i3wm config I have it bound as bindsym o exec <that previous command>.
When I run the command from a terminal I get the rofi launcher as expected and launching ranger or htop puts it in termite (great!). However, rofi launched from i3 still puts ranger, htop, etc. in uxterm.
Why would I use direct rofi keybinding when I can use i3 to provide a seamless interface to all kinds of stuff? Also, using direct rofi keybindings probably wouldn’t work in my case anyway since I have a modal i3 config. Note that I bound rofi to “o” using i3, which probably wouldn’t go so well for direct rofi keybinding case (from my understanding).
Neither the keybinding (e.g Control-space) nor checking it (by rofi -h) is a command line as I understand it. The command line is “the line where commands go”, but is often used to refer to plain text terminal interfaces as a whole.
Definitions aside, the problem seems to be that an i3 call of rofi doesn’t give the same result as a direct command line call of rofi. This seems like the root problem to me, and I’d prefer to address or investigate it directly if possible.
Sorry, it was a mistake out of speed and (me-)multitasking.
Does it make sense, if I had (correctly) said “i3 has keybindings for this”?
I should have told you that I am not an i3 user, so I only know RTFM stuff and related forum topics.
Nevertheless, I use rofi with BSPWM, so I know enough about rofi.
I totally agree with your assessment.
Find the command line that i3 uses to start rofi and go from there.
If there is no setting about terminal in the theme file rofidmenu.rasi, or any other imported theme (default or other), then rofi should use x-terminal-emulator, which does not normally exist in Arch system/packages.
From man rofi:
-terminal
Specify which terminal to start.
rofi -terminal xterm
Pattern: {terminal}
Default: x-terminal-emulator
From man rofi-sensible-terminal
rofi-sensible-terminal [arguments]
rofi-sensible-terminal is invoked in the rofi default config
to start a terminal.
...
It tries to start one of the following (in that order):
• $TERMINAL (this is a non-standard variable)
• x-terminal-emulator
• urxvt
• rxvt
• st
• terminology
• qterminal
etc...
As you see, if there is nothing configured, defaults to x-terminal-emulator, if understood correctly.
If you set rofi-sensible-terminal as rofi terminal. then $TERMINAL is used, if it is set.
I have not confirmed this exact flow, but you have all the info I know, so make your own assessment .
Thanks for the extra detail, it has been very helpful.
Yeah, it’s the one I gave, and it still does different things from terminal and when bound in i3.
The rofi terminal flag looks like a quick way to fix this, providing an explicit terminal name here seems to give the desired behavior (thanks!).
However, providing ??-sensible-term to rofi’s terminal flag does not give the right behavior when bound to i3. I think it’s an i3 thing, since directly calling rofi-sensible-terminal or even i3-sensible-terminal using i3 bindings both totally ignore the $TERMINAL value I set in ~/.profile and open uxterm.
IIRC I had similar issues with env vars and BSPWM not reading them, so I used an extra script that would source SHELL’s dot files. It seems WMs don’t source them, unless specified in their autostart (bspwmrc in my case).
You might want to check how this is properly configured in i3 (check documentation, or ask support) .
In general, I think i3 is in that boat of not sourcing stuff, but I’m not sure how directly my issue is related to that fact.
The thing that really throws me is that the forum thread linked in my first post shows that using $TERMINAL in the .profile fixes the rofi terminal application issues (which is all I really want), but that fix doesn’t work for me. I’ve opened an i3 discussion and in the meantime using the rofi -terminal flag will be fine. Thanks again for the help.
You may have modified the default EnOS config files, so maybe lost the …defaults.
Try to add an autostart command in i3 config, that sources .profile (with a bash -c command, or running a script with the source command), even at the start of the file.
You may want to compare your current local config files, with /etc/skel/ ones, or with upstream package.
Considering the fix seems to work for other people I think you might be right about me ruining some helpful default somewhere.
I have looked at the upstream package and I don’t see anything substantially different related to autostarting, etc. I swapped back to the default config and restarted i3, but ranger still opened in xterm from rofi.
EnOS WM specific configurations are an attempt to make their sessions easily usable OOTB. It’s very good, but in some individual cases, you need to take the case in your own hands and do it the Arch way .
.
.
.