Customer's detailed description: 
	
	All problems listed here are based on the assumption that a window's
	dialogs should always appear on top of the window, never behind it. It
	is up to the window manager to enforce this behavior.
	
	So, compile the sample program (with production JDK 1.1.6). run it and
	then try out these three test cases:

	Case 1:
		Execute the window manager action to bring Frame1 to the
		front. On my CDE environment, clicking on the title bar does
		this. The frame appears in front of the dialog. The dialog is
		also raised, but just under the frame. I would think this is a
		dtwm bug.
	
	Case 2:
		Use the menu bar in Frame2 to execute File/Frame 1 To Front.
		The frame appears in front of the dialog. Again, the dialog is
		also raised, but just under the frame. I list this separate
		from case 1 since Fvwm95 (an alternate window manager) behaves
		correctly in case 1 but fails case 2.
	
	Case 3:
		Iconify Frame1 using the proper window manager command. The
		frame and dialog both disappear (this is correct). Now,
		de-iconify Frame1, using the menu function in Frame2. Frame1
		re-appears, but the dialog is now gone and there appears to be
		no way to get it back.

	******************************************************************************
	
	import java.awt.*;
	import java.awt.event.*;
	
	class Main
	    implements ActionListener
	{
	
	Frame frame1;
	Frame frame2;
	Dialog dialog;
	
	public static void
	main(
	    String[] args)
	{
	    new Main();
	}
	
	Main()
	{
	    // Frame 1
	    frame1 = new Frame();
	    frame1.setSize(400, 200);
	    frame1.setLocation(400, 400);
	    frame1.setTitle("Frame 1");
	
	    frame1.setVisible(true);
	
	    // Frame 2
	
	    frame2 = new Frame();
	    frame2.setSize(400, 200);
	    frame2.setLocation(350, 350);
	    frame2.setTitle("Frame 2");
	
	    MenuBar menuBar = new MenuBar();
	    frame2.setMenuBar(menuBar);
	    Menu file = new Menu("File");
	    menuBar.add(file);
	    MenuItem item = new MenuItem("Frame 1 To Front");
	    file.add(item);
	    item.addActionListener(this);
	    item = new MenuItem("De-Iconify Frame 1");
	    file.add(item);
	    item.addActionListener(this);
	
	    frame2.setVisible(true);
	
	    // Dialog on Frame 1
	
	    dialog = new Dialog(frame1);
	    //dialog.setModal(true);
	    dialog.setSize(100, 200);
	    dialog.setLocation(500, 500);
	    dialog.setTitle("Dialog");
	    dialog.setVisible(true);
	}
	public void
	actionPerformed(
	    ActionEvent e)
	{
	    if ("Frame 1 To Front".equals(e.getActionCommand())) {
		frame1.toFront();
	    }
	    else {
		frame1.setVisible(false);
		frame1.setVisible(true);
	    }
	}
	
	}
	******************************************************************************

  xxxxx@xxxxx   1999-01-12
------------------------------

Unamp the transients before unmapping the primary window.

  xxxxx@xxxxx   1999-01-08
------------------------------

The first behaviour relates to the Style Manager option
to 'Allow Primary Windows On Top' in the Window dialog.
If this is delselected then transient windows (e.g. dialog
boxes) will always stay on top.

The latter behaviour is a window manager bug.
When the De-Iconfify option is selected it is
performing an unmapping on the frame 1 window,
then a mapping.
Analysing a trace of the X mapping events: dtwm
is unmapping the dialog box but not mapping but not
performing the reverse.
I suspect that when a primary window is mapped it
is not checking for any transients that require
mapping.


  xxxxx@xxxxx   1999-01-12
------------------------------

If the priomary gets unmapped it is correct that the transient
windows are unmapped too.
When the primary window is mapped it is not necessarily correct
that the dialogs should be mapped too.
This would be a big performance hit, requiring a search
through all unmapped windows of certain properties
each each primary window is mapped.
All the window manager knows is that the window is being 
removed from its control and does not know that it may
be remapped.

However it should be possible for the application to map
the transients once the primary is mapped.
This is the bug.
I am currently not sure why the transient windows cannot
be re-mapped if the primary window is unmapped then
re-mapped.


  xxxxx@xxxxx   1999-01-12
------------------------------

Its an interaction problem between X and Xt.
To display dialogs the call XtManageChild
is often called on the dialog shell form.
This works fine if the shell is unmanaged,
it does nothing the the shell is already managed.

For the case when the primary window is unmapped
the transient windows are unmapped but are never 
unmanaged, because the window manager is dealing
with window ids not widget ids.

When a transient is specifically removed in the
conventional manner it calls a delete window handler, which
is connected to the WM_DELETE_PROTOCOL atom.
This procedure will unmanage the widget.

To display the dialog shell it is necessary to 
peform somthing like:

if (!XtIsManaged (dialog_shell_form))
	XtMapWidget (XtParent (dialog_shell_form));
else
	XtManageChild (dialog_shell_form);

I am reluctant to add code to send a WM_DELETE_WINDOW
client message to each transient window when
the transients have been unmapped due to 
unmapping of the primary.

I will move to Java AWT to see what they think about
modifying the AWT motif native methods for dialog
management.

This scenario would be rarely encountered when programming
in the motif style but seems more likely to occur when using
AWT.
Additioanlly does AWT manage window groups for dialogs?
as i am relucatant to impose a performace penalty on
dtwm to seach through window list for transients of
the same group.

=========================
This is the same problem as bug 4094565 where toFront on Solaris is not doing the right thing.