Giters

open-dynaMIX / raiseorlaunch

A run-or-raise-application-launcher for i3 window manager.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Window cycling

petobens opened this issue · comments

commented

From #15:

I have now the following in my config file:

set $nexec exec --no-startup-id
bindsym $mod+Control+p $nexec raiseorlaunch -c Zathura -e \
    "--no-startup-id i3-msg workspace "2" && zathura"

Now imagine that I have 3 Zathura windows opened: 2 in workspace "2" and 1 in workpsace "1". If run the binding then raiseorlaunch will switch focus between the 2 windows in workspace 2 and ignore the one in workspace 1. Is it possible to also include the window in workspace 1 when cycling?

commented

I have a similar (albeit opposite) question/request. In my config I have the following two mappings:

set $nexec exec --no-startup-id
bindsym $mod+Control+i $nexec --no-startup-id raiseorlaunch -c Chromium -e \
    "--no-startup-id i3-msg workspace $ws1 && chromium"
bindsym $mod+Control+a $nexec raiseorlaunch -c Chromium -e \
    "--no-startup-id i3-msg workspace $ws1 && chromium --new-window https://calendar.google.com/calendar/r" -m cal

If I press the calendar map repeatedly, $mod+Control+a then raiseorlaunch will always focus the Chromium Calendar window. However if I press repeatedly the chromium map, $mod+Control+i then I will switch back and forth between the standard Chromium browser window and the calendar window (because the Calendar mapping is has the class flag -c Chromium). Is there a way to avoid this?
Thanks in advances and sorry for being such a nuisance.

commented

The reason for this is, with following bindsym

bindsym $mod+Control+a $nexec raiseorlaunch -c Chromium -e \
    "--no-startup-id i3-msg workspace $ws1 && chromium --new-window https://calendar.google.com/calendar/r" -m cal

you are telling raiseorlaunch to focus the window based on the con_mark cal. The window properties (-c Chromium) are only used when running the application, to set the con_mark on the right window.

So a solution would be to use a con_mark for the other chromium window as well. Something like that:

bindsym $mod+Control+i $nexec --no-startup-id raiseorlaunch -c Chromium -e \
    "--no-startup-id i3-msg workspace $ws1 && chromium" -m browser

Without this, the only possibility for raiseorlaunch to match the window is the window class (-c Chromium), which matches to both windows.

Be careful though: When triggering those bindsyms directly after each other, you could run into a race condition, resulting in having the wrong con_marks set for the windows. To prevent that, you could specify more (and importantly unique) window properties than just wm_class. On the other hand, if you find consistent and unique window properties for each window, there would be no need to set con_marks at all (given you don't need them for anything else).

commented

Excellent explanation :) Thanks!!

commented

A first implementation of this can be found in the develop branch. There is a new -C/--cycle switch.

Beware: If you use -w $workspace, it will just cycle through the matching windows on that workspace.

As I will probably not use this feature myself, it would be nice, if you could provide some feedback.

commented

I''ve been using this for a few days and seems to work great. Thanks :)