FVWM: Two questions, maybe two new options to ResizeMove

[Tapio Luukkanen]

Hello all,

Question 1: I probably should have asked publicly before starting to
experiment with the approach outlined here -- is there any cleaner,
already existing way to achieve these "goals"?

So ... I was experimenting with the PipeRead command to create a
"smart" scroll-wheel-based non-interactive window resizing mechanism
that would choose the edge where the resize occurs based on where the
window midpoint is located on the screen (eventually using maybe other
criteria as well).

The initial goal of this "smartness" was this: if the window midpoint is
in the "left half" of screen, its left edge should stay in place. If in the
"right half", then the right edge, and similarly for "top half" and top
edge, "bottom half" and bottom edge.

To achieve this, wrote a shell script ("fvwm-resizer-tool") that is passed
some fvwm state, and the script then emits commands for PipeRead:

## Resize using default increments in 'fvwm-resizer-tool'
Mouse 4 WT CS ResizerFunc y_minus
Mouse 5 WT CS ResizerFunc y_plus
Mouse 4 WT C4 ResizerFunc x_minus
Mouse 5 WT C4 ResizerFunc x_plus

## Resize with explicit size changes
Mouse 4 WT CSM ResizerFunc y_minus w-20c
Mouse 5 WT CSM ResizerFunc y_plus w+20c
Mouse 4 WT C4M ResizerFunc x_minus w-20c
Mouse 5 WT C4M ResizerFunc x_plus w+20c

DestroyFunc ResizerFunc
AddToFunc ResizerFunc
+ I ThisWindow PipeRead "fvwm-resizer-tool \
desk $[desk.n] \
deskpages $[desk.pagesx] $[desk.pagesy] \
deskwidhei $[desk.width] $[desk.height] \
page $[page.nx] $[page.ny] \
pages $[page.pagesx] $[page.pagesy] \
ewmh-wa $[wa.x] $[wa.y] $[wa.width] $[wa.height] \
ewmh-dwa $[dwa.x] $[dwa.y] $[dwa.width] $[dwa.height] \
win $[w.id] \
win-xy $[w.x] $[w.y] win-widhei $[w.width] $[w.height] \
cw-xy $[cw.x] $[cw.y] cw-widhei $[cw.width] $[cw.height] \
pointer-xy $[pointer.x] $[pointer.y] \
pointer-wxy $[pointer.wx] $[pointer.wy] pointer-cxy
$[pointer.cx] $[pointer.cy] \
vp-xy $[vp.x] $[vp.y] vp-widhei $[vp.width] $[vp.height] \
-resize $[*] "


The shell script parses these arguments and eventually emits commands
like these:

ResizeMove KeepRight w-20c keep ## reduce width, keep right edge
in place
ResizeMove KeepBottom keep w+25c ## increase height, keep bottom in
place
Resize keep w+25c ## increase height normally
Resize w-20c keep ## decrease width normally

To implement these new options KeepBottom and KeepRight for
"ResizeMove" move_resize.c and geometry.c needed to be patched
slightly (please contact if interested).

Question 1 restated: can anyone suggest better approaches?

Question 2:

Another (somewhat unrelated) thing to note (from the ResizerFunc call
above) is that I can't seem to find a way to pass the variables
$[page.nx] and $[page.ny] to the script as anything else than "0 0" --
they are maybe expanded at the time when the .fvwm2rc script is being
evaluated?

So, is there a way to ensure $[page.nx] and $[page.ny] are evaluated
"lazily" at
function call time, to have their correct values for example when I am
"viewing page 1 7"?

--Tapio

[Thomas Adam]

On Sun, Sep 14, 2014 at 05:00:21PM +0300, Tapio Luukkanen wrote:
> So ... I was experimenting with the PipeRead command to create a
> "smart" scroll-wheel-based non-interactive window resizing mechanism
> that would choose the edge where the resize occurs based on where the
> window midpoint is located on the screen (eventually using maybe other
> criteria as well).

The closest you have now is the direction mechanism which will calculate
which border to warp to based on the pointer's position, relative to the
window which is to be resized. How is having a window's midpoint
position relative to the screen useful?

> To implement these new options KeepBottom and KeepRight for
> "ResizeMove" move_resize.c and geometry.c needed to be patched
> slightly (please contact if interested).

By all means send them, although this sounds so niche that I'm dubious
as to their usefulness.

> Question 1 restated: can anyone suggest better approaches?

Not really.

> Question 2:
>
> Another (somewhat unrelated) thing to note (from the ResizerFunc call
> above) is that I can't seem to find a way to pass the variables
> $[page.nx] and $[page.ny] to the script as anything else than "0 0" --
> they are maybe expanded at the time when the .fvwm2rc script is being
> evaluated?
>
> So, is there a way to ensure $[page.nx] and $[page.ny] are evaluated
> "lazily" at
> function call time, to have their correct values for example when I am
> "viewing page 1 7"?

Try doubling up the dollar signs:

$$[page.nx] $$[[page.ny]

The expansion rules happen each time a command is encountered,
effectively expanding forwards for each command. In your function case,
there's about two or three commands which might have expanded them.
You'll need to experiment.

-- Thomas Adam

--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

[Tapio Luukkanen]

On 09/14/14 17:09, Thomas Adam wrote:
> On Sun, Sep 14, 2014 at 05:00:21PM +0300, Tapio Luukkanen wrote:
>> So ... I was experimenting with the PipeRead command to create a
>> "smart" scroll-wheel-based non-interactive window resizing mechanism
>> that would choose the edge where the resize occurs based on where the
>> window midpoint is located on the screen (eventually using maybe other
>> criteria as well).
>
> The closest you have now is the direction mechanism which will calculate
> which border to warp to based on the pointer's position, relative to the
> window which is to be resized. How is having a window's midpoint
> position relative to the screen useful?

Well, maybe I'm too fixed in my ways. but I've not yet grown used to
the tiling idiom.

Normally, on any one page I have a large number of emacs and xterm
windows open, side-by side or on top of each other, sometimes
overlapping, sometimes not. Consider windows AA - HH:

.AA..........
.AA.BBB...DD.
.AA.BBBCC.DD.
.EE.BBBCC.DD.
.EE.FF.CC.HH.
.EE.FF.GG.HH.

Now, if the position (quadrant) of the window center is not taken into
account, each window will grow downwards and to the right... and
eventually out of view. For windows at the right and bottom halfs,
shrinking their size would move them farther from the border. These
behaviours annoy me. I also want to avoid manual resizing from the
border.

So, if I want to grow windows EE, FF, CC, GG, or HH vertically, I
want them to grow "upwards in place", hence their bottom edge should
stay fixed as also when shrinking their vertical size. When resizing
DD or HH horizontally, their right edge needs to stay fixed.

Other possibilities are possible -- maybe windows BB and FF should
grow to the left and CC and GG to the right? Or maybe BB, CC, FF and
GG should grow or shrink vertically with their midpoint staying in
place? These behaviours might depend on resolution of current screen?
Need to experiment more until this stops (or starts) making sense...

>> To implement these new options KeepBottom and KeepRight for
>> "ResizeMove" move_resize.c and geometry.c needed to be patched
>> slightly (please contact if interested).
>
> By all means send them, although this sounds so niche that I'm dubious
> as to their usefulness.

The changed 3 files and the shell script will be for some time
available at WWW-directory http://talux.dynalias.com/fvwm/

But IMO these changes are not yet mature enough to be merged into the
main CVS. Especially, as this is the first time I'm tinkering with
window management code, and to understand the workings of current
logic lots of debugging printouts were added. The tentative changes in
resize_move_window() and constrain_size() probably need redesign or at
least very thorough testing.

So... I fear the current state of these changes requires such cleanup and
testing that would only distract anyone from other, more meaningfully
productive work...


>> Question 2:
>>
> Try doubling up the dollar signs:
>
> $$[page.nx] $$[[page.ny]

This solved the problem.

Thank you for your time and insights!

Tapio Luukkanen

[Dominik Vogt]

On Sun, Sep 14, 2014 at 11:08:20PM +0300, Tapio Luukkanen wrote:
> On 09/14/14 17:09, Thomas Adam wrote:
> > The closest you have now is the direction mechanism which will calculate
> > which border to warp to based on the pointer's position, relative to the
> > window which is to be resized. How is having a window's midpoint
> > position relative to the screen useful?

> Now, if the position (quadrant) of the window center is not taken into
> account, each window will grow downwards and to the right... and
> eventually out of view. For windows at the right and bottom halfs,
> shrinking their size would move them farther from the border. These
> behaviours annoy me. I also want to avoid manual resizing from the
> border.

I find the idea interesting, nad maybe I've tried something similar
in the past, by I can't remember. But there is an odd script on my
disk that may help you (see attachment).

The most difficult part of this is to find a natural way to say in
*which* direction you want to resize the window. Then it should be
not too difficult to issue commands to change the size by one
character or ten pixels; the resizemove command has syntax to
support this. e.g. "resize keep w+1c".

Normally you would use the gravity of a window to determine the
direction in which it grows.

Ciao

Dominik ^_^ ^_^

--

Dominik Vogt

[Tapio Luukkanen]

On 09/15/14 21:50, Dominik Vogt wrote:
>> Now, if the position (quadrant) of the window center is not taken into
>> account, each window will grow downwards and to the right... and
>> eventually out of view. For windows at the right and bottom halfs,
>> shrinking their size would move them farther from the border. These
>> behaviours annoy me. I also want to avoid manual resizing from the
>> border.
> I find the idea interesting, nad maybe I've tried something similar
> in the past, by I can't remember. But there is an odd script on my
> disk that may help you (see attachment).
Thanks. Slightly more elegant than my heavy-handed approach.
> The most difficult part of this is to find a natural way to say in
> *which* direction you want to resize the window. Then it should be
> not too difficult to issue commands to change the size by one
> character or ten pixels; the resizemove command has syntax to
> support this. e.g. "resize keep w+1c".
Yes, that's why the script gets all kinds of state variables to allow
easier experimenting.
> Normally you would use the gravity of a window to determine the
> direction in which it grows.

Each window's gravity would then need to be changed whenever its
position or size changes enough according to some heuristic. At least
there would be some hope for those poor windows that find themselves at
the lower half of the screen -- they would be compensated with upwards
mobile Northern gravity :-)

But some windows might still feel so self-important or satisfied with
themselves that they want to swell in place.

Thanks for your thoughts!

Tapio

[Dominik Vogt]

> > Normally you would use the gravity of a window to determine the
> > direction in which it grows.
>
> Each window's gravity would then need to be changed whenever its
> position or size changes enough according to some heuristic. At least
> there would be some hope for those poor windows that find themselves at
> the lower half of the screen -- they would be compensated with upwards
> mobile Northern gravity :-)
>
> But some windows might still feel so self-important or satisfied with
> themselves that they want to swell in place.

This is already an issue with some windows. Most do not set a gravity
(disregarding all the broken toolkits that use StaticGravity, that is)
regardless of where they end up on the screen. There are these stupid
Java applications that start their windows with a small size, then
calculate the contents and resize them to the final size. Often, when
the window is placed near the right or bottom border of the screen,
resizing results in part of the window being off screen. This has been
bugging me for a long time and eventually I'll make a patch for this,
e.g. a new stlye "PResizeKeepOnScreen" that tells fvwm to use a certain
gravity automatically when resizing the window makes it hit a screen
border.

Maybe the following would be a working approach for your script:

1) When a window is initially mapped, or resized or moved by means
other than the script, look at the corners of the window and
determine which corner of the screen it is closest to. I.e. if the
top right corner of the window is closer to the top right corner of
the screen than the other window corners are to their respective
screen corner, then the window will be resized to the bottom left.
Store this information somewhere, perhaps in two window state bits.

2) When the scroll wheel is used, another script looks up the stored
resize direction and determines what to do with the window. Note
that this way of resizing should not trigger (1), because that
would cause the window to grow in a different direction when the
"closest corner" calculation changes.

3) You could even add two bottons to the window that indicate the
resize directions and allow changing them (at the moment you need
two buttons because each of the two states can only be used as a
toggle).

Ciao

Dominik ^_^ ^_^

--

Dominik Vogt