Hey,

I have created an Arch User Repository (AUR) package for this repository under the name sway-overfocus. Software from the AUR is very convenient to install for users of the pacman package manager (which is the default for Arch Linux and Manjaro) over an installation from source. The package currently tracks the 0.2.3 version, as given by the tag. Feel free to add a mention to this package to the README if you would like.

Note: While creating the package, I noticed that the package versions for sway-overfocus differ in the Cargo.toml (0.2.3) and Cargo.lock (0.2.2) files. I currently circumvent this issue in the build process by using sed to adjust the version in the lockfile. Please let me know if this intended or if you plan to fix this discrepancy.

In case you never heard of the AUR, let me quote from the Arch Linux wiki:

The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions that allow you to compile a package from source with makepkg and then install it via pacman. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the community repository.

In case you have any questions or concerns, or would like me to take the package down, please let me know. Thank you for providing this great piece of software!

Hiya! Found this via that sway ticket & loving it, great work.

This request is probably going to seem esoteric but would it be possible to make the order in which the movement arguments were specified semantically significant?

My use case is essentially this (paraphrased):

bindsym [hjkl] exec sway-overfocus group-[ldur]w split-[ldur]w
bindsym Shift+[hjkl] exec sway-overfocus split-[ldur]w group-[ldur]w

So, because I have a layout that frequently ends up as alternations of tab > split > tab > sometimes split, what I'm after is for my basic hjkl movements to move group-wise if the focus is within a tabbed/stacked container, and split-wise if it's not (so, how it works currently). However, I would like, when I shift the keys, for the behaviour to be the exact opposite, where it will move split-wise when the focus is in a tabbed/stacked container, and tab-wise when it's in a split, which for me essentially has the effect of moving containers at the parent level instead of the focus level.

However, at the moment, unless I've set something up incorrectly, it would appear that both of those commands do the same thing, which I'd assume would mean the order of arguments is not taken into account.

My setup is: External monitor with pos: 0,0 Laptop monitor with pos: 3840,0 My external monitor is physically positioned to the left of my laptop.

The original focus command in sway allows me to

1. Have focus in a window/container on my laptop-screen
2. Press mod+Left
3. Get focus on a window on my external monitor (positioned to the left of my laptop both virtually and physically)

sway_bfocus does not transcend desktop boundaries.

If the aim is to replace the focus command, all "active desktops", i.e. those that are currently displayed, should be taken into account when switching focus.

The README states that Cargo 1.58 or newer is required to build, but the project doesn't build with Cargo 1.58. See the output below.

> cargo build --release
error: failed to parse manifest at `/home/mads/dev/sway-overfocus/Cargo.toml`

Caused by:
  feature `strip` is required

  The package requires the Cargo feature called `strip`, but that feature is not stabilized in this version of Cargo (1.58.0 (f01b232bc 2022-01-19)).
  Consider trying a newer version of Cargo (this may require the nightly release).
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-strip-option for more information about the status of this feature.

If the target window has no title, sway-overfocus fails.

$ sway-overfocus split-lw float-lw
error: no valid focus command

The window that should be the target (notice name is null):

{
  "id": 63,
  "type": "con",
  "orientation": "none",
  "percent": 0.3319633259563705,
  "urgent": false,
  "marks": [],
  "focused": true,
  "layout": "none",
  "border": "pixel",
  "current_border_width": 4,
  "rect": {
    "x": 2154,
    "y": 18,
    "width": 1050,
    "height": 1668
  },
  "deco_rect": {
    "x": 0,
    "y": 0,
    "width": 0,
    "height": 0
  },
  "window_rect": {
    "x": 4,
    "y": 4,
    "width": 1042,
    "height": 1660
  },
  "geometry": {
    "x": 0,
    "y": 0,
    "width": 500,
    "height": 500
  },
  "name": null,
  "window": 6291457,
  "nodes": [],
  "floating_nodes": [],
  "focus": [],
  "fullscreen_mode": 0,
  "sticky": false,
  "pid": 3670786,
  "app_id": null,
  "visible": true,
  "max_render_time": 0,
  "shell": "xwayland",
  "inhibit_idle": false,
  "idle_inhibitors": {
    "user": "none",
    "application": "none"
  },
  "window_properties": {
    "transient_for": null
  }
}

If I forcefully set a name with xprop, sway-overfocus works as expected:

$ xprop -id 6291457 -set WM_NAME test
$ sway-overfocus split-lw float-lw
[
  {
    "success": true
  }
]

Currently, floating containers are simply ignored, so trying to change focus from one does nothing.

Since they are only present in workspace containers, we should be able to get basic support by reforming the top nodes of the tree. It might be challenging to support proper directional movement.

Currently I cycle through tabs with bindsym $mod+Tab exec sway_bfocus tabbed forward cycle

However, I sometimes stack my windows instead of tabbing them.

Is it possible to make the cycling tab/stack agnostic?

Bumps regex from 1.5.4 to 1.5.6.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

The following doesn't work in my config

set $i3_scripts ~/.config/i3/scripts
bindsym $mod+w exec '$i3_scripts/sway-overfocus split-li group-lw'
bindsym $mod+e exec '$i3_scripts/sway-overfocus split-ri group-ri'

whereas this works:

set $i3_scripts ~/.config/i3/scripts
bindsym $mod+w exec $i3_scripts/sway-overfocus split-li group-lw   # Remove single quotes
bindsym $mod+e exec $i3_scripts/sway-overfocus split-ri group-ri   # Remove single quotes

Maybe change README to address this?

The program runs for sway in 5-15ms on my system, which is acceptable. It takes 30-50ms in i3 however.

The vast majority of time is spent running the swaymsg/i3-msg commands, while parsing and searching takes less than 1ms. Maybe doing IPC directly would be significantly faster?

When a container is fullscreened, the containing workspace should be treated as simply holding that container alone. Currently, containers are always focused as though nothing is full-screen.

It'd be nice to support moving containers using the same logic they are focused with.

My initial idea is that sway_bfocus move <targets> should find the container that would be focused, then place the currently focused container right before or after it. This wouldn't be as powerful as the builtin directional movement, but it would be more consistent. The lacking functionality could then be achieved with an additional move to parent command.