Browse all patches

Author[edit | edit source]

Rüdiger Otte

Synopsis[edit | edit source]

This patch is rejected in 2008. You can see the patch and the discussion here.

What made the author suffer is that clicking raises windows. First make sure:

  • Open the configurator, choose "binding", and "window keymap". If "Button1-click" is bound to "raise-window-and-pass-through-click", then unbind it.
  • If you're window is raised by focusing, open the configurator "Focus" -> "auto raise". If that item isn't there, add (require ' in your ~/.sawfish/rc. Then uncheck the top item.

Some windows do raise even if you've done the above two. It's Sawfish bug, sorry, and you can avoid it by:

  • Open the configurator, choose "binding", and "window keymap". Assign "Button1-click" to "nop".

Discussion[edit | edit source]

You need to use a sloppy focus-mode, unless Sawfish will become unusable (say enter-exit or enter-click).

It still doesn't work in some cases.

Testcase If I have a gnome-terminal open and Firefox open when I switch the focus from gnome-terminal to Firefox Firefox insists on rising.
I can disable this rising with a Nop binding, but that makes the window manager otherwise unusable. Cyber rigger 16:47, January 7, 2010 (UTC)
You need to use a sloppy focus-mode Flashrider [Christopher Bratusek] 16:53, January 7, 2010 (UTC)
I assume you mean Sawfish_Configurator>Customize>Focus>enter-only.
This seems to help, although it changes the problem instead of fixing it. My question now is why Sawfish prevents the rogue window rise from Firefox using Sawfish_Configurator>Customize>Focus>enter-only and it does NOT prevent the rogue rise using Sawfish_Configurator>Customize>Focus>click.
I would be happy if applications were never allowed to do a rogue rise on a new click-to-focus.
Because the click focus mode is expected to focus & raise the window in general.
The old window manager olwm/olvwm didn't/doesn't raise a window when you did a left click on the contents of the window. It just changed the focus. Olwm/olvwm also prevents a raise from the same applications that are allowed to rise with sawfish. To raise with olwm/olvwm you have to do a short click on the border or title. A drag on the border would move but not rise. You can even move a window behind another window. I grew up on olvwm. To me, an assumed raise on click to focus is just wrong. If you used an analogy of sheets of paper on a desk, you wouldn't want a sheet to always jump to the top of the stack if you touched it. From what I have gathered, the raise on focus was easier to code in the early days (i.e. old non-X window managers). You didn't have to map around the hidden parts of the window. Most people never knew any different. It wasn't a matter of user preference. It was a matter of simplifying the coding.
For me, having a window manager that doesn't raise on focus is like having double the screen area when working with a lot of windows. Cyber rigger 18:39, January 16, 2010 (UTC)
But there could be an option for that. Flashrider [Christopher Bratusek] 17:33, January 11, 2010 (UTC)
You can suppress it. Open "focus" from configurator, and check "Whether focusing a window doesn't change it's position in the stack." I didn't know that "click" focus mode changes the stacking. I can't explain why not all windows are affected, though. - Teika kazura 06:32, January 12, 2010 (UTC)

How about these?

  • Another window manager, e.g. metacity, is running?
  • You've set 'raise on focus' in configurator -> 'matched window'?

- Teika kazura 07:20, January 9, 2010 (UTC).

Metacity is not installed.
I don't see any entries set in 'matched window'
Another application that insists on rising is Cyber rigger 17:26, January 11, 2010 (UTC)
I saw a related discussion here. If I understand it correctly, some applications are requesting a rise from the window manager at click-to-focus (whether a user wanted it or not). I would like to see a feature where the window manager denies that request and makes that window stay where it is. Isn't the "window manager" supposed to have the ultimate control of managing the windows? Cyber rigger 18:57, January 13, 2010 (UTC)

Ok, now I see you're right. Some indeed require raising. Thank you for patient investigations. It's recorded in Proposed Goals#Fill gap for EWMH (partially).
  The solution is described there. The original patch by Rüdiger Otte is not the solution, but a workaround, like binding 'nop', and is not to be adopted. I can't promise when it'll be fixed, since we don't have enough developers, and there's a workaround. But it will surely be done sometime. -- Teika kazura 05:10, January 16, 2010 (UTC)

Thanks for the entry. I just want to be able to tell these raise requests no, say put, I have other windows I need to see. Cyber rigger 18:45, January 16, 2010 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.