bug: Moving windows via kbd shortcuts is janky

[Cushee-Foofee]

Description

When moving windows, or even just moving the selection (Active highlight) of windows, the movement may be broken.

Problem Explanation

When moving the active highlight, I noticed that going clockwise (Right, Down, Left, Up) for a 2x2 window setup, it works fine, but when I reverse direction for counter-clockwise, then all of a sudden it only moves between two windows in the opposite corners. (Duplicate of/tracking on #171)

Also, when I am actually moving the windows with the hotkeys (Shift+Super+Arrow), the window may not properly move. For example, in 2x2, I may move a window up, but it doesn't move, or it just moves right and makes a 1x3 or 1x4 configuration instead. Screencast from 2023-04-30 18-47-13.webm

Lastly, with 2 monitors, sometimes movement will not work across them. Kind of like a one way mirror, I may be able to move the acive highlight, or even just move a window to the right side, but I cannot access the left side without alt+tabbing, using my mouse, or some other method. In the screenshot, if I accidentally active highlight the settings pop-up window, I cannot access any other window or move any window with forge's hotkeys. (need a separate ticket)

Expected Behavior

I expect the highlight to properly move based on shortcut input.

I expect windows to move based on the direction, not randomly half the time. I also expect the movement to be able to create proper configurations, not simplifying.

I also expected movement and highlights to work both ways for multi-monitor setups.

Details

• [X] Yes, it applies to any application.

It happens only on one computer?

• [X] I don't know.

It happens only with some specific gnome configuration?

• [X] I don't think that the configuration matters.

It happens only with some specific extension installed?

• [X] I don't think that the installed extensions affect the bug/behavior.

Diagnostics

Environment

• Distro version: Linux fedora 6.2.13-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 27 01:33:30 UTC 2023 x86_64 GNU/Linux
• GNOME Shell version: GNOME Shell 44.1
• Forge source: Extensions.gnome.org
• Forge version: 44.1-67

Display Setup

Displays:

1. 2 x 1080p
2. Dual monitor horizontal orientation

Screenshots

Extension Configuration

auto-split-enabled=false css-last-update=uint32 37 css-updated='1682888403680' dnd-center-layout='tabbed' float-always-on-top-enabled=false focus-border-toggle=false preview-hint-enabled=false stacked-tiling-mode-enabled=false tabbed-tiling-mode-enabled=false tiling-mode-enabled=true window-gap-hidden-on-single=false window-gap-size=uint32 4 window-gap-size-increment=uint32 1 workspace-skip-tile='1'

[keybindings] window-focus-down=['Down'] window-focus-left=['Left'] window-focus-right=['Right'] window-focus-up=['Up'] window-move-down=['Down'] window-move-left=['Left'] window-move-right=['Right'] window-move-up=['Up']

Enabled Extensions

transparent-top-bar@ftpix.com Name: Transparent Top Bar (Adjustable transparency) Description: Fork of: https://github.com/zhanghai/gnome-shell-extension-transparent-top-bar

Bring back the transparent top bar in GNOME Shell with adjustable transparency.

Does not work well with custom shell themes. Path: /home/buncomputer/.local/share/gnome-shell/extensions/transparent-top-bar@ftpix.com URL: https://github.com/lamarios/gnome-shell-extension-transparent-top-bar Version: 15 State: ENABLED

Resource_Monitor@Ory0n Name: Resource Monitor Description: Monitor the use of system resources like cpu, ram, disk, network and display them in gnome shell top bar. Path: /home/buncomputer/.local/share/gnome-shell/extensions/Resource_Monitor@Ory0n URL: https://github.com/0ry0n/Resource_Monitor/ Version: 19 State: ENABLED

forge@jmmaranan.com Name: Forge Description: Tiling and window manager for GNOME

Please report bugs/issues on https://github.com/jmmaranan/forge/issues Path: /home/buncomputer/.local/share/gnome-shell/extensions/forge@jmmaranan.com URL: https://github.com/jmmaranan/forge Version: 67 State: ENABLED

vertical-workspaces@G-dH.github.com Name: V-Shell (Vertical Workspaces) Description: Customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically stacked workspaces.

Dear users, the reliability and stability of this extension is my priority, if you encounter any problem, first check for conflicts with other extensions and then open an issue on the Github page linked below. Any feedback is greatly appreciated.

V-Shell features:

• vertical or horizontal orientation of workspaces
• customize the overview layout, dimensions and contents
• alternative overview modes with static workspace preview that reduces unnecessary movement on the screen
• wallpaper background with adjustable blur effect in the overview
• dash icon size, content, icon click and scroll behavior
• app grid dimensions, icons size, contents and behavior
• active icons in the folder preview
• close workspace button on workspace thumbnail
• main panel position and visibility
• hot corner/edge position and behavior
• notifications, OSD and workspace switcher popup position
• custom window attention handler behavior
• improved app search provider with custom icon size
• window search provider for quick navigation between windows
• recent files search provider
• static background in the workspace switcher animation outside of the overview
• workspace switcher popup appears even when switching workspace with a gesture
• 4 predefined profiles with different layout and behavior that can be overwritten by your settings
• fixes (works around) several upstream bugs (known and reported)
• modular structure of the V-Shell allows you to disable modules that you don't need or conflicts with other extension that you like better for the task Path: /home/buncomputer/.local/share/gnome-shell/extensions/vertical-workspaces@G-dH.github.com URL: https://github.com/G-dH/vertical-workspaces Version: 29 State: ENABLED

Graphics information

-display
description: VGA compatible controller product: TU116 [GeForce GTX 1650 SUPER] vendor: NVIDIA Corporation physical id: 0 bus info: pci@0000:09:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: vga_controller bus_master cap_list rom configuration: driver=nvidia latency=0 resources: irq:117 memory:f6000000-f6ffffff memory:e0000000-efffffff memory:f0000000-f1ffffff ioport:e000(size=128) memory:f7000000-f707ffff -graphics product: EFI VGA physical id: 3 logical name: /dev/fb0 capabilities: fb configuration: depth=32 resolution=1920,1080

Monitor information

Screen 0: minimum 16 x 16, current 3840 x 1080, maximum 32767 x 32767 XWAYLAND0 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 520mm x 290mm supported: 0, 1 1920x1080 59.96+ XWAYLAND1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 480mm x 270mm supported: 0, 1 1920x1080 59.96+

Extra

I know I have talked about some bugs before, but I just wanted to say personally, I appreciate all the work and effort you have put into this extension.

Forge has allowed me to easily get window tiliing while also having a more normal Linux experience on Fedora. Even with some weird wonky bugs, Forge has improved my experience so much.

Thank you! <3

[jmmaranan]

Hi @Cushee-Foofee - thanks for the report, the highlight issue seems to be a duplicate of #171. FWIW, I did not implement the last focus indicator when user suddenly focuses back. But basically this is how I think i3 behaves. Since this extension is based on i3 but some logic has diverged.

However, the move-window API being wonky I know is a bug on Wayland but not X11. Are you in Wayland by any chance? If so, I'll use this ticket for the move-window API issue.

[Cushee-Foofee]

Hi @Cushee-Foofee - thanks for the report, the highlight issue seems to be a duplicate of #171. FWIW, I did not implement the last focus indicator when user suddenly focuses back. But basically this is how I think i3 behaves. Since this extension is based on i3 but some logic has diverged.

However, the move-window API being wonky I know is a bug on Wayland but not X11. Are you in Wayland by any chance? If so, I'll use this ticket for the move-window API issue.

Yes, I am on Wayland.

Also, that bug report doesn't talk about the hotkeys not changing the highlight back to the other side.

[jmmaranan]

@Cushee-Foofee - do you have a screen cast of the highlight issue?

The data structure for Forge is using left-right, top-bottom list of nodes. When you move forward on any orientation it moves to the next sibling. When you move backward it goes to the previous sibling, if any of the siblings is a container, if previous, it focuses on the tail end. If it is forward, it focuses on the head.

In the case that you have:

[A] [B / C]

And if current focus is on A, if you move to B/C, it focuses to the head which is B. In case you have:

[B / C] [A]

And if focus still on A, when you move to B/C it focuses on the tail which is C

Forge is missing to remember the previous focus. When it was on B (on group B/C) and it moves to A (in any of the above cases) and you go back to B/C, that it was previously on B. So focus need to go to B. If none of the previous indicator is set, it will follow the head/tail logic

[Cushee-Foofee]

@Cushee-Foofee - do you have a screen cast of the issue?

The data structure for Forge is using left-right, top-bottom list of nodes. When you move forward on any orientation it moves to the next sibling. When you move backward it goes to the previous sibling, if any of the siblings is a container, if previous, it focuses on the tail end. If it is forward, it focuses on the head.

In the case that you have:

[A] [B / C]

And if current focus is on A, if you move to B/C, it focuses to the head which is B. In case you have:

[B / C] [A]

And if focus still on A, when you move to B/C it focuses on the tail which is C

Forge is missing to remember the previous focus. When it was on B (on group B/C) and it moves to A (in any of the above cases) and you go back to B/C, that it was previously on B. So focus need to go to B. If none of the previous indicator is set, it will follow the head/tail logic

Originally I tried recording with OBS, but for some reason even though my mouse cursor moves in perfect 60 FPS, forge's highlights either lag or sometimes doesn't show up at all on the recording when switching between windows. I can take a video showing what it looks like by clicking with the mouse, although it would technically be incorrect as the problem is with the hotkeys, not the mouse.

For A, B, and C, are those windows? (Like calculator, file browser, LibreOffice Writer, etc)? And are they all on the same monitor/workspace?

[jmmaranan]

Yes. A, B and C are windows./ denotes a split on any orientation. Let's start with the same monitor / single workspace for now.

You can tap Print Screen and then choosing the camera icon (which records the screen instead of just taking a screenshot - and the circle button changes to red to denote you can do screencasts). Then it saves to Videos when you are done. This should capture everything including the hints

[Cushee-Foofee]

Yes. A, B and C are windows./ denotes a split on any orientation. Let's start with the same monitor / single workspace for now.

You can tap Print Screen and then choosing the camera icon (which records the screen instead of just taking a screenshot - and the circle button changes to red to denote you can do screencasts). Then it saves to Videos when you are done. This should capture everything including the hints

Screencast from 2023-04-30 17-37-16.webm

I didn't realize it would record better than OBS, nice. Although I originally decided against that since it doesn't record audio (Or at leaast I couldn't figure out how).

Essentially, while going counter-clockwise (The direction changes depending on which windows are open I guess? No idea why it changes to be fully honest) it works fine, but then I do the same method, just clockwise, and all of a sudden it only does the two corner windows, and then throws the selection onto the settings pop-up window.

Also, I try moving from the pop-up window with the same movement, but that does not work and I have to use my mouse.

Again, if it had audio, you could hear my keyboard taps, which would better explain the situation.

[jmmaranan]

Thanks for the screencast. I can replicate what you reported.

This is how Forge behaves normally using the head/tail data structure I mentioned. For your 4 windows on the left, I assume the following structure:

[A / B]
[C / D]

For counter clockwise, it works naturally but it follows below. A is head, B is tail, C is head and D is tail. A/B is head, C/D is tail. If you move from C/D to A/B, it is a to previous sibling movement, it will focus on B tail and then head A. If you move down from A/B to C/D, it will focus on C head, then D tail.

For clockwise, it does not as you would expect naturally, but it just follows the head/tail I mentioned.

For when opening the prefs from Extensions App, this one I will check why it gets stucked.

[jmmaranan]

If B remembers that D was previous window on a different split-container, it will work naturally. I'll check sometime this week - this is already mentioned though on #171.

[Cushee-Foofee]

Thanks for the screencast. I can replicate what you reported.

This is how Forge behaves normally using the head/tail data structure I mentioned. For your 4 windows on the left, I assume the following structure:

[A / B]
[C / D]

For counter clockwise, it works naturally but it follows below. A is head, B is tail, C is head and D is tail. A/B is head, C/D is tail. If you move from C/D to A/B, it is a to previous sibling movement, it will focus on B tail and then head A. If you move down from A/B to C/D, it will focus on C head, then D tail.

For clockwise, it does not as you would expect naturally, but it just follows the head/tail I mentioned.

For when opening the prefs from Extensions App, this one I will check why it gets stucked.

It's not just pop-ups, I noticed if I have multiple of a window type, such as 2 Firefox browser windows, or 2 LibreOffice Writer windows, even if one of the windows is on a separate workspace that I am not using, I will get stuck on one of the sides. If I open extensions, turn them all off and on again, not only will my windows slightly move in certain ways, it will also allow the current workspace pair to work together properly, allowing me to move between both sides perfectly fine.

But if I go down a few workspaces, one of the workspace pairs will not work.

I don't know if this is only with paired windows, or all windows randomly.

[jmmaranan]

Can you screenshot what you have here? This is from Settings / Multi-Tasking

Are you using Workspace on Primary or Same Workspace on all displays?

[Cushee-Foofee]

Can you screenshot what you have here? This is from Settings / Multi-Tasking

Are you using Workspace on Primary or Same Workspace on all displays?

[jmmaranan]

Thanks for the screenshot - this is an issue of Forge unable to work with Workspace on Primary because I cannot map the data structure yet (or if at all possible to do so) - unfortunately, you will have to switch it to single workspace for all displays for this one. I'll assume this is what you mentioned here:

Lastly, with 2 monitors, sometimes movement will not work across them. Kind of like a one way mirror, I may be able to move the acive highlight, or even just move a window to the right side, but I cannot access the left side without alt+tabbing, using my mouse, or some other method. In the screenshot, if I accidentally active highlight the settings pop-up window, I cannot access any other window or move any window with forge's hotkeys.

Just trying to have some focus for this ticket, can I use this ticket for the move-window issue? I am talking about the following:

when I am actually moving the windows with the hotkeys (Shift+Super+Arrow), the window may not properly move. For example, in 2x2, I may move a window up, but it doesn't move, or it just moves right and makes a 1x3 or 1x4 configuration instead.

For the highlight, just echoing I'd like to track it on ticket#171:

When moving the active highlight, I noticed that going clockwise (Right, Down, Left, Up) for a 2x2 window setup, it works fine, but when I reverse direction for counter-clockwise, then all of a sudden it only moves between two windows in the opposite corners.

[Cushee-Foofee]

Thanks for the screenshot - this is an issue of Forge unable to work with Workspace on Primary because I cannot map the data structure yet (or if at all possible to do so) - unfortunately, you will have to switch it to single workspace for all displays for this one. I'll assume this is what you mentioned here:

Lastly, with 2 monitors, sometimes movement will not work across them. Kind of like a one way mirror, I may be able to move the acive highlight, or even just move a window to the right side, but I cannot access the left side without alt+tabbing, using my mouse, or some other method. In the screenshot, if I accidentally active highlight the settings pop-up window, I cannot access any other window or move any window with forge's hotkeys.

Just trying to have some focus for this ticket, can I use this ticket for the move-window issue? I am talking about the following:

when I am actually moving the windows with the hotkeys (Shift+Super+Arrow), the window may not properly move. For example, in 2x2, I may move a window up, but it doesn't move, or it just moves right and makes a 1x3 or 1x4 configuration instead.

For the highlight, just echoing I'd like to track it on ticket#171:

When moving the active highlight, I noticed that going clockwise (Right, Down, Left, Up) for a 2x2 window setup, it works fine, but when I reverse direction for counter-clockwise, then all of a sudden it only moves between two windows in the opposite corners.

No way am I switching to workspace on all displays, I will just live with the jank.

Also, yeah you can switch to the move window issue. Here, I will make a video for that specifically.

Screencast from 2023-04-30 18-47-13.webm

I am trying to put the windows back into a 2x2 grid, but they just won't go back.