Use only Alt+Tab (without pressing Enter), like in kde
#38
Comments
|
Patch is welcome. |
|
+1 for this feature :) |
|
An option to always select the MRU (most recently used) window would already be a big step 👍 |
|
@sanderboom Probably better left to the wm in my opinion. |
|
@sanderboom isn't MRU already implemented in |
|
@roomcays for me the current active window is selected by default. If I want 'alt-tab-like' behavior, I have to press I did a quick test with |
|
@vyp The scenario I'd like to use rofi for is a 'cross workspace alt-tab'. Could probably be done using wm as well, although I think it would be a nice and non-intrusive addition to rofi. |
|
I see now what you're trying to achieve. Got the same behaviour. |
|
@roomcays thanks for the suggestion. In this case I'd need to use a second shortcut for this as I still want to be able to use rofi in different ways. That's why an option to preselect not the current but logical MRU item would be nice :) I'll experiment some more. |
|
@sanderboom Well yes, a non-cross workspace alt tab would be pretty limiting. Which window manager/de are you using? Been a long time since I've used a de, but most de's usually have some sort of alt-tab behaviour built in. Otherwise, even if you're using a non-ewmh wm, this should be pretty easy to achieve with wmutils. But I haven't tried it myself so I'm not sure. |
|
Now that we have on-release bindings (in master), it should be possible. I think I managed to work around the X11 limitation about already-down modifiers. To achieve that: |
Two nits:
|
|
Just tested this:
|
|
removed the delay. |
|
I manage to almost implement it (With a small tweak to select the second item of the list) #!/bin/bash
rofi \
-show window \
-kb-cancel "Alt+Escape,Escape" \
-kb-accept-entry "!Alt-Tab,Return"\
-kb-row-down "Alt+Tab,Alt+Down" \
-kb-row-up "Alt+Shift+Tab,Alt+Up"&
xdotool keyup Tab
xdotool keydown TabI just have 2 issues remaining:
|
|
Use Selecting the second row should be something done in the window mode, or at rofi’s global level. That would remove the need for your hack and the resulting Tab-still-down issue. :-) |
|
maybe I'm confused on what the |
@sardemff7 could you explain what you mean by this? |
|
To solve the tab key being held after Rofi is closed, I came up with the following: xdotool search --sync --class Rofi keyup --delay 0 Tab && xdotool key --delay 0 TabThis will wait for the Rofi window to open before executing the commands. Note that there is still a delay. Would love to see an official solution in Rofi. |
|
The fake Tab workaround is a “fix” for two things: First, just using Alt-Tab didn’t work in rofi. Now it does with a trick: have Second, not selecting the already-focused window. On this one, we cannot do much because the EWMH spec is not perfect and doesn’t give us a 100% sure order-of-last-focused. Would that work for you? @DaveDavenport are you fine with yet another option? :-) |
I've submitted a PR to resolve a long standing TODO in xdotool to make the delay configurable here: jordansissel/xdotool#238 That leaves me with the first release of Super_L having no effect if I have just pressed super+tab (plus the one fake tab from xdotool). I either have to press tab a second time before releasing super, or I have to tap super after releasing super, to get rofi to select and close |
Thanks to @sardemff7 for help on IRC. This seems to work exactly like the alt-tab that I am used to, as long as the window list is ordered by recent access which is outside rofi's control. |
|
I found the main bug preventing this feature. Once I find a fix, you can all finally drop your xdotool shady hacks. :-)
IOW, it is “merely” a matter of actually getting the proper event which is tied to the pointer focus (while being a keymap event…) |
rofi -show window -kb-accept-entry "!Super-Tab,!Super_L,!Super+Super_L,Return"
bash: !Super: event not foundMaybe single quotes were meant ? rofi -show window -kb-accept-entry '!Alt-Tab,!Alt_L,!Alt+Alt_L,Return' |
|
The key here is that the “doing nothing” (in theory, “switch to last focus”) Alt-Tab would be triggered by the |
|
with there was an error "no keysym found for binding '!Ctrl-Alt-Ctrl_L'. Removing this one, there is indeed a difference: when the mouse is where the rofi window will be, |
|
@sparr, thank you for you script. I found that if I use altdesktop/i3ipc-python#141 xdotool search --sync --syncsleep 50 --limit 1 --class Rofi \
keyup --delay 0 Alt+Tab \
keydown --delay 0 Alt+Tab \
&& test $(is-alt-pressed) == "false" \
&& xdotool search --limit 1 --class Rofi key --delay 0 Return&
cat /dev/stdin | rofi -dmenu -kb-accept-entry '!Alt-Tab,Return' -kb-row-down Alt-Tab" -kb-toggle-sort 'Alt-Ctrl-Shift-S' &Where is-alt-pressed code is: #include <X11/Xlib.h>
#include <X11/keysym.h>
#include <stdbool.h>
#include <stdio.h>
int main()
{
Display* dpy = XOpenDisplay(NULL);
char keys_return[32];
XQueryKeymap( dpy, keys_return );
KeyCode kcal = XKeysymToKeycode( dpy, XK_Alt_L );
bool bAltLPressed = !!( keys_return[ kcal>>3 ] & ( 1<<(kcal&7) ) );
KeyCode kcar = XKeysymToKeycode( dpy, XK_Alt_R );
bool bAltRPressed = !!( keys_return[ kcar>>3 ] & ( 1<<(kcar&7) ) );
printf(bAltLPressed || bAltRPressed ? "true" : "false");
XCloseDisplay(dpy);
} |
There is no delay if I seperate xdotool into two lines. |
|
The best solution of course is #909 Why it is not merged, it doesn't seem to do any harm if people dislike it not using it. |
Correct me if I am wrong, but I think even that wouldn't really solve the problem of pressing tab one additional time than normal window switchers. (Why? Because, it doesn't register "!Alt+Tab" unless you press and leave tab once!) |
|
I kinda dislike the end result here, I really want my rofi to come up opon Alt+Tab (using i3 conf) and lauch whatever option is tab or alt+tab is dropped. I also want it to start at result nr 2 that would have been the dream atleast :P |
Acually this solves most my problems with the solution, but I still have one issue. When running the script, sometimes I dropp the Alt+Tab so fast that rofi does not recognize it and therefore does not quit. All help would be appriciated |
|
@leier69 Have you tried #38 (comment)? That solution works very well for me. You'll only need to replace |
|
Thanks @DaveDavenport for cca9fa3, which enables I pushed a hack in the Could anyone here try this branch with the minimal command : If you’re really quick, it may not work, but I’m not sure we can do something about that, the X server doesn’t send us the event in the “correct” order for some reason in this case. |
|
Thanks for all the info in this issue! For some reason though, my window list is in a fixed order - not in MRU order. Is that expected? (Using i3) |
|
Yeah, I forgot one very important information : The order of windows is entirely WM-dependent, and there is nothing rofi can do about it without adding a whole bunch of WM-specific code, which will not happen. As for i3 specifically, with 4.16.1 (yeah I should update), the order is more or less what I’d expect. But it should be quite easy to use their focus-last example script, though it requires a daemon script to monitor all the changes. However, any ordering issue is outside the scope of rofi. Now that you can use |
|
If I understand properly, this is a fundamental issue with how X is designed? How does KDE / other app-switchers do it? I am not sure. |
|
If you’re talking about the ordering issue, please stop. Anything integrated with a DE or WM will have DE/WM-specific code for that. rofi is a 100% generic tool, relying solely on EWMH and ICCCM standards. Specifically “Alt-Tab switchers” are commonly implemented directly in a DE or designed for one DE only. If you have an example of a switcher with purely generic code that happens to work everywhere, please share, hopefully it’s open source and we can reuse some of its logic. If you’re talking about the binding issue, it’s actually pretty much the same. Anything more integrated than rofi will probably use specific tricks. We could change the binding handling a tiny bit (though it would be a pretty big code change) to react on “key up” events even if we didn’t see the “key down” event but it’s pretty much the only use case where it would makes sense, and IMO would lead to unexpected bindings triggering in all other cases. |
|
I am not talking about the ordering issue, don't worry. Apologies for not making that clear. I know you can easily change that on Xmonad in fact. Yes, I was thinking that it had to be more directly integrated with the DE itself, hence probably why this issue has been open for around 6 years now. I meant to ask if it was easy to detect such a "key-up" event / what the biggest obstacle is. |
|
FWIW, I 'fixed' the mouse bug #38 (comment) by moving the mouse into the rofi window and back, using xdotool. #!/usr/bin/env bash
set -euo pipefail
LOGFILE=""
ROFI_ARGS=()
KB_ACCEPT_APPEND=""
MODE=""
while getopts "m:l:" OPTION; do
case "$OPTION" in
m)
MODE="$OPTARG"
case "$MODE" in
alttab)
ROFI_ARGS+=( -show window -selected-row 1) # -selected-row is only available in https://github.com/davatorium/rofi/pull/909
KB_ACCEPT_APPEND=",!Alt+Alt_L"
;;
altspace)
ROFI_ARGS+=( -show window )
;;
superspace)
ROFI_ARGS+=( -show drun )
;;
*)
echo "unknown mode $MODE";
exit 1 # todo use libnotify to display error
;;
esac
;;
l)
LOGFILE="$OPTARG"
;;
*)
echo "unknown option '$OPTION'"
exit 1
;;
esac
done
if [ "$MODE" == "" ]; then
echo "must specify a mode"
exit 1
fi
if [ "$LOGFILE" != "" ]; then
echo "redirecting output to file"
exec >> "$LOGFILE"
exec 2>&1
fi
# launch rofi
export ROFI_DUMP_WINDOW_POSITION="$(mktemp)" # see below
rofi \
-kb-cancel "Alt+Escape,Escape" \
-kb-accept-entry '!Alt-Tab,!Alt+Down,!Alt+ISO_Left_Tab,!Alt+Up,Return'$KB_ACCEPT_APPEND \
-kb-row-down 'Alt-Tab,Alt+Down,Down' \
-kb-row-up 'Alt+ISO_Left_Tab,Alt+Up,Up' \
"${ROFI_ARGS[@]}"&
rofipid="$!"
# The following Strategies move the mouse into the rofi window and back to where it came from.
# (this is a work around for https://github.com/davatorium/rofi/issues/38#issuecomment-469064051 )
# Strategy 1
#echo "move mouse to center screen (best effort, fast because we avoid the search)"
#xdotool mousemove 960 540 sleep 0.1 mousemove restore
# Strategy 2
#echo "move mouse to rofi center (precise, but slow due to search and fails sometimes)"
#(
# source <(xdotool search --sync --limit 1 --pid "$rofipid" --class Rofi getwindowgeometry --shell)
# xdotool mousemove $X $Y sleep 0.1 mousemove restore
#)
# Strategy 3
# diff --git a/source/view.c b/source/view.c
# index 5ba1309a..11d98840 100644
# --- a/source/view.c
# +++ b/source/view.c
# @@ -411,6 +411,15 @@ static void rofi_view_calculate_window_position ( RofiViewState *state )
# RofiDistance y = rofi_theme_get_distance ( WIDGET ( state->main_window ), "y-offset", config.y_offset );
# state->x += distance_get_pixel ( x, ROFI_ORIENTATION_HORIZONTAL );
# state->y += distance_get_pixel ( y, ROFI_ORIENTATION_VERTICAL );
# +
# + // dump position to file if desired
# + const char *dump_file_path = getenv("ROFI_DUMP_WINDOW_POSITION");
# + static FILE *dump_file = NULL;
# + if (dump_file_path) {
# + if (!dump_file) dump_file = fopen(dump_file_path, "w");
# + fprintf(dump_file, "X=%d\nY=%d\nWIDTH=%d\nHEIGHT=%d\n", state->x, state->y, state->width, state->height);
# + fflush(dump_file);
# + }
# }
#
# static void rofi_view_window_update_size ( RofiViewState * state )
(
while test ! -e $ROFI_DUMP_WINDOW_POSITION || test $(wc -l "$ROFI_DUMP_WINDOW_POSITION" | awk '{print $1}') -lt 4 ; do sleep 0.05; done
source "$ROFI_DUMP_WINDOW_POSITION"
xdotool mousemove $X $Y sleep 0.1 mousemove restore
)
rm "$ROFI_DUMP_WINDOW_POSITION"
wait "$rofipid"
|
|
The patch from master needs to be merged or it doesnt work |
|
@duckie Thank you a lot for testing I’ve pushed the fixes to the |
|
The fix as it is in the |
|
I guess the current |
Whoa! Are you sure? Please, can you tell me how you do this? When I invoke |
Hi ; may I ask, what could cause the window list to be ordered by recent access? |
|
Rofi doesn’t control the order at all see #38 (comment) If people don’t read the full issue (yes it’s quite a chunk of text but it does contain useful information) I’ll have to lock the issue to keep the unecessary repetitions to a minimum. |
|
Thank you for your answer, @sardemff7 I totally get it, ordering the windows by age is definetely not Rofi's job, and your documentation makes this very clear, no PB, I was just enquiring about ways to do that (I guess I wasn't very clear myself, sorry about that) in fact this is probably my new pet project, I want to write that "WM-agnostic window switcher for Xorg" that you mentioned previously, maybe using something like wmctrl. Just a quick question : were I to use Rofi to display the menu / list of open windows, could it
The 1st point is easily done ; I suppose that the 2nd point could depend on how the WM is handling KB input, in which case let's say "in i3"? And for the 3rd point, I apologize if I didn't find it in the docs: how can I specify a custom action to be done on enter? I understand I can do it "on the fly" with Rofi's KB shortcuts but can I also script it to redefine enter to do just that? Thanks for your patience, as most of this MSG is not really about Rofi 👍 |
|
The whole point of this issue is to support that, and it should work by now, but we have limited testing. Please re-read everything here, the exact answer is here somewhere. If you want to discuss non-rofi matters, at least please do that on IRC, you can come to #rofi or really any WM channel, to find people that would help. |
|
I second this. |
|
To make it clear the feature is implemented, let’s close this issue. Patches to add a documented example are welcome. |
and others
It would be nice to use only
Alt+Tab(without pressing Enter) to change the focus.The proposed method would change the focus when
Altis not longer pressed. Once the menu is displayed,Alt+Tabcan be used to go to the item in the menu (observe that actually onlyTabis pressed again sinceAltis continuously pressed). AndAlt+Shift+Tabfor the previous item. In order to cancel,ESCcan be used (while pressingAlt). This is the default behavior in kde, for example.I believe it is faster and uses less hand movements.
The text was updated successfully, but these errors were encountered: