raise-on-click "buggy behavior"

[0n-s]

Expected behaviour

Windows should be able to raise themselves even when org/mate/marco/general/raise-on-click is false.

Actual behaviour

The "buggy behavior" mentioned in the description of the GSettings key org/mate/marco/general/raise-on-click is reproducible.

Steps to reproduce the behaviour

See description of the aforementioned GSettings key. This links to the original Metacity bug, with a reproducer in the 1st comment.

I would like to mention that Metacity got a bugfix for this issue shortly before it was put to rest. This patch applies cleanly to Marco without modification & that's what I've been doing on my system to fix this bug, but it'd be nice to see it fixed for everyone since it's already been fixed in the original for over a decade now.

MATE general version

1.26.2

Package version

1.26.2

Linux Distribution

NixOS

Link to bugreport of your Distribution (requirement)

[raveit65]

Pull request please?

[raveit65]

See description of the aforementioned GSettings key. This links to the original Metacity bug, with a reproducer in the 1st comment.

Please write it here....

[0n-s]

See description of the aforementioned GSettings key. This links to the original Metacity bug, with a reproducer in the 1st comment.

Please write it here....

Sure.

Consider the following Tk application:

#!/usr/bin/env wish

button .b \
   -text "Click to raise window 2" \
   -command "raise .t"
pack .b

toplevel .t
pack [label .t.l -text "window 2"]

wm group .t .

Run it. Move the button window over the top of "window 2". Press the button. If the option raise_on_click is set, it works correctly. If the option is unset, the raise event seems to be ignored, and "window 2" remains below the button window.

[raveit65]

Is there an real application which currently suffer by this issue? And can you provide steps to reproduce for this real application? ... because metacity report is from 2005

[raveit65]

Ok, the reproducer does what it promised.

But i can't remember that i ever run in this bug (if it really is one) with an application because raise-on-click is set to true on my systems. I never changed the default setting.

[0n-s]

Is there an real application which currently suffer by this issue? And can you provide steps to reproduce for this real application? ... because metacity report is from 2005

Somewhat realistic example:

1. Open Caja to a location where you have a very nice PDF.
2. Open the PDF with Atril.
3. Stack Atril below Caja.
4. Repeat step 2, with the exact same PDF.

One would expect Atril to raise itself at step 4, & that is what it does when raise-on-click is true (default). But when we set it to false, Marco ignores its request to do so, & it just stays below Caja, which can be especially confusing if you have Caja maximized.

& that's what the "buggy behavior" is: a setting that controls whether windows should be raised when their area is clicked, also additionally controls whether requests to raise windows by applications themselves are honored, which is completely unrelated.

[raveit65]

This is reproducible and i consider that as wrong behavior, and PR fixes it. But i can't imagine any weird use case to disable the gesettings key :-)

[0n-s]

Well, either disabling raise on click or being able to set a raise delay is really the only sane way to go about a focus-follows-mouse focus model (org/mate/marco/general/focus-mode = 'mouse'), otherwise it's just far too easy to completely destroy your window placement.

Focus follows mouse is pretty great for efficiency only if you can tweak those behaviors, otherwise it's arguably objectively worse than even click to focus. :)

P.S. a little unintuitive, but raise on click is actually raise on focus in most WMs, including Marco AFAIK, so focus follows mouse with raise on click means you raise every single window your cursor passes through instantly. Not the only reason you'd want to disable raise on click with mouse focus, but it does make it virtually unusable.