Subject: Re: [Fwd: FVWM-2.3.6 patch submissions]

From: [email-masked] (Mark Rainford)
Date: Tue, 31 Aug 1999 23:24:55 +0100

8/26/99 12:12 Dominik Vogt wrote:

            Mark, 
            that patch works only as one would expect if the styles 
            RaiseTransient and LowerTransient are used. I could imagine 
            the final behaviour like this: 
            There are three styles, (Dont)RaiseTransient and 
            (Dont)LowerTransient plus (Dont)StackTransientParent. 
            The first should work as the man page says: If they are 
            set, raising/lowering the parent window raises/lowers 
            transients too. The StackTransientParent style additionally 
            says that the parent window is to be raised/lowered together 
            with its transients whenever a transient is raised/lowered. 

Sounds okay. But is it only the raised transient and its parent which
move, or does the movement of the parent raise all its transients too?
(as if the Raise action was acting on the parent). The patch does
the second.

            At the moment the patch is way too strict. The problems I 
            see are: 

             - You can't lower transients below the parents anymore, 
               even with DontLowerTransient and DontRaiseTransient set. 

Well that *is* what I am trying to achieve, but I didn't intend to make it
obligatory. I've probably confused the issue by (a) making the mistakes
mentioned below, and (b) supplying one patch to introduce more than one
new feature.

My overall aim is for a configuration in which transients cannot
be obscured by their parent. This is Motif behaviour, and some of
our applications actually rely upon it. It can be partly achieved
with RaiseTransient and the new StackTransientParent, but still needs
something more to prevent the movement of the parent above its transients;
ie. when they are already raised, and the parent is raised again.
I would like another new style, say RaiseTransientStrict, which does
everything RaiseTransient does except allowing the parent to toggle
above/below the transients when they are all at the top of their layer.

             - If both Dont... styles are set you can't raise transients 
               above any other windows. 
             - Again with those two styles: When you click on a transient, 
               its parent is raised. 
             - The LowerTransient/DontLowerTransient style seems to have 
               no effect at all. 

Hmmm ... the patch was a little blunt in applying StackTransientParent
style without regard for the (Dont)RaiseTransient and (Dont)LowerTransient
styles - resulting in the above three problems. A little more logic soon
fixes that.

             - You can't restack transients anymore. If an application has 
               two transients, you are unable to raise one transient above 
               the other. 

Ooops ... that was working fine before ... before ... before I broke
it. I'll fix it.

            We need to clean up these issues before we can apply that 
            patch. 

I'm afraid there's more that needs cleaning up too: in my original
patch submission for 2.0.46 I included treatment of a whole tree of
transients (where a main-window-with-transient-subwindows is itself
a transient of another window). Well I did that out of a belief that
nothing prohibits it. You quite reasonably asked "Does this ever happen",
and it seems the answer is "Yup". Start Netscape, Edit->Preferences,
Navigator->Applications, press the "Choose" button to select a destination
for Downloaded files and bingo, you have three windows (1) File Browser
which is transient for (2) "Netscape: Preferences", which is itself a
transient for (3) the main Netscape window. It seems to me that  with
RaiseTransient, a raise of (3) which raises (2) really ought to raise
(1) too.

I'll send patches for StackTransientParent and RaiseTransientStrict
shortly. What do you think about the tree of transients?

--
Regards, Mark.
--
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]