Subject: Three patches for fvwm-2.3.6

From: "mjr0" <[email-masked]>
Date: Thu, 2 Sep 1999 00:59:40 +0100

Dominik,

Enclosed, three patches in a tarball - applied with:

 $ cd <your fvwm-2.3.6 source tree top>
 $ cat <untar'd patches directory>/00* | patch -p1

Patch files:

001-fix.fvwm-2.3.6-LowerTransient

 Fixes a logic bugette in must_move_transients()

002-patch.fvwm-2.3.6-StackTransientParent

 Implements (Dont)StackTransientParent as suggested in your mail:
 Raise/Lower on a transient moves the parent window too.

 Only one level of transientfor is handled. I think we should
 consider extending it to handle whole trees of transient windows.
 I conviced myself earlier this year that the penalty of extra scans
 along stack_next->... is not large. What do you think?

003-patch.fvwm-2.3.6-RaiseTransientStrict

 Implements RaiseTransientStrict as proposed in my earlier mail:
 turns RaiseTransient ON, but does not allow the main window above
 its transients.

 There is a conflict here in that DontRaiseTransient followed by
 RaiseTransientStrict will turn RaiseTransient ON. Is it best to
 simply point that out in the manual page, or to apply some trap in
 the style parsing ?

--
Regards, Mark.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 2 Sep 1999 02:55:56 +0200

Hi Mark,

>  along stack_next->... is not large. What do you think?

Well, go ahead.

>  simply point that out in the manual page, or to apply some trap in

Just don't toggle RaiseTransient flag. I see no real reason in
doing this.  Furthermore I'd prefer that 'strict' is the default
because of the reasons I wrote in my last mail.  And don't forget
that 'strict' affects raising as well as lowering. Perhaps it
should better be named '(Dont)RaiseLowerTransientLenient'?
The name is a bit too long for my liking, perhaps a different one
is better?

--------- after testing the patches ----------

Excellent work, Mark :-) Everything works smooth now. I will commit
the three patches you sent me today.  There are only minor things
to be done:

 1) Write a patch for the man page.
 2) Write a patch for the NEWS, AUTHORS and ChangeLog files.
 3) Find an acceptable default behaviour and put the necessary
    lines in ConfigFvwmDefaults.
 4) The LowerTransient style has no equivalent LowerTransientStrict
    style. How about '(Dont)StackTransientLenient'? This would
    augment RaiseTransient/LowerTransient and have no effect if
    neither of the two is used.

BTW, a single patch is enough for all the changes.

When this is finished we are very close to the point where we
will stop writing new features for 2.4 and begin testing and
debugging :-)

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: Dominik Vogt <[email-masked]>
Date: Thu, 9 Sep 1999 02:56:16 +0200

> 003-patch.fvwm-2.3.6-RaiseTransientStrict

Mark, I think there is some bug in inner_RaiseOrLowerWindow().
When an application changes its layer, the new_layer function
calls RaiseWindow/LowerWindow while the stack ring is not
sorted properly (the window is still stuck in the old layer).
I think you are doing something with the unsorted stack ring
that causes raising/lowering to behave funny. Any ideas?

Bye

Dominik ^_^