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
On Thu, 29 Oct 1998, Duane Guingrich wrote:
: 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 majordomo_at_hpc.uh.edu.
: To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
:
--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu Oct 29 1998 - 11:41:15 GMT