Subject: FVWM: TransientFor hint property problem

From: "Duane Guingrich" <[email-masked]>
Date: Thu, 29 Oct 1998 10:39:40 -0500

I am having a problem with FVWM not behaving the same as
mwm when I set the TransientFor hint property. What I am trying to
do is make the window of a separate task behave like it is a dialog
of my main task. I am doing the following steps:

1) Run my program called 'MyTask'
2) MyTask spawns the standalone FontSel program using a pipe
    to get the selected font from FontSel's standard output.
3) MyTask looks for the WindowID of FontSel based on its window
    name using a timer and QueryTree().
4) When MyTask finds the WindowID of FontSel, it calls
    XSetTransientForHint() using the WindowID of MyTask
    as the parent window and the found WindowID of FontSel
    as the dialog window.

    When I do this under mwm, the stacking order is maintained
so that clicking on the window for MyTask will caused the window
for FontSel to be raised as well. Under FVWM, the two windows
continue to operate independently and clicking on the window for
MyTask raises it in front of the window for FontSel.

    When I saw that this technique didn't work under FVWM,
I tried setting the windowgroup for the FontSel window to the
WindowID of MyTask, but this didn't work either.

     Duane

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

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 29 Oct 1998 10:58:10 -0500 (EST)

Not sure, but you could try looking at the options for MWMxxx and
HintOveride

they are all documented in the man page.

See if that helps,
Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 29 Oct 1998 12:40:58 -0500 (EST)

We to have had a long standing problem with fvwm and applications compiled
against Motif libraries. The apps will not start! The current "trick that
works" is to start Netscape before you run a "problem" app, as it seems to
set things in a way that will allow apps following to run. This is of course
stupid. 

I have attached a bug report on the issue, which mentions another "trick
that sometimes works", but it a much smaller and faster trick then starting
Netscape, eating lots of memory, starting big app, eating rest of memory,
swap, swap, swap....

I spent a number of hours last night looking at how Fvwm handles the Motif
Intrinsics, and wanted to gag. If you look at the AfterStep source and see
all the motif-isms that had to comment out you will quickly see that the
routines in decorations.c code is in need of some changes (SelectDecor(),
GetMwmHints(), GetOlHints(). If you look at the Enlightment source, you will
see a better handling of the MwmHints. Fixing this will help Fvwm better
manage and expand its lookand feel as well.

Right now MWM and OLWM are in a twisted mess in the Fvwm code.

After the next release (yes I agree with the soon), this code needs help.

There should be either an FVWM_FLAGS or an fvwm_structure set, such that is 
the union of what other WM apps may present to it can be used in the code,
and not rely on MWM_FLAGS as is done now. The WM_app code should be kept in
their specific GetXXXHints() routines, and only the fvwm_structure should 
get out, as well as go through the rest.

It look to me like it should (with lots of hand waving here);

GetFvwmHints()     // What did the .fvwmrc+running_state give us. (WMHints)
                   // i.e. first load fvwm_structure with the look we want.
GetMwmHints()      // If this is a Motif app find our compromise
GetOlwmHints()     // If this is an Open Look app find our compromise
GetGnomeHints()    // If this is a Gnome app find our compromise
GetXyzHints()      // If this is an Xyz app find our compromise
SelectDecor()      // A much cleaner routine that takes the final
                   // fvwm_structure and presents it to Fvwm_core.

These routines are all called from AddWindow(), and could be put in their
own routine and .c file GetHints() and hints.c. I think this is central 
to the great "style" changes.

The existing code was good from that standpoint that it was how twm was
given the mwm look and feel. There are now more looks and feels, and this
needs to be reorganized, so we do not end up with endless source or
CVS branches for every fvwm spinoff. A cleaner API would help various
factions to work together.

Randall

:     I am having a problem with FVWM not behaving the same as
: mwm when I set the TransientFor hint property. What I am trying to
: do is make the window of a separate task behave like it is a dialog
: of my main task. I am doing the following steps:
: 
: 1) Run my program called 'MyTask'
: 2) MyTask spawns the standalone FontSel program using a pipe
:     to get the selected font from FontSel's standard output.
: 3) MyTask looks for the WindowID of FontSel based on its window
:     name using a timer and QueryTree().
: 4) When MyTask finds the WindowID of FontSel, it calls
:     XSetTransientForHint() using the WindowID of MyTask
:     as the parent window and the found WindowID of FontSel
:     as the dialog window.
: 
:     When I do this under mwm, the stacking order is maintained
: so that clicking on the window for MyTask will caused the window
: for FontSel to be raised as well. Under FVWM, the two windows
: continue to operate independently and clicking on the window for
: MyTask raises it in front of the window for FontSel.
: 
:     When I saw that this technique didn't work under FVWM,
: I tried setting the windowgroup for the FontSel window to the
: WindowID of MyTask, but this didn't work either.
: 
:      Duane
: 
: --
: Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
: To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
: message to [email-masked].
: To report problems, send mail to [email-masked].
: