Keep rofi open after selection

[vedxyz]

I'm using a combi of [drun,run] as an app launcher, and especially when I need to launch multiple entries that I regularly need, it's a bit cumbersome to

1. Open rofi
2. Move to selection
3. Launch selection (rofi disappears)
4. Repeat from step 1

instead of

1. Open rofi
2. Move to selection
3. Launch selection (rofi stays open)
4. Repeat from step 2

I looked around but couldn't find an existing solution to achieve this behavior. Is this not possible at this time (in which case I might promote this to a feature request), or am I missing something?

Of course, I could achieve the end goal by using a non-rofi solution like scripting a bundle of apps to launch together, but I'd like to have my workflow go through a single pipeline (rofi) if I can help it.

If it's of any significance, my rofi version is 1.7.3.

Edit: for reference I should probably add what I had in mind, I wanted something like kb-accept-custom that would keep rofi open if used, where as the standard kb-accept would behave, well, as it currently does.

[DaveDavenport]

This is currently not supported. tbh i don't know of any launcher that does this.

[FabianUntermoser]

Well fzf supports multi-selection with the --multi flag.

[DaveDavenport]

rofi supports multi-selection in dmenu mode.. I am not sure what you are trying to contribute?

[adi1090x]

@DaveDavenport

I think you should implement this feature (atleast in dmenu mode)

Example: Let's say, I've created an applet which adjust the screen brightness. Now usually a user won't want rofi to disappear on each selection, Expected behavior should be, the user keep pressing enter and rofi should stay open until the user adjust the brightness according to his need, They he can press ESC to close the rofi window. (Same for volume applet or any other script that requires the same)

Maybe we can have an option in dmenu mode like : -stay-focused-on-selection

[DaveDavenport]

that has been fixed in git, there will be a follow up release in the next few days.
See #1679

[adi1090x]

Alright, I'm on Arch Linux So i guess it'll be fixed soon.

For the workaround, I've removed those options from the scripts.

Anyway, Keep doing the great work. I've created a lot of stuff using rofi (here) and the user interface in my Linux Distribution (Archcraft) is very much dependent on rofi (and rofi breaks it very often 😆).

Thank You.

[DaveDavenport]

It would help, if more people tested the development version before a release.
For me it is always playing catch-up with corner cases.

I try to keep breakage to a minimum, but often people use it in ways I do not expect and then new (requested) features break stuff.

[adi1090x]

I understand that.

I mean i use rofi for everything, from app launcher to powermenu to music player, to god knows what

I'd love to be a beta tester only if i had time, Archcraft keeps me very busy.

Anyway, No issues... I often find a workaround until the issue is fixed.

[DaveDavenport]

Same here, I hardly have time to work on things.

[focusaurus]

I also have a use case where this would be nice. I use rofi with the blezz mode as an application switcher with a modal tree of hotkeys. Because I run this to switch apps (example: "f10 then b" to switch to a browser), I need it to appear and have hotkeys bound very quickly. Sadly launching a new rofi process is just a little bit too slow and often my first hotkey is sent to the previous application instead of rofi where I intend it.

So, to work around that, I built a rofi-like TUI script that I keep running and on hotkey my window manager just moves it from an offscreen tag to the current tag which is instantaneous. Once it has done the action, it moves itself to the standby window manager tag to get out of the way, but it stays running the whole time.

I used to pre-spawn a rofi window and keep it on standby in the standby tag to solve this, but it creates some weird issues with keyboard focus when changing window manager tags that I haven't been able to troubleshoot.

[DaveDavenport]

Sadly launching a new rofi process is just a little bit too slow and often my first hotkey is sent to the previous application instead of rofi where I intend it.

Have you profiled rofi? see where this times is spend.. rofi here starts in ~200ms with many plugins on and in drun mode. Blezz is around 50ms.
It might be a good idea to find the cause, intead of working around the problem.

See the documentation on h ow to get timing traces, if you start a discussion on this forum, we can help analyze it.

[focusaurus]

OK I have a gist with timings. I'll start a new thread. But given I run this thing as my window switcher - so like all the dang time, I don't think keeping it running is "working around the problem" as opposed to "don't rerun processes and reread config files and themes every few seconds just for funzies".