Which Xfce Gitlab project should I report this issue to?

NM64 · 2024-10-29 19:28:53

I was told that xfwm4 is the wrong project for the following issue, but I've no idea which project would be the correct one:

https://gitlab.xfce.org/xfce/xfwm4/-/issues/818

In particular, my initial thought would be that it's the fault of something upstream but, as I state on the issue in question, it doesn't occur everywhere (the File, Edit, View, etc menus in Thunar being a key exception, though it does still occur with Thunar's context menus), and it seems to happen on Qt-based desktop environments as well as Gtk-based ones.

Last edited by NM64 (2024-10-29 19:31:02)

eriefisher · 2024-10-30 19:05:32

The fact that it's happening across environments tells me it a hardware or driver issue. Possibly an X setting but unlikely. I have never seen this behavior myself.

NM64 · 2024-10-30 19:19:29

eriefisher wrote:

The fact that it's happening across environments tells me it a hardware or driver issue.

Not to discount your idea, but this issue occurs across a slew of multiple hardware and distros, not to mention has existed for several years now. I may not have really any software dev ability, but if you want someone that can test lots of different hardware then I'm the person! big_smile (as long as it's not very new hardware of course...I've only a single DDR4 motherboard for example, and no DDR5).

(that being said, there's a similar extremely prevalent cross-distro cross-hardware "issue" where 1920x1080 60Hz over HDMI commonly defaults to using chroma sub-sampling with limit color range, presumably out of the assumption of TVs wanting - maybe particularly old TVs did, but even my 2013 TV can do RGB)

Honestly, in my view, it simply seems like a design oversight as it's something I only noticed when I moved over from Windows a few years ago.

If you've never seen this happen, then may I suggest you actively sort of try instigating the issue? An easy way not demonstrated is with right-click context menus - simply be having your mouse cursor moving towards the direction of where the context menu will appear while making your right-click, all while making sure that your click isn't super-fast either but isn't really held-down for too long (~100ms as demonstrated in my video is a good length). The trick is that your mouse cursor must be moving (even if just 1 pixel) between the time that you initially press the button and the time you release the button.

...alternatively, as I was typing this, I just realized - this probably only exists on desktops or older laptops that have physical mouse buttons. Are you by chance a laptop user? I can't see how this would even be possible if using tap-to-click for example.

Last edited by NM64 (2024-10-30 19:28:19)

eriefisher · 2024-10-31 10:34:46

Yes, I am on a laptop, but I do have physical L&R click buttons. Not just an area on the touch pad.

Xfce Forum

Sub domains

#1 2024-10-29 19:28:53

Which Xfce Gitlab project should I report this issue to?

#2 2024-10-30 19:05:32

Re: Which Xfce Gitlab project should I report this issue to?

#3 2024-10-30 19:19:29

Re: Which Xfce Gitlab project should I report this issue to?

#4 2024-10-31 10:34:46

Re: Which Xfce Gitlab project should I report this issue to?

Board footer