xfwm4 issueshttps://gitlab.xfce.org/xfce/xfwm4/-/issues2024-03-28T16:04:49Zhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/774mouse controlling opposite monitor on dual monitor setup2024-03-28T16:04:49Zcallmejoemouse controlling opposite monitor on dual monitor setupAfter upgrading to kernel 6.8.1 I am having this issue.
I have dual monitors and when i boot to the desktop if the mouse is on the left screen it will bring a window on the right monitor into focus. so in order to grab a window on the ...After upgrading to kernel 6.8.1 I am having this issue.
I have dual monitors and when i boot to the desktop if the mouse is on the left screen it will bring a window on the right monitor into focus. so in order to grab a window on the right monitor i have position the mouse cursor on the left monitor approximating the relative location of the window on the right monitor.
I've tried moving the displays around and changing primary display in the settings but it doesn't fix the issue. This is happening if I log into the desktop as the root user. If I log in as a regular user I can use the display settings manager to make adjustments and everything works as it should.
I am using an nvidia GTX1660ti gpu with nouveau driver. This behavior goes away if i switch to the nvidia proprietary driver.
Also, if i downgrade to kernel 6.7.9 the issue goes away with the nouveau driver.
KDE seems to work fine, as well my wayland DE, wayfire.
distro is archlinux.
I submitted a bug report over on the mesa project, but they suggested this is probably an xfce issue.
thankshttps://gitlab.xfce.org/xfce/xfwm4/-/issues/775Synchronizing window frame and content2024-03-23T18:40:14ZNikolay BorodinSynchronizing window frame and contentIs there any way to synchronize the window frame creation with the appearance of the framebuffer (window content)?
For example, when I start the application, the client doesn't immediately render the content. Can we somehow check this a...Is there any way to synchronize the window frame creation with the appearance of the framebuffer (window content)?
For example, when I start the application, the client doesn't immediately render the content. Can we somehow check this and draw the frame only when the content has appeared (and do similar thing for destroying windows?).
![image](/uploads/26b6b6c62018b57e4db148f53a010fa7/изображение.png)
Because I think kwin did it somehow.https://gitlab.xfce.org/xfce/xfwm4/-/issues/8Expose-like task switcher for Xfce2024-03-23T16:59:33ZBugzilla MigrationExpose-like task switcher for Xfce## Submitted by Christof Schulze
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#3541)](https://bugzilla.xfce.org/show_bug.cgi?id=3541)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_6...## Submitted by Christof Schulze
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#3541)](https://bugzilla.xfce.org/show_bug.cgi?id=3541)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier:
it would be great to have a task switcher for xfce that could display all windows side by side like the application switcher of apple'S OSX
skippy is not an option since it crashes constantly but skippy-xd might actually do what I want (not sure since it keeps crashing on my system)
compiz is not an option since it would involve using a different windowmanager, but xfwm is otherwise superior.
Reproducible: Always
Version: 4.4.xOlivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/642Prevent windows move to external monitor on connect2024-03-20T12:15:28ZVadym LavrovPrevent windows move to external monitor on connectI just got a bug (dunno if it presents only for me, or that's a well-known issue) that when I connect any external monitor - every window automatically moves to it.
Even if the laptop monitor is set to Primary.I just got a bug (dunno if it presents only for me, or that's a well-known issue) that when I connect any external monitor - every window automatically moves to it.
Even if the laptop monitor is set to Primary.https://gitlab.xfce.org/xfce/xfwm4/-/issues/715Desktop frozen after resume from system sleep if sceensaver is enabled2024-03-14T14:56:02ZAlexander RennDesktop frozen after resume from system sleep if sceensaver is enabledConsider the following scenario:
- desktop compositing is enabled
- xscreensaver is being used for locking and it's set to lock on system sleep event
- system is suspended by closing the laptop lid
After the system is resumed, I'm pre...Consider the following scenario:
- desktop compositing is enabled
- xscreensaver is being used for locking and it's set to lock on system sleep event
- system is suspended by closing the laptop lid
After the system is resumed, I'm presented with the static frozen screenshot of my desktop instead of the screensaver. But typing my password and pressing "ENTER" causes the desktop to unfreeze, i.e. keyboard input went to xscreensaver, and xscreensaver unlocks the desktop. This means that the foreground window which grabbed keyboard input was in fact the xscreensaver lock screen, but for some reason it was not rendered properly on the screen (basically, xscreensaver lock screen was invisible).
If desktop compositing is disabled then everything works as expected, i.e. no desktop freeze after system resume, xscreensaver shows its lock screen as it's supposed to be. This is why I believe it might be an issue with the desktop composition.
Also, the issue is not limited only to the xscreensaver. I verified that there is the same issue if using gnome-screensaver.
And I guess it's the same issue as https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/1https://gitlab.xfce.org/xfce/xfwm4/-/issues/772Rename Stick Window shortcut to mention workspaces2024-03-11T13:59:32ZBill RuddockRename Stick Window shortcut to mention workspacesThe Window Manager keyboard shortcut `Stick Window` is not intuitive in its meaning. #622 was one example of confusion with this naming. I was also confused by this today as I had mistakenly unset the shortcut and struggled to find it ag...The Window Manager keyboard shortcut `Stick Window` is not intuitive in its meaning. #622 was one example of confusion with this naming. I was also confused by this today as I had mistakenly unset the shortcut and struggled to find it again.
The wording used in the window menu from the title bar is "Always on Visible Workspace" / "Only Visible in This Workspace", which is more clear to me.
I think it would make sense for the keyboard shortcut and the window menu actions for this to be similar to each other. This would help a user who knows how to do this using the window menu to find the related shortcut.
I suggest a new wording for the keyboard shortcut as `Stick Window to All Workspaces`.https://gitlab.xfce.org/xfce/xfwm4/-/issues/697Focus changes to xfdesktop when switching into a workspace with a fullscreen ...2024-03-10T14:54:20ZFelipe MarinsFocus changes to xfdesktop when switching into a workspace with a fullscreen windowI noticed this after upgrading to Xfce 4.18. As mentioned in the title, if the focus of the target workspace is on a non-gtk fullscreen window, the focus changes to xfdesktop (I monitored it by using `watch xdotool getactivewindow`). But...I noticed this after upgrading to Xfce 4.18. As mentioned in the title, if the focus of the target workspace is on a non-gtk fullscreen window, the focus changes to xfdesktop (I monitored it by using `watch xdotool getactivewindow`). But it also depends on the way of switching workspaces and the context.
Here is some situations where this bug **doesn't** happen:
- If you switch the workspace by using the pager panel plugin.
- If the current focus is already on xfdesktop. So when switching workspaces, the focus changes as expected.
- If the current focus is already on a fullscreen window.
- If the target workspace is already focused on xfdesktop, so the focus changes automatically to the fullscreen window.
To exemplify the last situation, let's say that you have 2 workspaces: the first is focused on Mousepad (that is not at fullscreen) and the second is focused on Krita (that is at fullscreen). When you switch from the first workspace to the second, the focus changes to xfdesktop. So when you switch back to the first workspace and switch again to the second (where the focus is on xfdesktop), the focus changes back to Krita.
I didn't find anyone reporting this on Manjaro Forum, so maybe this bug is caused by some configuration that I've changed before. But since I don't remember changing such a configuration, I decided to open this issue.
**Edit:** As I commented below, there is a new addition to what I described above. Even though the behaviour described still happens, there is a case where the focus acts as expected that I describe in the comment: https://gitlab.xfce.org/xfce/xfwm4/-/issues/697#note_81601
**Xfwm4 version:** 4.18.0 | **OS:** Manjaro Linux with Stable repositoryhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/748Alt+Tab works incorrectly for Java AWT/Swing apps with modal dialogs2024-03-10T13:48:49ZDmitry BatrakAlt+Tab works incorrectly for Java AWT/Swing apps with modal dialogsWhen a Java AWT/Swing application is showing a modal dialog, Alt+Tab doesn't work as expected for it. The application gets activated as expected, but it's not moving in the list of recently activated apps. This, in particular, results so...When a Java AWT/Swing application is showing a modal dialog, Alt+Tab doesn't work as expected for it. The application gets activated as expected, but it's not moving in the list of recently activated apps. This, in particular, results sometimes in Alt+Tab being 'stuck' on such an application (a single invocation of Alt+Tab not moving focus to another app).
Sample reproducer (ModalDialog.java file) is attached to the ticket. With any Java 11+ runtime installed (tested with openjdk-11-jre), it can be launched from terminal as `java ModalDialog.java`. After the sample app is launched, press Alt+Tab several times. First time focus is switched back to terminal as expected, but then it's stuck on sample app. To switch to the terminal, Tab should be pressed twice, while Alt is held pressed.
Reproduced with Xfwm4 v4.16.1 on Linux Mint 21.https://gitlab.xfce.org/xfce/xfwm4/-/issues/771Unwanted window resize when saving file in meld (GTK3 application)2024-03-08T14:53:59ZJohan MazelUnwanted window resize when saving file in meld (GTK3 application)I use Xfce 4.18, GTK 3.24.38, and Meld 3.22 (a GUI diff tool).
Inside Meld, I open a tab that compares two files, toto0 and toto1, and another tab that also compares two files, toto1 (same file as in the first tab) and toto2.
If I modif...I use Xfce 4.18, GTK 3.24.38, and Meld 3.22 (a GUI diff tool).
Inside Meld, I open a tab that compares two files, toto0 and toto1, and another tab that also compares two files, toto1 (same file as in the first tab) and toto2.
If I modify the toto1 file in the first tab and save it, the meld windows height unexpectedly increases well beyond my screen size (roughly two times).
When I save the file there is a "Reload" button that pops up inside the second tab. This may causes my window height problem.
The expected behavior would be that the Meld window height does not change when I save a file.
I strongly suspect that the bug is inside Xfce because I do not get this error inside Gnome so I guess that the error is not inside GTK or Meld.
I chose to report the bug inside the Xfwm4 repository because it felt like it was the most probable location for the observed bug. If anybody think I should actually report my problem elsewhere, I will gladly remove this issue and report in another repository.https://gitlab.xfce.org/xfce/xfwm4/-/issues/760Minimizing and maximizing when "Focus follows mouse" is enabled2024-02-26T15:34:20ZSashaMinimizing and maximizing when "Focus follows mouse" is enabledIf "Focus follows mouse" is enabled in the Window Manager settings of Xfce, and you click on a icon on the taskbar, it will minimize and maximize the window a few times but after that it will stay minimized even if you click on the icon.If "Focus follows mouse" is enabled in the Window Manager settings of Xfce, and you click on a icon on the taskbar, it will minimize and maximize the window a few times but after that it will stay minimized even if you click on the icon.https://gitlab.xfce.org/xfce/xfwm4/-/issues/770Alt+mouse wheel to zoom: client window "sometimes" receives mouse-wheel events2024-02-22T23:37:05ZBURN-MICROSUCKAlt+mouse wheel to zoom: client window "sometimes" receives mouse-wheel eventsI often use alt+mousewheel to zoom the screen, very useful feature. The only problem is that if the mouse is over a window (which it normally is, ie. the one i want to show/see closer) then that window receives the mouse up/down events, ...I often use alt+mousewheel to zoom the screen, very useful feature. The only problem is that if the mouse is over a window (which it normally is, ie. the one i want to show/see closer) then that window receives the mouse up/down events, while it shouldn't since those are meant by the user to tell xfwm to zoom the screen, not to scroll around in the app or do whatever the mouse wheel happens to do in that window.
edit: this happens inconsistently and "sometimes" only, no idea what triggers it.https://gitlab.xfce.org/xfce/xfwm4/-/issues/769No possible way to disable shadows without disabling compositor2024-02-22T23:23:04ZBURN-MICROSUCKNo possible way to disable shadows without disabling compositorThe checkboxes under "window manager tweaks" settings, "compositor" tab. Only the shadows under docks (panels) can be disabled. Toggling the other checkboxes for shadows under popups (menus) and regular windows - or editing the correspon...The checkboxes under "window manager tweaks" settings, "compositor" tab. Only the shadows under docks (panels) can be disabled. Toggling the other checkboxes for shadows under popups (menus) and regular windows - or editing the corresponding settigns using xfce4-settings-editor -> xfwm4 - doesn't disable them, even after dis/re-enabling the compositor, or even logout/reboot.
X11, same result on several different machines with different graphics cards, mainly nvidia, intel-builtin.https://gitlab.xfce.org/xfce/xfwm4/-/issues/761Shadow settings don't take effect immediately when enabling the compositor2024-02-13T22:39:54ZNinjaCowboyShadow settings don't take effect immediately when enabling the compositorWhen re-enabling the compositor, no shadows appear initially until I toggle the settings checkboxes.
## Steps to reproduce:
1. Select a light coloured wallpaper so that shadows can be easily seen.
2. Open xfwm4-tweaks-settings and go to ...When re-enabling the compositor, no shadows appear initially until I toggle the settings checkboxes.
## Steps to reproduce:
1. Select a light coloured wallpaper so that shadows can be easily seen.
2. Open xfwm4-tweaks-settings and go to the Compositor tab.
3. Enable all of the shadow options.
4. Uncheck and check "Enable display compositing".
## Expected behaviour:
Enabled shadows should be visible immediately upon enabling the compositor.
## Actual behaviour:
No shadows are visible, but toggling one of the checkboxes off and on again after enabling the compositor seems to make them show up again.
![Video Demonstration](/uploads/1aaef1472ae1cc30dd4a11120e7f18b2/out.ogv)https://gitlab.xfce.org/xfce/xfwm4/-/issues/768Firefox occasionally stops redrawing / freezes under Xfwm2024-02-04T14:39:37ZAlistair BuxtonFirefox occasionally stops redrawing / freezes under XfwmAbout once per day, Firefox UI stops updating. It is still working, it just doesn't redraw.
My system is Ubuntu, Xorg and Nvidia proprietary drivers. I have the compositor turned on in Xfwm. This problem has been happening for a couple ...About once per day, Firefox UI stops updating. It is still working, it just doesn't redraw.
My system is Ubuntu, Xorg and Nvidia proprietary drivers. I have the compositor turned on in Xfwm. This problem has been happening for a couple of years. Closest I can narrow it down to is it didn't happen in Xubuntu 20.04 but I think it does in 22.04 and it definitely does in 23.04.
Webrender is disabled in my Firefox, I think. gfx.webrender.all is set to False.
This is an odd bug and difficult to reproduce so the report will be a list of symptoms and observations for now:
* Moving or resizing the Firefox window will cause it to redraw exactly once.
* Restarting Firefox makes the problem go away temporarily.
* Restarting Xfwm also make the problem go away temporarily.
* If there is a Youtube video playing on the current tab, it will continue playing, even though the rest of the window doesn't update.
* The problem seems to happen more often when watching Youtube videos, especially if one is playing in a background tab.
* Sometimes when this happens, the Xfce panel also freezes, especially the volume control applet. Closing Firefox makes this problem go away too.
* Sometimes Firefox will completely freeze after this happens, ie you can no longer interact with it, and attempting to close the window pops up the Xfwm "frozen application" message. This is very rare though.
So I'm not sure if this is a Xfwm problem or a Firefox problem. It is strange that restarting either of them makes the problem go away.
I realise there isn't much to go on here but I will update this bug if I find anything new.https://gitlab.xfce.org/xfce/xfwm4/-/issues/742[Feature Request] Horizontal Pixmap Support in Themes.2024-02-04T01:59:53Z266-750Balloons[Feature Request] Horizontal Pixmap Support in Themes.As it currently stands in xfwm, there is only support for tiling pixmaps horizontal (a.k.a "vertical pixmaps"). This is problematic in that it makes patterns such as horizontal gradients impossible in the window manager as it is. Thus, I...As it currently stands in xfwm, there is only support for tiling pixmaps horizontal (a.k.a "vertical pixmaps"). This is problematic in that it makes patterns such as horizontal gradients impossible in the window manager as it is. Thus, I think it would be nice if xfwm could add support for various forms of gradients and vertical tiling.https://gitlab.xfce.org/xfce/xfwm4/-/issues/767Default keybinds to tile window up or down are interchanged2024-01-26T16:56:01ZShallrathDefault keybinds to tile window up or down are interchangedBy default, the keybinds to tile windows are the following:
| Action | Default Keybind |
| ------------- | ----------------------- |
| Tile left | Super + Numpad left |
| Tile right | Super + Numpad right |
...By default, the keybinds to tile windows are the following:
| Action | Default Keybind |
| ------------- | ----------------------- |
| Tile left | Super + Numpad left |
| Tile right | Super + Numpad right |
| Tile **up** | Super + Numpad **down** |
| Tile **down** | Super + Numpad **up** |
I don't think assigning up and down to the exact opposite keys is good. Especially when the other keybinds that tile lower left or lower right are using keys at the bottom (End and PgPn) and the upper left and upper right keybinds are at the top (Home and PgUp).
So in the corners, up means up and down means down, while at the egdges, up means down and down means up.
I know these can easily be changed by the user but I think the default should be fixed so that users don't need to do this change on their end.https://gitlab.xfce.org/xfce/xfwm4/-/issues/280Make window lowering with middle click optional2024-01-23T19:13:39ZBugzilla MigrationMake window lowering with middle click optional## Submitted by Antti Savolainen
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#14154)](https://bugzilla.xfce.org/show_bug.cgi?id=14154)**
## Description
Sometimes closing tabs with middle click overshoots a ...## Submitted by Antti Savolainen
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#14154)](https://bugzilla.xfce.org/show_bug.cgi?id=14154)**
## Description
Sometimes closing tabs with middle click overshoots a little and lowers the window. I'm wishing for a setting to make this optional.
I found a 2013 branch implementing it, but I don't know how valid or up to date the code is.
https://github.com/CBke/xfwm4/commit/e34e71e06f0bdadee45e5fde4af7c5f51e7dc358Olivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/576"Move window to" inconsistent behavior.2024-01-21T20:47:53ZJacco van Schaik"Move window to" inconsistent behavior.The behavior of "Move window to workspace <n>" and "Move window to {upper, bottom, etc.} workspace" seems to be inconsistent. The former moves the focused window to the given workspace but doesn't switch to the workspace. The latter move...The behavior of "Move window to workspace <n>" and "Move window to {upper, bottom, etc.} workspace" seems to be inconsistent. The former moves the focused window to the given workspace but doesn't switch to the workspace. The latter moves the window *and* switches to the indicated workspace. I think it would be better if these actions behaved the same way (move the window *and* switch workspace would be my preference).
Xubuntu 21.04, Xfce 4.16.https://gitlab.xfce.org/xfce/xfwm4/-/issues/766Body of window disappears from window's pixmap when it is closed2024-01-21T20:36:08ZYuxuan ShuiBody of window disappears from window's pixmap when it is closedThis is the same problem as #317, just for the window closing case. The cause is the same too, the client window is destroyed before the frame.This is the same problem as #317, just for the window closing case. The cause is the same too, the client window is destroyed before the frame.https://gitlab.xfce.org/xfce/xfwm4/-/issues/764[Feature Request] Hotkeys to cycle left & right between window buttons like tabs2024-01-20T22:30:39Zadvice[Feature Request] Hotkeys to cycle left & right between window buttons like tabsI apologize if this already exists, if it does please let me know. I am looking to have a set of hotkeys that can cycle between window buttons left or right.
Obviously user can customize them but I was thinking of
Super + PageDown = se...I apologize if this already exists, if it does please let me know. I am looking to have a set of hotkeys that can cycle between window buttons left or right.
Obviously user can customize them but I was thinking of
Super + PageDown = select/cycle next panel window button to the right
Super + PageUp = select/cycle next panel window button to the left
Similar to how when you have a program with tabs you can use ctrl+page down & ctrl+page up to cycle between the them.
Hotkeys would be applied to the window button that currently has focus and goes left or right based on that. I imagine would cycle back to beginning / end when reached like how tabs do.
There are so many hotkeys it is hard to believe that a simple set like this does not exist, so again I apologize if I have overlooked them. All the ones I have tried seem to cycle between window buttons in a "random" order / pattern.
I had originally thought that the Lower Window & Raise Window hotkeys could maybe do this but don't think so, it cycles in a random order. I cannot confirm because they do not work as in the issue I reported here #763
Also if possible, I have noticed that some cycling hotkeys have issues when programs are opened in fullscreen, if possible if these hotkeys are added would be great if fullscreen programs are not treated any differently than maximized windows. I think the Lower/Raise Window tools are one of them that have issue, not sure if I should make separate issue for this?
Thank You if anyone considers adding this