Raise/lower windows during move/resize?

[cybersphinx]

Hello,

Currently I have bound my mouse’s side buttons to move/resize windows like this:

DestroyFunc user_move
AddToFunc user_move

• C Move

Mouse 9 WSFT A user_move

That works quite well, but sometimes the window I move ends up below is below another one, so I’d like to make the scroll wheel raise/lower the window while still moving it. My first try was

DestroyFunc user_move
AddToFunc user_move

• I Mouse 5 WSFT A Lower
• I Mouse 4 WSFT A Raise
• C Move
• I Mouse 5 WSFT A -
• I Mouse 4 WSFT A -

But that doesn’t work, since any button press just ends the moving without doing what it’s bound to. From testing just the mouse bindings it seems I also have to prevent the lowered window from losing focus if the cursor then touches another window, but the main question is: Is it possible to execute the raise/lower command without ending the moving?

[thomasadam]

Style * ClickToFocusRaises
DestroyFunc Foo
AddToFunc Foo
+ I Raise
+ C Move

– Thomas Adam

[cybersphinx]

Well, that solves the case mentioned in my first post, but that’s just a part of the problem (though the most usual case I guess).

I want to move a window, without raising by default. Then when I notice it is obscuring/obscured by another window, I want the option to raise/lower it. Or in other words, press the button and put the window where I want it, in all three dimensions.

[thomasadam]

@cybersphinx

I want to move a window, without raising by default. Then when I notice it is obscuring/obscured by another window, I want the option to raise/lower it. Or in other words, press the button and put the window where I want it, in all three dimensions.

You can’t. The reason you can’t will become clear when I describe what happens…

To have more than one operand applied on a window (in your case, a conditional raise/move on a window) requires writing a function to perform both these actions. However, as soon as you bind any action to a function and apply it to a window, the pointer is grabbed – this means at the point you’re moving the window, only that operation is in effect until it’s over anf other things can happen.

So… you have some options open to you:

1. Use what I gave you; effectively cutting your loses;

or:

2. You can still raise/lower the window after it has moved. So for instance, let’s say you’re moving a window and it happens to now be under another window because it was never raised. You could do this:

DestroyFunc SomeFunc
AddToFunc   SomeFunc
+ I Move
+ I PipeRead `echo ThisWindow (!Visible|Overlapped|!Raised) Raise`

Note what’s happening here. The move command is the first thing that happens when the function is invoked (within the Immediate action). When that’s done, the PipeRead comes along and raises the window if it’s obscurred.

– Thomas Adam

[cybersphinx]

@thomasadam

To have more than one operand applied on a window (in your case, a conditional raise/move on a window) requires writing a function to perform both these actions. However, as soon as you bind any action to a function and apply it to a window, the pointer is grabbed – this means at the point you’re moving the window, only that operation is in effect until it’s over anf other things can happen.

I feared as much.

[code]
DestroyFunc SomeFunc
AddToFunc SomeFunc

• I Move
• I PipeRead echo ThisWindow (!Visible|Overlapped|!Raised) Raise
  [/code]Now this looks nice (and after enclosing the echoed text in quotes it actually works). Though I don’t really understand what the PipeRead and two of the three conditions do, it doesn’t seem to do anything different than just using “+ I ThisWindow (Overlapped) Raise”.

Anyway, this is approaching a usable compromise, if I can get it to only raise the window if it’s completely obscured. I’d have thought “ThisWindow (!Visible) Raise” would do that, but it doesn’t. Somehow the “visible” condition seems broken, it seems to be always true, regardless if the window is actually visible or not (I’m using the Debian package version 1:2.5.26-2, if that matters).

[thomasadam]

@cybersphinx

Though I don’t really understand what the PipeRead and two of the three conditions do, it doesn’t seem to do anything different than just using “+ I ThisWindow (Overlapped) Raise”.

Visible is completely unobstructed. Overlapped is if part of the window is exposed.

@cybersphinx

Anyway, this is approaching a usable compromise, if I can get it to only raise the window if it’s completely obscured. I’d have thought “ThisWindow (!Visible) Raise” would do that, but it doesn’t. Somehow the “visible” condition seems broken, it seems to be always true, regardless if the window is actually visible or not (I’m using the Debian package version 1:2.5.26-2, if that matters).

Well, that’s why I included “!Raised” since that covers all of them really; note that the condition Visible will not work if you have any kind of compositing manager running.

– Thomas Adam

[cybersphinx]

@thomasadam

Visible is completely unobstructed. Overlapped is if part of the window is exposed.

Well, I got that much. The question was, why did you choose all three? “!Raised” alone seems to be always true when used on a lowered window, so the other two conditions are irrelevant.

Though by my experimentation, “visible” is always true, and “overlapped” is true when the window is at least partly covered (not partly exposed - and I don’t have any composition manager running). Tested with the following[code]DestroyFunc user_move
AddToFunc user_move

• I Move
• I ThisWindow (XXX) Raise[/code]with the condition in place of XXX. Then I use two windows, raise one, and move the lowered window. With “!visible”, the window is never raised after moving (always with “visible”), and with “overlapped” when it is at least partly covered by another window.