Subject: Notification: incoming/631

From: [email-masked]
Date: Mon, 12 Jun 2000 14:33:22 -0500 (CDT)

FVWM Bug Tracking notification

new message incoming/631

Message summary for PR#631
	From: [email-masked]
	Subject: non-modal dialogs from Qt
	Date: Mon, 12 Jun 2000 14:33:20 -0500 (CDT)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 13 Jun 2000 02:31:36 +0200

On Mon, Jun 12, 2000 at 02:33:22PM -0500, [email-masked] wrote:
> >From [email-masked]  Mon Jun 12 14:33:21 2000
> Received: from localhost (localhost [127.0.0.1])
> 	by larry.math.uh.edu (8.9.1/8.9.1) with ESMTP id OAA20435
> 	for <[email-masked]>; Mon, 12 Jun 2000 14:33:20 -0500 (CDT)
> Message-Id: <[email-masked]>
> To: [email-masked]
> Full_Name: Daniel Tweedt
> Version: 2.3.19
> CVS_Date: 
> OS: linux kernel 2.2.14
> X_Server: XFree86 3.3.6; XIG 3D Accelerated-X
> Submission from: (NULL) (24.3.252.175)
> 
> 
> Until recently I've been using the stable 2.2.x versions of fvwm2. The
> problem described below did not occur with any of those versions, nor does
> it occur on a Silicon Graphics (SGI) workstation (SGI window manager) that
> I sometimes use.
> 
> I've done some code development using the C++ GUI toolkit Qt, version
> 2.0.2, from Troll Tech (a different version of this toolkit was used to
> develop KDE). When making GUI dialog boxes/menus, it is possible to specify
> a current widget or dialog to be the "parent" of its sub-dialog box(es).
> When this is done, the parent and its child dialog are closely related; for
> example the child dialog first appears centered over its parent, and when
> either is iconified by clicking a window frame button then they are both
> (all) iconified together as a single icon. Using the newer beta version(s)
> of fvwm, NON-MODAL sub-dialogs of this type cannot be "pushed" back behind
> their parents, nor can their parent(s) be "popped" to the top; the last
> child always stays on top. Other than that, the dialogs seem to behave
> correctly.
> 
> If it would be helpful, I could probably write a simple chunk of code using
> Qt to demonstrate (reproduce) this problem. Please let me know if such a
> test case is needed. Perhaps you're already aware of this issue?

Don't bother to write any code to demonstrate this.  The reason is
that the default behaviour for transient windows in fvwm was changed.
You can override the default setting with this line in your config file:

  Style * DontRaiseTransient, DontLowerTransient

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]