Hyprland
Hyprland copied to clipboard
hyprwm
focusworkspaceoncurrentmonitor doesn't fully focus after swap
Hyprland Version
System/Version info
Hyprland, built from branch main at commit 181f651de2e67917c7fcc72f7a69e6f4707954e5 dirty (vector: avoid min0 clamps without a max being invalid).
Date: Mon Feb 5 17:37:34 2024
Tag: v0.35.0-4-g181f651d
flags: (if any)
System Information:
System name: Linux
Node name: izumi
Release: 6.7.3-zen1-2-zen
Version: #1 ZEN SMP PREEMPT_DYNAMIC Fri, 02 Feb 2024 17:03:56 +0000
GPU information:
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 XT] [1002:747e] (rev c8) (prog-if 00 [VGA controller])
os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo
plugins:
Bug or Regression?
Bug
Description
First of all, thanks for a resolution of the mouse dependency with this dispatcher.
Now I've noticed another unexpected behavior - after swapping workspaces by targeting one that is on another screen, the focus partially moves to the side screen:
- :x: col.active_border is seen on the side screen and col.inactive_border activates on the previously focused window on the current screen
- :x: keyboard input is on the windows on side screen
- ✔️ hitting a binding to open a new app opens it on the current screen
I've only tested this with both screens having windows on them, hyprland is a bit unpredictable where empty workspaces are involved :P
How to reproduce
Given I have 2 monitors
And I have "Window A" in "Workspace 1" on "Monitor DP-1"
And I have "Window B" in "Workspace 2" on "Monitor DP-2"
And "Window A" is focused
And I don't use the mouse at all
When I press "SUPER + 2 (focusworkspaceoncurrentmonitor , 2)"
✔️ Then "Workspace 2" should be moved to "Monitor DP-1"
✔️ And "Workspace 1" should be moved to "Monitor DP-2"
❌ And "Window B" on "Monitor DP-1" should be focused
✔️ And new windows should open on "Monitor DP-1" by default
But "Window B" gets "col.inactive_border" applied to it
And "Window A" gets "col.active_border" applied to it
And trying to type reveals that "Window A" on "Monitor DP-2" is receiving inputs
Crash reports, logs, images, videos
No response
I too have issues where if I'm on group 1 ( Qutebrowser ) and the window is focused then I do mod + 2 ( That has a foot terminal on the opposite monitor ) it brings the terminal I had on the second monitor to the main monitor but never focuses it . The focus stays on the window that is on group 1 that has now moved as expected to the other monitor.
Hyprland, built from branch main at commit 3d9ca6381df1cdbf1731d7e2b39ea3f7574fce1e dirty (crashreporter: fix logging of function data (4632)).
Date: Wed Feb 7 09:50:23 2024
Tag: v0.35.0-7-g3d9ca638
I have exactly the same problem. It moves the workspace without keeping the focus on the same monitor.
Hyprland, built from branch HEAD at commit 84ab8d11e8951a6551d1e1bf87796a8589da6d47 (props: bump ver to 0.35.0).
Date: Mon Feb 5 01:59:02 2024
Tag: v0.35.0
@vaxerski I know you're extremely busy but any chance you could take a look at this one at some point please ? Thanks in advance.
Also have this issue. The mouse is on the appropriate focus, but the client isn't itself focused until the mouse is moved.
yes yes give me a moment I understand
Hello, I found another small problem (or feature?) but I don't think it deserves new bug report... Last version from pacman 0.37.1-1, so:
When I have an empty workspace 7 on monitor 1 (while workspace 4 with a browser is currently open on monitor 1) and I want to "pass" this empty workspace 7 to monitor 2 (with the mouse focused on monitor 2 in workspace 9) via a keybind something like bind = $mainMod CTRL, 7, focusworkspaceoncurrentmonitor, 7, the actual behavior now is to focus and move the mouse to monitor 1 with the empty workspace 7, and not to open that empty workspace 7 on monitor 2! And when I have the empty workspace 7 open on monitor 1 and workspace 9 open on monitor 2 (with the mouse focus on it), the actual behavior is to SWAP these two workspaces between monitors, and that's absolutely not what I want: I want to move the empty workspace 7 to monitor 2 and focus on it and leave workspace 9 on monitor 2 as well, but that's not what currently happens.
Does anyone know how to fix this, or is there some setting I missed or broke in config? Can I ask to fix this bug or implement a feature to my preferred behavior if it's not a bug tho? Thanks.
I already post about this issue in https://github.com/hyprwm/Hyprland/pull/4439#issuecomment-2001653203 but didn't get answer yet. Anyway it will be nice if it gets fixed.
sounds like a bug, but wdym "empty workspace 7 on monitor 1 while workspace 4 is open", empty workspaces not in focus get deleted?
sounds like a bug, but wdym "empty workspace 7 on monitor 1 while workspace 4 is open", empty workspaces not in focus get deleted?
Oh sorry for my poor explanation. I mean I have on monitor 1 an empty workspace 7 (it binded to it by workspace = 7, monitor:DP-1) and a browser open on workspace 4 but not in focus: mouse cursor on workspace 9 and it is focused on the monitor 2 and I see both workspaces 4 and 9 in two monitors in this example and when I trigger bind = $mainMod CTRL, 7, focusworkspaceoncurrentmonitor, 7 mouse focuses on empty workspace 7 and it switches from 4 on monitor 1 and not changed anything on monitor 2 but I wanted to move (and open) workspace 7 to monitor 2.
Monitor 1 (focused coz I need to screenshot):
Monitor 2 (actual mouse position in experiment):
Also Waybar don't update status of workspace after these moves (and also swapactiveworkspaces and movecurrentworkspacetomonitor ) and that's very confusing and I need to move mouse to other monitor/workspace to get update (but that's probably it's problem tho).
Anyway thank you so much for reply and this best GUI thing for Linux ever xd
well if you bound it to a specific monitor that will take precedence over your cursor
well if you bound it to a specific monitor that will take precedence over your cursor
Ok I just unbound that workspace = 7, monitor:DP-1 thing an it fixed it surprisingly, but if I want workspaces 1 to 8 to be bound by default to monitor 1 and workspaces 9+ to monitor 2 what should I do exactly? I primarily use combination like bind = $mainMod, 7, workspace, 7 to switch between workspaces, but also want to use bind = $mainMod CTRL, 7, focusworkspaceoncurrentmonitor, 7 sometimes. Will you fix this bug or it is a "feature" now tho?
And btw there is a very strange animation effect with switching through focusworkspaceoncurrentmonitor when a non active another workspace that I want to switch to monitor 2 (which is on monitor 1) appears for a half a second on that monitor 1 and then moves to monitor 2 and it's feels uncomfortable to be honest haha
I have
bezier = myBezier, 0.165, 1.025, 0.025, 1
animation = windows, 1, 2, myBezier
animation = windowsOut, 1, 2, default, popin 80%
animation = border, 1, 2, default
animation = borderangle, 1, 2, default
animation = fade, 1, 2, default
animation = workspaces, 1, 2.5, myBezier
animation = specialWorkspace, 1, 2, myBezier, slidevert
if it helps... Thanks anyway!
And btw there is a very strange animation effect with switching through focusworkspaceoncurrentmonitor when a non active another workspace that I want to switch to monitor 2 (which is on monitor 1) appears for a half a second on that monitor 1 and then moves to monitor 2 and it's feels uncomfortable to be honest haha
sounds like @thejch 's fault in #5126
probably, but honestly not sure what that means. i tried reproducing but couldn't. maybe send a video?
probably, but honestly not sure what that means. i tried reproducing but couldn't. maybe send a video?
Ok but can you tell me how exactly you recorded your video with two virtual Hyprland screens? Thanks
Ok but can you tell me how exactly you recorded your video with two virtual Hyprland screens? Thanks
If you want to launch nested hyprland with two virtual monitors, do WLR_BACKENDS=wayland,wayland ./build/Hyprland. Put both on one physical screen and you can record that screen.
Alternatively just record your monitors with your phone or something. as long as you can see whats going on in the video
Ok but can you tell me how exactly you recorded your video with two virtual Hyprland screens? Thanks
If you want to launch nested hyprland with two virtual monitors, do
WLR_BACKENDS=wayland,wayland ./build/Hyprland. Put both on one physical screen and you can record that screen. Alternatively just record your monitors with your phone or something. as long as you can see whats going on in the video
I just did it "OBS skills" way. There are two of bugs to which I refer in one video: first is the strange animation when another workspace pops up in a half a second (00:20) and second in which workspaces (actually) swapped the wrong way with focusworkspaceoncurrentmonitor (and I'm sure they shouldn't "swap" at all with dispatcher like that, 00:27).
P.S. And yes my "DP-1" and "DP-2" on this recording positioned right way like in my real setup. I "reversed" them in text of my previous reports/comments just for better understanding of the problem. Sorry for confusion xd
https://github.com/hyprwm/Hyprland/assets/36805381/e323fd05-d50f-472c-88a8-878272eb560b
I just did it "OBS skills" way. There are two of bugs to which I refer in one video: first is the strange animation when another workspace pops up in a half a second (00:20) and second in which workspaces (actually) swapped the wrong way with
focusworkspaceoncurrentmonitor(and I'm sure they shouldn't "swap" at all with dispatcher like that, 00:27).P.S. And yes my "DP-1" and "DP-2" on this recording positioned right way like in my real setup. I "reversed" them in text of my previous reports/comments just for better understanding of the problem. Sorry for confusion xd bugs-1.mp4
That first issue should be fixed. The second swapping thing apparently is by design from what I can tell from the code. Maybe the people who added this feature liked it that way. You may wanna open a feature request for adding an alternative option if you would like it to behave the way you describe it.
That first issue should be fixed. The second swapping thing apparently is by design from what I can tell from the code. Maybe the people who added this feature liked it that way. You may wanna open a feature request for adding an alternative option if you would like it to behave the way you describe it.
Ok, thanks for fix! I will think about second...