xfwm4 issueshttps://gitlab.xfce.org/xfce/xfwm4/-/issues2024-03-18T14:50:16Zhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/773<Super>+d doesn't work for Show Desktop2024-03-18T14:50:16ZHei Tor<Super>+d doesn't work for Show DesktopSuper+d doesn't work for Show Desktop. The closest that I could get was Alt+d, because ctrl+alt+d is too much. I tried to make it work by manually editing the show_desktop_key in ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-...Super+d doesn't work for Show Desktop. The closest that I could get was Alt+d, because ctrl+alt+d is too much. I tried to make it work by manually editing the show_desktop_key in ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml and rebooting over and over, but it doesn't work at all. Unless for <super>+e for thunar or <super>+c for xfce4-popup-clipman which is, btw, very handy to manage transfer area.
$ uname -a
Linux fedora 6.7.7-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 1 16:53:59 UTC 2024 x86_64 GNU/Linux
xfce4-about -V
xfce4-about 4.18.5 (Xfce 4.18)https://gitlab.xfce.org/xfce/xfwm4/-/issues/1Add possibility to make title bar button for "Aways on top"2024-03-15T03:26:09ZBugzilla MigrationAdd possibility to make title bar button for "Aways on top"## Submitted by Peter de Ridder
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#2354)](https://bugzilla.xfce.org/show_bug.cgi?id=2354)**
## Description
xfwm gives possibility for title bar buttons for stick, s...## Submitted by Peter de Ridder
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#2354)](https://bugzilla.xfce.org/show_bug.cgi?id=2354)**
## Description
xfwm gives possibility for title bar buttons for stick, shade, etc. It would be nice to have it also for "Always On Top". Not everyone needs that but it's quite handy. Same counts for the shortcut keys as reported in [bug 1121](https://bugzilla.xfce.org/show_bug.cgi?id=1121) (Add possibility to make shorcut for "Always on top")
Reproducible: Always
Steps to Reproduce:
Version: 4.4.xOlivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/622Alt-F6 preset to Stick window, the actual effect is Only on This Workspace2024-03-11T13:59:34ZGraham PerrinAlt-F6 preset to Stick window, the actual effect is Only on This WorkspaceXfce on FreeBSD stable/13 in a VirtualBox guest.
When the shortcut is used, the effect differs from its preset.
After trying repeatedly with a physical keyboard on USB, I tried repeatedly with the soft keyboard of VirtualBox:
![202...Xfce on FreeBSD stable/13 in a VirtualBox guest.
When the shortcut is used, the effect differs from its preset.
After trying repeatedly with a physical keyboard on USB, I tried repeatedly with the soft keyboard of VirtualBox:
![2021-12-31_12-40-42](/uploads/26350c140316030d4573770700dd87c1/2021-12-31_12-40-42.png)
The shortcut does **not** result in Always On Top (if that's what's meant by _stick_).
### Environment
```text
grahamperrin@mowa219-gjp4-freebsd-13-stable-vm:~ $ date ; uptime ; uname -aKU
Fri Dec 31 13:03:55 GMT 2021
1:03PM up 57 mins, 0 users, load averages: 4.15, 3.51, 2.54
FreeBSD mowa219-gjp4-freebsd-13-stable-vm 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n248759-3684bb89d52: Thu Dec 30 02:37:49 UTC 2021 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1300523 1300523
grahamperrin@mowa219-gjp4-freebsd-13-stable-vm:~ $ pkg -vv | grep -e url -e enabled
url : "pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest",
enabled : yes,
grahamperrin@mowa219-gjp4-freebsd-13-stable-vm:~ $ pkg prime-origins | sort
devel/git
editors/nano
emulators/virtualbox-ose-additions
ports-mgmt/pkg
security/sudo
sysutils/gkrellm2
sysutils/htop
www/firefox
x11-wm/xfce4
x11/qterminal
x11/sddm
x11/xorg
grahamperrin@mowa219-gjp4-freebsd-13-stable-vm:~ $ pkg info -x x11-wm/xfce4-wm
xfce4-wm-4.16.1
grahamperrin@mowa219-gjp4-freebsd-13-stable-vm:~ $
```https://gitlab.xfce.org/xfce/xfwm4/-/issues/756Xfwm4 does not respect the use of an external compositor (picom, etc.)2024-02-22T15:02:18ZNikolay BorodinXfwm4 does not respect the use of an external compositor (picom, etc.)If you use the built-in xfwm4 compositor, all the window manager effects are displayed, but if you use a different compositor, the effects are disabled, although they work fine using [picom](https://github.com/yshui/picom).
This patch f...If you use the built-in xfwm4 compositor, all the window manager effects are displayed, but if you use a different compositor, the effects are disabled, although they work fine using [picom](https://github.com/yshui/picom).
This patch fixes this behavior (works fine even if the --disable-compositor autotools option is set):
```diff
diff --git a/src/compositor.c b/src/compositor.c
index 49c27f730..4269bbcae 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4173,6 +4173,7 @@ compositorHandleCursorNotify (DisplayInfo *display_info, XFixesCursorNotifyEvent
update_cursor (screen_info);
}
}
+#endif
static gboolean
compositorCheckCMSelection (ScreenInfo *screen_info)
@@ -4200,6 +4201,7 @@ compositorCheckCMSelection (ScreenInfo *screen_info)
return FALSE;
}
+#ifdef HAVE_COMPOSITOR
#ifdef HAVE_PRESENT_EXTENSION
static void
compositorHandlePresentCompleteNotify (DisplayInfo *display_info, XPresentCompleteNotifyEvent *ev)
@@ -4406,11 +4408,19 @@ compositorIsUsable (DisplayInfo *display_info)
gboolean
compositorIsActive (ScreenInfo *screen_info)
{
-#ifdef HAVE_COMPOSITOR
g_return_val_if_fail (screen_info != NULL, FALSE);
- return screen_info->compositor_active;
+#ifdef HAVE_COMPOSITOR
+ if (screen_info->compositor_active) {
+ return TRUE;
+ }
#endif /* HAVE_COMPOSITOR */
+
+ // check if any other compositor is running (ex. picom)
+ if (compositorCheckCMSelection(screen_info)) {
+ return TRUE;
+ }
+
return FALSE;
}
```
P.S. Maybe there are other places where you need to fix the code, but this patch seems to [work fine](https://imgur.com/a/2188Qcn), I didn't see any issues.
It would be nice to have this thing, especially when picom is on the WM/compositor list (compton can be removed, it's obsolete and unmaintained).
![xfce4-settings](/uploads/aed8036e8d442907016710461f221915/изображение.png)https://gitlab.xfce.org/xfce/xfwm4/-/issues/317Boby of window disappears from window's pixmap when it is minimized2024-01-21T20:15:34ZBugzilla MigrationBoby of window disappears from window's pixmap when it is minimized## Submitted by ysh..@..il.com
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#15061)](https://bugzilla.xfce.org/show_bug.cgi?id=15061)**
## Description
Context: there is a user reporting to compton (some kind...## Submitted by ysh..@..il.com
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#15061)](https://bugzilla.xfce.org/show_bug.cgi?id=15061)**
## Description
Context: there is a user reporting to compton (some kind of X11 compositor) complaining that, with compton fade out is enabled, minimizing a window will cause the body of the window to disappear immediately, then the decoration of the window will gradually fade out.
The way compton handles fade out is like this: when a window is unmapped, compton will keep using the last named pixmap right before the unmap, and draw it will decreasing opacity. Therefore, I suspect xfwm might did something during window unmap so the body of the window disappeared.
I understand this might not really be a bug in xfwm, but I wish you could shed some light on this problem, as this only occur when compton is used with xfwm.Olivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/24Window borders are displayed black2023-12-17T20:03:50ZBugzilla MigrationWindow borders are displayed black## Submitted by Daniel Pielmeier
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5532)](https://bugzilla.xfce.org/show_bug.cgi?id=5532)**
## Description
Created attachment 2440
Black Decorations
Sometimes aft...## Submitted by Daniel Pielmeier
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5532)](https://bugzilla.xfce.org/show_bug.cgi?id=5532)**
## Description
Created attachment 2440
Black Decorations
Sometimes after starting xfce all windows have black borders. When I fire up xfce4-appearance-settings and switch styles the decorations are back again.
**Attachment 2440**, "Black Decorations":
![decorations](/uploads/b0323dd7096f5510386b0f8ecd65f798/decorations.png)
Version: 4.6.1Olivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/757Mouse freezes for a few seconds if an HDMI display has been connected to the ...2023-12-04T13:00:17ZFlashwalkerMouse freezes for a few seconds if an HDMI display has been connected to the laptopI have the Intel graphics and also the nVidia card on my laptop in hybrid prime mode runing on proprietary drivers v.535.
When i plug an additional monitor via HDMI i'm starting to get `SYN_DROPPED event` Xorg errors with mouse freezin...I have the Intel graphics and also the nVidia card on my laptop in hybrid prime mode runing on proprietary drivers v.535.
When i plug an additional monitor via HDMI i'm starting to get `SYN_DROPPED event` Xorg errors with mouse freezing for a few seconds:
```
[152372.261] (II) config/udev: Adding input device MX Anywhere 3S Mouse (/dev/input/mouse3)
[152372.261] (II) No input driver specified, ignoring this device.
[152372.261] (II) This device may have been added with another device file.
[152372.288] (II) config/udev: Adding input device MX Anywhere 3S Mouse (/dev/input/event18)
[152372.288] (**) MX Anywhere 3S Mouse: Applying InputClass "libinput pointer catchall"
[152372.288] (II) Using input driver 'libinput' for 'MX Anywhere 3S Mouse'
[152372.288] (**) MX Anywhere 3S Mouse: always reports core events
[152372.288] (**) Option "Device" "/dev/input/event18"
[152372.290] (II) event18 - MX Anywhere 3S Mouse: is tagged by udev as: Mouse
[152372.290] (II) event18 - MX Anywhere 3S Mouse: device is a pointer
[152372.290] (II) event18 - MX Anywhere 3S Mouse: device removed
[152372.312] (**) Option "config_info" "udev:/sys/devices/virtual/misc/uhid/0005:046D:B037.000B/input/input46/event18"
[152372.312] (II) XINPUT: Adding extended input device "MX Anywhere 3S Mouse" (type: MOUSE, id 18)
[152372.316] (**) Option "AccelerationScheme" "none"
[152372.319] (**) MX Anywhere 3S Mouse: (accel) selected scheme none/0
[152372.319] (**) MX Anywhere 3S Mouse: (accel) acceleration factor: 2.000
[152372.319] (**) MX Anywhere 3S Mouse: (accel) acceleration threshold: 4
[152372.320] (II) event18 - MX Anywhere 3S Mouse: is tagged by udev as: Mouse
[152372.320] (II) event18 - MX Anywhere 3S Mouse: device is a pointer
[152415.197] (II) event18 - MX Anywhere 3S Mouse: SYN_DROPPED event - some input events have been lost.
[152475.402] (II) event18 - MX Anywhere 3S Mouse: SYN_DROPPED event - some input events have been lost.
[152497.459] (II) event18 - MX Anywhere 3S Mouse: SYN_DROPPED event - some input events have been lost.
[152497.463] (EE) client bug: timer event18 debounce: scheduled expiry is in the past (-70ms), your system is too slow
[152497.463] (EE) client bug: timer event18 debounce short: scheduled expiry is in the past (-87ms), your system is too slow
...
[153314.103] (II) event18 - MX Anywhere 3S Mouse: SYN_DROPPED event - some input events have been lost.
[153314.103] (EE) client bug: timer event18 debounce: scheduled expiry is in the past (-26ms), your system is too slow
[153314.103] (EE) client bug: timer event18 debounce short: scheduled expiry is in the past (-39ms), your system is too slow
[153325.153] (EE) client bug: timer event18 debounce: scheduled expiry is in the past (-1152ms), your system is too slow
[153325.153] (EE) client bug: timer event18 debounce: scheduled expiry is in the past (-1040ms), your system is too slow
[153325.153] (EE) client bug: timer event18 debounce short: scheduled expiry is in the past (-1053ms), your system is too slow
[153325.153] (EE) WARNING: log rate limit exceeded (5 msgs per 3600000ms). Discarding future messages.
```
I found [here](https://forum.manjaro.org/t/screen-stuttering-lag-after-long-uptimes-on-nvidia-proprietary-drivers/34301) that if i just restart the display manager after connecting the monitor:
```
sudo systemctl restart display-manager
```
the issue is gone
System Info:
```
$ xfwm4 --version
This is xfwm4 version 4.18.0 (revision 7e7473c5b) for Xfce 4.18
Released under the terms of the GNU General Public License.
Compiled against GTK+-3.24.33, using GTK+-3.24.33.
Build configuration and supported features:
- Startup notification support: Yes
- XSync support: Yes
- Render support: Yes
- Xrandr support: Yes
- Xpresent support: Yes
- X Input 2 support: No
- Embedded compositor: Yes
- Epoxy support: Yes
```
```
libxfce4util7 4.18.1-2~bpo22.04 xubuntu-dev/staging/ubuntu jammy/main
xfce4 4.16 jammy/universe
```https://gitlab.xfce.org/xfce/xfwm4/-/issues/27New windows created at bottom of stack (when "New Window Focus" is not active)2023-08-19T20:56:58ZBugzilla MigrationNew windows created at bottom of stack (when "New Window Focus" is not active)## Submitted by Porcelain Mouse
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5581)](https://bugzilla.xfce.org/show_bug.cgi?id=5581)**
## Description
New windows appear at the bottom of the window stack, unl...## Submitted by Porcelain Mouse
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5581)](https://bugzilla.xfce.org/show_bug.cgi?id=5581)**
## Description
New windows appear at the bottom of the window stack, unless "New Window Focus" is active. New windows should appear at the top of the middle/normal window stack space, regardless of the "New Window Focus" setting, as is customary and common prior to v4.6.
Is this, perhaps, a side-effect of the 4.6 code change referenced in the Changelog as, "Do not automatically give focus to windows placed on lower layers, but focus those on upper layers at first map?" The new behavior is "new windows appear at bottom of stack, unless setting to force focus on new windows is enabled," which is not the same thing. Focusing and Window placement should be completely independent, and have always been.
This change is completely bizarre. I don't understand what was wrong with focusing on lower windows in the first place. I also don't understand why that behavior change resulted in a disruption of the behavior I like. Furthermore, shouldn't the default placement for new windows be at the top of the normal/middle stack space? Why is the default placement of new windows at the bottom of the stack space?
Version: 4.6.0Olivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/26Not possible to alt-tab during a drag-and-drop operation2023-08-19T20:56:58ZBugzilla MigrationNot possible to alt-tab during a drag-and-drop operation## Submitted by Olivier Robert
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5578)](https://bugzilla.xfce.org/show_bug.cgi?id=5578)**
## Description
In some windows manager, it is possible to cycle windows (...## Submitted by Olivier Robert
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5578)](https://bugzilla.xfce.org/show_bug.cgi?id=5578)**
## Description
In some windows manager, it is possible to cycle windows (atl-tab)/virtual desktops while performing a drag and drop. This functionality is extremely useful to move a file from a file manager to another for example.
The feature is lacking in Gnome/Metacity as well and a bug report has been filled for that. See:
http://bugzilla.gnome.org/show_bug.cgi?id=135056
The reason I quote this bug is that a patch (at least a hack) has been submited.
"Unfortunatly" the patch is for metacity, not for gtk, so we cannot directly benefit from it in xfce. However the diagnosis and the modification made to the code are perhaps transposable to xfce.
Version: 4.6.1Olivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/22<Alt>F8 shortcut minimizes window, not resize; no minimize window setting in ...2023-08-19T20:56:57ZBugzilla Migration<Alt>F8 shortcut minimizes window, not resize; no minimize window setting in Settings## Submitted by Robert Rothenberg
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5047)](https://bugzilla.xfce.org/show_bug.cgi?id=5047)**
## Description
When I use `<Alt>`F8, the window is usually minimized, ...## Submitted by Robert Rothenberg
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5047)](https://bugzilla.xfce.org/show_bug.cgi?id=5047)**
## Description
When I use `<Alt>`F8, the window is usually minimized, rather than giving me the ability to resize it.
I cannot find in the Settings menu an option for the keyboard shortcut to minimize the window, only to maximize or shade it. Judging form other shortcuts, I assume it should be `<Shift>``<Alt>`F8 instead.
Resetting defaults does not help.
Version: 4.6.0Olivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/21XFCE appears unable to properly run the compositing manager, and the desktop ...2023-08-19T20:56:57ZBugzilla MigrationXFCE appears unable to properly run the compositing manager, and the desktop will not render## Submitted by hel..@..il.com
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5037)](https://bugzilla.xfce.org/show_bug.cgi?id=5037)**
## Description
When I attempt to start the compositing manager from withi...## Submitted by hel..@..il.com
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#5037)](https://bugzilla.xfce.org/show_bug.cgi?id=5037)**
## Description
When I attempt to start the compositing manager from withing the settings manager, the visual appearances changes in that the desktop is rendered in parts as gray, where the color will "tear" when the windows are moved around on it. Compositing manager or no, the desktop will also fail to render, and does not respond when clicked on. The attempt to start the compositing manager takes many seconds, and the startup time of XFCE is significantly slower than 4.4.0, too--perhaps due to this error.
Version: 4.4.xOlivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/19Panel covers full screen Apps2023-08-19T20:56:57ZBugzilla MigrationPanel covers full screen Apps## Submitted by Nathan Howard
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#4973)](https://bugzilla.xfce.org/show_bug.cgi?id=4973)**
## Description
Programs run in full screen while using xfwm4 (without comp...## Submitted by Nathan Howard
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#4973)](https://bugzilla.xfce.org/show_bug.cgi?id=4973)**
## Description
Programs run in full screen while using xfwm4 (without composite in use) are covered by xfce4-panel.
Using metacity before running a fullscreen app is one known work around.
I am using Nvidia 180.29 drivers (always find it helps to mention this :) ) Using only Xfce Menu, task list, clock and notification area panel plugins.
Version: 4.5.99.1 (4.6 rc 1)Olivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/16Adjustment of Shadows2023-08-19T20:56:57ZBugzilla MigrationAdjustment of Shadows## Submitted by Ado
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#4447)](https://bugzilla.xfce.org/show_bug.cgi?id=4447)**
## Description
Not sure if it has been asked before or spoken about, but is it possi...## Submitted by Ado
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#4447)](https://bugzilla.xfce.org/show_bug.cgi?id=4447)**
## Description
Not sure if it has been asked before or spoken about, but is it possible to get teh Composite features enhanced? As in making shadows darker and further away , and maybe even a blur effect for translucent windows?Olivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/14windowmanager crashed if default font set to linux libertine2023-08-19T20:56:56ZBugzilla Migrationwindowmanager crashed if default font set to linux libertine## Submitted by David Voge
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#4274)](https://bugzilla.xfce.org/show_bug.cgi?id=4274)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en...## Submitted by David Voge
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#4274)](https://bugzilla.xfce.org/show_bug.cgi?id=4274)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1a1) Gecko/2008072306 Shiretoko/3.1a1
Build Identifier:
I had a problem to set default font to Linux Libertine. The result was, all guis crashed and only a grey screen like default X was showing up. i did not can changed default font again via X and must done via getty.
my system runs on a gentoo-x86_64 system and i use 4.5.x-svn checkouts for all xfce things. last checkout 24h.
Reproducible: Always
Steps to Reproduce:
1. select default windowmanager font to linux libertine
Actual Results:
all guis crashed and only a grey screen like default X was showing up and i did not can changed default font again via X and must done via getty.
Expected Results:
runs good :)
Version: 4.4.xOlivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/11borderless window maximization2023-08-19T20:56:54ZBugzilla Migrationborderless window maximization## Submitted by Simon Lipp
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#3786)](https://bugzilla.xfce.org/show_bug.cgi?id=3786)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1...## Submitted by Simon Lipp
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#3786)](https://bugzilla.xfce.org/show_bug.cgi?id=3786)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8.1.6) Gecko/20071029 Firefox/2.0.0.6
Build Identifier:
Hi all,
When I use xfwm4, I use a a lot the keyboard. Really a lot. In fact, I use my mouse only to resize or move windows. So, for a maximized windows, I don't need window borders nor title bar ("menus" ?). I did a quick & dirty patch (2 lines) to hide window decorations when a window is maximized. Now I give it to you as "proof of concept".
Any chance yo have this feature "out of the box" in the future ?
Reproducible: Always
Steps to Reproduce:
Version: 4.4.xOlivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/7request option to disable auto-raise on window cycle2023-08-19T20:56:54ZBugzilla Migrationrequest option to disable auto-raise on window cycle## Submitted by David Oostdyk
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#3416)](https://bugzilla.xfce.org/show_bug.cgi?id=3416)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;...## Submitted by David Oostdyk
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#3416)](https://bugzilla.xfce.org/show_bug.cgi?id=3416)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.5) Gecko/20070719 Firefox/2.0.0.5
Build Identifier:
I think it would be useful to add an option to disable auto-raise on window cycle (alt+tab). Usually when I cycle windows it is simply to change the keyboard focus, and auto-raise often covers other windows which I specifically don't want covered by the newly focused window.
Reproducible: Always
Steps to Reproduce:
1. open two windows and overlap them so one mostly covers the other
2. focus on the raised window
3. pretend you want to type on lower window while still seeing upper window...
4. press alt+tab, or whatever you use to cycle windows
Actual Results:
The window you wanted to type in has covered the window you wanted to still be able to see, thus ruining your afternoon.
Expected Results:
An xfwm4 option to prevent auto-raise!
Version: 4.4.xOlivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/5Option to not raise a window when using Alt+Tab2023-08-19T20:56:54ZBugzilla MigrationOption to not raise a window when using Alt+Tab## Submitted by Xavier Otazu
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#3274)](https://bugzilla.xfce.org/show_bug.cgi?id=3274)**
## Description
I would like to suggest a new focus behaviour for the xfwm4....## Submitted by Xavier Otazu
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#3274)](https://bugzilla.xfce.org/show_bug.cgi?id=3274)**
## Description
I would like to suggest a new focus behaviour for the xfwm4.
Actually, when changing focus using the Alt+Tab shorcut, the newly
focused windows raises. Could it be possible not to raise it?
This behaviour could be defined by the user in the settings manager with
an option similar to the "raise when click". In fact, even if "raise
when focus" is deactivated (which is really why I want when changing
using Alt+Tab) it raises.
I think this new behaviour is iseful when you want to maintain
some order on the overlaping windows but you want to change focus
between windows without changing its overlaping.
Version: 4.4.xOlivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/4Middle Clicking to Paste when Click to Focus is enabled does not focus the wi...2023-08-19T20:56:53ZBugzilla MigrationMiddle Clicking to Paste when Click to Focus is enabled does not focus the window that was pasted into## Submitted by Rob Smith
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#2861)](https://bugzilla.xfce.org/show_bug.cgi?id=2861)**
## Description
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux...## Submitted by Rob Smith
Assigned to **Olivier Fourdan `@olivier`**
**[Link to original bug (#2861)](https://bugzilla.xfce.org/show_bug.cgi?id=2861)**
## Description
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux x86_64; en) Opera 9.10
Build Identifier:
I have Click to Focus enabled
I select out of window 1, and middle click into window 2 to paste
in previous versions of xfce, it would focus window 2
currently it pastes into window 2, but window 1 is still focused
Reproducible: Always
Steps to Reproduce:
1. select out of window 1
2. middle click into window 2
Actual Results:
Pasted into window 2, but window 1 is still focused
Expected Results:
paste into window2 and window 2 gets focused
Version: 4.4.xOlivier FourdanOlivier Fourdanhttps://gitlab.xfce.org/xfce/xfwm4/-/issues/714Window Focus Becomes Erratic At Seemingly Random Times2023-08-12T03:42:30Z266-750BalloonsWindow Focus Becomes Erratic At Seemingly Random Times(Somewhat) Relevant Machine Specifications:
OS: Debian 12 (Bookworm, which is in Testing, which I think is in soft freeze)
Architecture: amd64
Motherboard: Aorus AX370 Gaming 5 (This is a Desktop Machine)
Memory: 32 GB (Just to make it c...(Somewhat) Relevant Machine Specifications:
OS: Debian 12 (Bookworm, which is in Testing, which I think is in soft freeze)
Architecture: amd64
Motherboard: Aorus AX370 Gaming 5 (This is a Desktop Machine)
Memory: 32 GB (Just to make it clear it's not a memory overflow or the like. Applications that function run at full performance.)
Input Devices: Logitech M510 Mouse, Logitech K350 Keyboard, and sometimes a no-name mouse and keyboard to control a VM.
Kernel: 6.1.20
XFWM Version: 4.18.0 revision 7e7473c5b (Although seems to have started some time around the introduction of the 4.18 desktop in general)
XFCE4 Panel Version: 4.18.2
Graphics: AMD Radeon RX 550 (Connected to Display), AMD Radeon RX 580 (I passthrough this GPU to VMs or sometimes use DRI_PRIME. It's usually not in use when the issue occurs, but a sufficient oddity to mention.)
Seemingly randomly, while using the desktop, window focus starts to become erratic. Usually, the problem starts when I try to use the Whisker Menu. It will not accept input, and one window seems to be stealing the focus, sometimes Firefox, sometimes XFCE4 terminal. Windows can no longer be dragged, and some don't accept mouse input, and others keyboard input. I try to restart both the window manager and the panel, to no avail.
I will try to get dmesg ouput to you shortly when the problem comes up again, but I have tried in vain to troubleshoot this many times, usually not seeing anything of relevance.
These are the applications and major processes usually running when the problem occurs (but not always): Amazon Music in Wine, Firefox ESR in firejail, VSCodium (It's just a deblobbed VSCode, which is an electron app), XFCE terminal, and redshift (night mode). I've sometimes suspected it to be Amazon Music, but the bug sometimes comes up even when it is not open.
Usually, I just end up going into a tty and restarting lightdm, which resets the desktop as well.
This looks similar in some respects to #632 and could be the same issue, but they were starting to come to the conclusion it might be an issue with their trackpad kernel driver, so for now, I am putting this as a distinct issue.
Thank you for your time. Let me know if I need to give more information.https://gitlab.xfce.org/xfce/xfwm4/-/issues/696No shadows under most popup / context menus2023-08-10T11:37:34ZStJimmyNo shadows under most popup / context menus## System Info
OS: Arch Linux
Xfce Version: 4.18
Xfwm version: 4.18.0
GTK3 version: 3.24.36 (gtk3-classic)
## Problem Description
When the option 'Show shadows under popup windows' in 'Window Manager Tweaks' is enabled, this only se...## System Info
OS: Arch Linux
Xfce Version: 4.18
Xfwm version: 4.18.0
GTK3 version: 3.24.36 (gtk3-classic)
## Problem Description
When the option 'Show shadows under popup windows' in 'Window Manager Tweaks' is enabled, this only seems to work for some menus. From what I observed, they do show for (at least) the following cases:
- All of Pale Moon's menus (kind-of GTK2);
- Qt5 applications (using the GTK2 plugin);
- Panel calendar;
- GTK2 and GTK3 application menubar popup menus (but only after having opened them at least once, and **NOT** their context menus).
- Context menus, and button menus (e.g. the filetype selector) in GTK3 applications again after having opened them once ~~(but not for GTK2 applications, at least not HexChat's menus)~~ They do show for GTK2 after opening once too, but only if no additional custom styling is applied through a user gtkrc (I don't understand this myself either), and not for 'root' context menus (e.g. HexChat's right-click menu);
- Xfce's panel menus, also only after opening them once before.
It is to note, though, that as soon as any application that shows this behavior is closed, after restarting the application(s) the menus are 'shadowless' again until they've been re-opened once.
Most other menus (mostly context/right-click menus, from what I gathered) and all tooltips belonging to either GTK2 or GTK3 applications do **not** show a shadow whatsoever. ~~I'm not actually sure if it's caused by gtk3-classic (a set of patches for GTK3 to make it behave more like GTK2, targeted mainly at 'classic' desktops like MATE and Xfce); using the vanilla GTK3 however yields to no comparable results as under it, menus are drawn with what seem to be (thin) client-side shadows.~~ As it seems to influence 'pure' GTK2 applications too, it's probably not an issue with my gtk3-classic build.
I've so far 'circumvented' this inconsistency by keeping popup shadows disabled; I'd like to use them, though.
### 'Investigation'
I've tried going through the sources and history of Xfwm4's compositor; however, it seems most things dealing with the logic of drawing shadows were added **well over fifteen (15) years ago** (according to git blame anyway), so I hold it for highly unlikely that it would reside therein. The diff between 4.16.1 and 4.18.0 also doesn't really show anything that, to my non-developer eyes, would cause this to happen.
Thanks a lot in advance, even if just for reading my novel ;)