FVWM: limiting window movement to working area

[JUNG, Christian]

Hello,

is it possible to limit the movement of a window to the area defined by EWMHBaseStrut?

Some details: I've got a FvwmTaskBar at the top of my desk and define the working area with the following commands:

AddToFunc StartFunction
+ I Module FvwmTaskBar
+ I Wait FvwmTaskBar
+ I Next (FvwmTaskBar, CirculateHit) EwmhBaseStruts 0 0 $[w.height] 0

Style "FvwmTaskBar" !Title,!Handles,BorderWidth 4,Sticky,StaysOnTop,WindowListSkip,CirculateSkip,ClickToFocusPassesClick
*FvwmTaskBar: Geometry +0+0
*FvwmTaskBar: UseSkipList
*FvwmTaskBar: AutoStick
*FvwmTaskBar: StartName
*FvwmTaskBar: StartIcon taskbar_icon.xpm
*FvwmTaskBar: StartCommand Menu StartMenu Rectangle $widthx$height+$left+$top 0 +100
*FvwmTaskBar: NoBrightFocus
*FvwmTaskBar: TipsColorset 16
*FvwmTaskBar: Colorset 17
*FvwmTaskBar: FocusColorset 18
*FvwmTaskBar: IconColorset 19
*FvwmTaskBar: Pad 0
*FvwmTaskBar: ClockFormat %H:%M
*FvwmTaskBar: UpdateInterval 60

The window placement and e.g. maximizing works perfectly and honors the working area but a window can be moved under the taskbar rendering the title bar unusable. The windows can be moved partly from the desk on all sides too. Is there a possibility to "stop" the window before crossing the boundaries of the working area?

Thanks a lot!


Chris

SHS SERVICES GmbH - Informatik
Hofstattstraße 106a
D-66333 Völklingen

phone: [phone]
fax: [phone]
www: http://www.shsservices.org/

SHS SERVICES GmbH, Firmensitz: Bismarckstrasse 145, 66333 Völklingen
Registergericht: Amtsgericht Saarbrücken HRB 14092
Geschäftsführer: Martin Baues, Dr. B

[Thomas Adam]

Post by JUNG, Christian
Hello,
is it possible to limit the movement of a window to the area defined by EWMHBaseStrut?

The Move command honours the EWMH Working Area by default when used
NON-interactively, but for interactive moves, no. You're free to move it
anywhere.

I toyed with the idea of having wall-boundaries where windows couldn't be
moved, but due to the way one can configure their DesktopSize, and flip
between pages when resizing/moving windows, etc., soon came to the
realisation it becomes impossible to give a realistic configuration.

Therefore, you won't ever get hard-walled areas honouring the EWMH Working
Area for interactive window moves.

As for your current problem, just use Layers, perhaps?

-- Thomas Adam

[Michael Großer]

Post by Thomas Adam

Post by JUNG, Christian
Hello,
is it possible to limit the movement of a window to the area defined by EWMHBaseStrut?

The Move command honours the EWMH Working Area by default when used
NON-interactively, but for interactive moves, no. You're free to move it
anywhere.
I toyed with the idea of having wall-boundaries where windows couldn't be
moved, but due to the way one can configure their DesktopSize, and flip
between pages when resizing/moving windows, etc., soon came to the
realisation it becomes impossible to give a realistic configuration.
Therefore, you won't ever get hard-walled areas honouring the EWMH Working
Area for interactive window moves.
As for your current problem, just use Layers, perhaps?
-- Thomas Adam

If I would have a requirement to forbid windows to be moved beyond
a thought border, I would try to write some code, which becomes
active as soon as the user stops manually moving the window.
This code would move the window back then.

Sounds dirty, I know, but why not?

:-)
Michael

[Thomas Adam]

Post by Michael Großer

Post by Thomas Adam

Post by JUNG, Christian
Hello,
is it possible to limit the movement of a window to the area defined by EWMHBaseStrut?

The Move command honours the EWMH Working Area by default when used
NON-interactively, but for interactive moves, no. You're free to move it
anywhere.
I toyed with the idea of having wall-boundaries where windows couldn't be
moved, but due to the way one can configure their DesktopSize, and flip
between pages when resizing/moving windows, etc., soon came to the
realisation it becomes impossible to give a realistic configuration.
Therefore, you won't ever get hard-walled areas honouring the EWMH Working
Area for interactive window moves.
As for your current problem, just use Layers, perhaps?
-- Thomas Adam

If I would have a requirement to forbid windows to be moved beyond
a thought border, I would try to write some code, which becomes
active as soon as the user stops manually moving the window.
This code would move the window back then.
Sounds dirty, I know, but why not?

Then you can make use of blocking PipeRead to do things like:

DestroyFunc foo
AddToFunc foo
+ I PipeRead `echo Move`
+ I PipeReaad `[ $[w.x] -lt $SOME_VALUE ] && echo "Move somewhere else"`

-- Thomas Adam

[JUNG, Christian]

Post by Thomas Adam
DestroyFunc foo
AddToFunc foo
+ I PipeRead `echo Move`
+ I PipeReaad `[ $[w.x] -lt $SOME_VALUE ] && echo "Move somewhere else"`

FvwmEvent can be used to trigger the check of the window placement:

DestroyFunc StartFunction
AddToFunc StartFunction
+ I Module FvwmEvent
+ I Module FvwmTaskBar
+ I Wait FvwmTaskBar
+ I Next (FvwmTaskBar, CirculateHit) MaintainWorkingArea

DestroyFunc MaintainWorkingArea
AddToFunc MaintainWorkingArea
+ I SetEnv WORKAREA_LEFT_MARGIN 0
+ I SetEnv WORKAREA_RIGHT_MARGIN 0
+ I SetEnv WORKAREA_TOP_MARGIN $[w.height]
+ I SetEnv WORKAREA_BOTTOM_MARGIN 0
+ I EwmhBaseStruts 0 0 $[w.height] 0

*FvwmEvent: Cmd
*FvwmEvent: configure_window "Current CheckWindowPlacement"

DestroyFunc CheckWindowPlacement
AddToFunc CheckWindowPlacement
+ I PipeRead '[ $[w.x] -lt $[WORKAREA_LEFT_MARGIN] ] && echo Move $[WORKAREA_LEFT_MARGIN]p w0'
+ I PipeRead '[ $[w.y] -lt $[WORKAREA_TOP_MARGIN] ] && echo Move w0 $[WORKAREA_TOP_MARGIN]p'

Note that CheckWindowPlacement only assures that the window can not escape the left and top of the working area which is sufficient in my case. All other cases would need more complex logic (e.g. handle cases where window is larger than working area). This could be easily done by a shell script on the other hand.


Chris

[Thomas Adam]

Post by JUNG, Christian

Post by Thomas Adam
DestroyFunc foo
AddToFunc foo
+ I PipeRead `echo Move`
+ I PipeReaad `[ $[w.x] -lt $SOME_VALUE ] && echo "Move somewhere else"`

It can, but note that this hypothetical "foo" function _explicitly_
indicates moving the window. Listening for ConfigureNotify events via
FvwmEvent as you're proposing also has the added (dis)advantage that
*resizing* the window, be it deliberately or through program-specified
reasons, is then taken in to consideration.

You probably don't want that in all cases, I'd have thought.

Post by JUNG, Christian
DestroyFunc StartFunction
AddToFunc StartFunction
+ I Module FvwmEvent
+ I Module FvwmTaskBar
+ I Wait FvwmTaskBar
+ I Next (FvwmTaskBar, CirculateHit) MaintainWorkingArea
DestroyFunc MaintainWorkingArea
AddToFunc MaintainWorkingArea
+ I SetEnv WORKAREA_LEFT_MARGIN 0

Use InfoStoreAdd here.

Post by JUNG, Christian
+ I SetEnv WORKAREA_RIGHT_MARGIN 0
+ I SetEnv WORKAREA_TOP_MARGIN $[w.height]
+ I SetEnv WORKAREA_BOTTOM_MARGIN 0
+ I EwmhBaseStruts 0 0 $[w.height] 0
*FvwmEvent: Cmd

This isn't needed anymore.

Post by JUNG, Christian
*FvwmEvent: configure_window "Current CheckWindowPlacement"

You don't need "Current" here -- there is *nothing* to say that you're
moving a window with explicit focus (c.f. NeverFocus), and also the more
glaring reason that FvwmEvent is already running in a window context, making
the explicit check for "Current" a mistake, or a rather silly limitation.

-- Thomas Adam

[JUNG, Christian]

Post by Thomas Adam

Post by JUNG, Christian

Post by Thomas Adam
DestroyFunc foo
AddToFunc foo
+ I PipeRead `echo Move`
+ I PipeReaad `[ $[w.x] -lt $SOME_VALUE ] && echo "Move

somewhere else"`
It can, but note that this hypothetical "foo" function _explicitly_
indicates moving the window. Listening for ConfigureNotify events via
FvwmEvent as you're proposing also has the added (dis)advantage that
*resizing* the window, be it deliberately or through program-specified
reasons, is then taken in to consideration.
You probably don't want that in all cases, I'd have thought.

You're right. Resizing a window should be handled differently (the window should be resized to the working area for example and not moved after resizing it).

The explicit "Move" in your example works only for click-and-move and not drag-move operations or am I wrong?

Post by Thomas Adam

Post by JUNG, Christian
DestroyFunc MaintainWorkingArea
AddToFunc MaintainWorkingArea
+ I SetEnv WORKAREA_LEFT_MARGIN 0

Use InfoStoreAdd here.

Hmm. I'm currently working with version 2.5.26; but I'll update soon... Promised! :-)

Post by Thomas Adam

Post by JUNG, Christian
*FvwmEvent: Cmd

This isn't needed anymore.

Post by JUNG, Christian
*FvwmEvent: configure_window "Current CheckWindowPlacement"

You don't need "Current" here -- there is *nothing* to say that you're
moving a window with explicit focus (c.f. NeverFocus), and
also the more
glaring reason that FvwmEvent is already running in a window
context, making
the explicit check for "Current" a mistake, or a rather silly
limitation.

Thanks a lot for the hints! Removed this stuff...

[Thomas Adam]

This post might be inappropriate. Click to display it.

[JUNG, Christian]

As I said before -- Move honours the EWMH working area by default when used
EwmhBaseStruts 100 100 100 100
Pick Move 0 0
[ Move the window else, somewhere randomly ]
Pick Move 0 0 ewmhiwa

This seems to work with fvwm 2.6 or newer. Currently I'm stuck to 2.5.

But nevertheless I can only pick the window at the titlebar (single click, left mouse button) and then move the window if I try something like this:

Emulate Win
Mouse 1 T A Function MoveWindow
DestroyFunc MoveWindow
AddToFunc MoveWindow
+ I PipeRead 'echo Move'
+ I PipeRead '[ $[w.x] -lt $[WORKAREA_LEFT_MARGIN] ] && echo "Echo window left boundary"'

But I'd like to hold down the mouse button and move the window until the button is released. Is there a possibility to accomplish this or is there a way to execute a function after the window has been placed?


Chris

[JUNG, Christian]

I've found a way to work around this messy FvwmEvent-stuff:

Mouse 1 T A Function MoveWindow
DestroyFunc MoveWindow
AddToFunc MoveWindow
+ M Move
+ M PipeRead '[ $[w.x] -lt $[WORKAREA_LEFT_MARGIN] ] && echo Move $[WORKAREA_LEFT_MARGIN]p w0'
+ M PipeRead '[ $[w.y] -lt $[WORKAREA_TOP_MARGIN] ] && echo Move w0 $[WORKAREA_TOP_MARGIN]p'

[Jaimos F Skriletz]

Post by Thomas Adam
I toyed with the idea of having wall-boundaries where windows couldn't
be moved, but due to the way one can configure their DesktopSize, and
flip between pages when resizing/moving windows, etc., soon came to
the realisation it becomes impossible to give a realistic configuration.
Therefore, you won't ever get hard-walled areas honouring the EWMH
Working Area for interactive window moves. As for your current
problem, just use Layers, perhaps? -- Thomas Adam

Would it be possible and useful to set an invisiable boundary that could
be used with SnapAttraction or EdgeMoveDelay/EdgeMoveResitance over the
EWMH boundaries. This way things can still be moved anywhere but there
is a bit of resistance or snaping to the borders (even if there isn't a
pannel there to snap to)? I am thinking allowing the EWMH bounderies to
behave more like the edge of the pages when moving things around, and
something that is configurable to the amount of delay/resistance needed?

jaimos

[Thomas Adam]

Post by Jaimos F Skriletz

Post by Thomas Adam
I toyed with the idea of having wall-boundaries where windows
couldn't be moved, but due to the way one can configure their
DesktopSize, and flip between pages when resizing/moving windows,
etc., soon came to the realisation it becomes impossible to give a
realistic configuration.
Therefore, you won't ever get hard-walled areas honouring the EWMH
Working Area for interactive window moves. As for your current
problem, just use Layers, perhaps? -- Thomas Adam

Would it be possible and useful to set an invisiable boundary that
could be used with SnapAttraction or EdgeMoveDelay/EdgeMoveResitance
over the EWMH boundaries. This way things can still be moved
anywhere but there is a bit of resistance or snaping to the borders
(even if there isn't a pannel there to snap to)? I am thinking
allowing the EWMH bounderies to behave more like the edge of the
pages when moving things around, and something that is configurable
to the amount of delay/resistance needed?

You can already do this for the pan windows surrounding the screen (which is
how EdgeResistance is able to work for page boundaries, etc.) Extending
this for the working area would not be feasible for EWMH-specific window
types such as docks. So its implementation cannot depend on augmenting the
way pan windows work at the moment.

-- Thomas Adam