Subject: FVWM: patches for Raise/Lower on transients

From: Mark Rainford <[email-masked]>
Date: Wed, 15 Sep 1999 18:28:37 +0100

Dominik,

Enclosed please find patches (from CVS this time :-) completing my
previous submissions - hopefully agreeing with all we've discussed.

- Raise/LowerTransient: main always below transients
- StackTransientParent: documented
- FlipTransient(previously StackTransientLenient): new style,
re-instates flipping transients above/below main on raise (no longer
normal behaviour for RaiseTransient); does similar job for
LowerTransient.

This time I've included updates for NEWS, ChangeLog etc :-) but NOT
fvwm/ConfigFvwmDefaults on the grounds that False is a good initial
value for the relevant flags.

Outstanding:

(1) Extend the behaviour to handle more than one level of
main+transient. Since no one seems to have noticed this but me, I guess
its not worth holding up a release for, but I will start on it.

(2) Does anyone have views on the suggestions I made in relation to
transients and layers? (Mon, 13 Sep 1999 18:31:06 +0100)

-- 

Regards,  Mark.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Sep 1999 01:39:35 +0200

> transients and layers? (Mon, 13 Sep 1999 18:31:06 +0100)

Okay, this looks good, but I still se a few small problems:

Configuration: RaiseTransient + LowerTransient + DontFlipTransient:

 1) The RaiseLower command never lowers a window that is overlapped
    by one of its transients. I guess this is because there is still
    a window obscuring it and thus the function assumes it has to
    raise the window. The same behaviour is correct if you use the
    FlipTransient style.

Configuration: RaiseTransient + LowerTransient + FlipTransient:

 2) I use 'GlobalOpt MouseFocusClickRaises' and
    'Style * SloppyFocus'. When I click on a window with a transient
    it raises above its transients as expected, but if I click it
    again it doesn't lower back below the transient. It does lower
    itself if I raise it by clicking on the title bar.

---------- a while later ------------

Problem 1 is fixed now.

---------- a while later ------------

Problem 2 is fixed too.

There is only one thing left that may confuse users (well, it *does*
confuses me and that should probably be fixed:

Configuration: RaiseTransient + LowerTransient + FlipTransient:

 3) Put some window A on page 0 0; put a window B with a transient
    C on page 1 0. Put a window D on page 1 0. Raise window B and C
    so that they are above D and C atop of B. Raise the window A on
    the other page by moving it in the pager with button 2. Now when
    I raise window B I expect it to flip atop C because of FlipTransient.
    But instead nothing seems to happen. In fact, B and C are raises
    over A because although its on a different page. A RaiseLower would
    have lowered both windows below D, not raised them above A.

    The problem is that the code in must_move_transients() doesn't
    consider if windows are actually overlapped by other windows but
    only looks at the stacking order. The right thing to do would be
    to check any of its transients (possibly recursive) each window
    overlapping each of the individual transients. Well, since this
    would require O(n^2) tests for overlapping windows (where n is
    the total number of windows) I guess its not worth the effort.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mark Rainford <[email-masked]>
Date: Fri, 17 Sep 1999 18:41:20 +0100

Thu, 16 Sep 1999 01:39:35 +0200 Dominik Vogt wrote:
> > Enclosed please find patches ....
> 
> ....

Thankyou.

> ---------- a while later ------------

Thankyou, thankyou.

>     the total number of windows) I guess its not worth the effort.

Or we could make a new style FlipTransientStrict ... only joking :-) The
same holds for lowering - when not overlapping other windows and not at
the bottom of the stack. I think it is reasonable for this to be
documented behaviour - I'm sure that users of FlipTransient will develop
a feel for it.

As for the RaiseLower case, perhaps the man page should indicate that
the action depends on being overlapped rather than on the position in
the stack.

In case you like these notions, I've attached a man page patch.
-- 

Regards,  Mark.

Index: fvwm/fvwm2.1
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm2.1,v
retrieving revision 1.194
diff -u -b -B -r1.194 fvwm2.1
--- fvwm/fvwm2.1	1999/09/16 02:03:31	1.194
+++ fvwm/fvwm2.1	1999/09/17 17:35:20
@@ -2096,6 +2096,9 @@
 .TP
 .B "RaiseLower"
 Alternately raises and lowers a window.
+The window is raised if it is obscured by any window
+(except for its own transients when RaiseTransient style is used)
+otherwise it is lowered.

 .TP
@@ -3070,6 +3073,9 @@
 The \fIFlipTransient\fP style augments \fIRaiseTransient\fP and
 \fILowerTransient\fP styles so that repeated raising or repeated lowering
 of the main window makes the transients flip above and below the main.
+Note that flipping only occurs at the top or bottom of the layer,
+and so a second raise or lower may be neccessary to actually flip when the
+first has simply moved the window's position.
 The \fIDontFlipTransient\fP style disables this behaviour so that the
 main window is always below its transients.
 \fI(Dont)FlipTransient\fP has no effect if \fIRaiseTransient\fP and
Index: fvwm/stack.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/stack.c,v
retrieving revision 1.21
diff -u -b -B -r1.21 stack.c

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 19 Sep 1999 14:56:41 +0200

> In case you like these notions, I've attached a man page patch.

Okay, I applied the patch.

Bye

Dominik ^_^