Subject: Re: FVWM: CDE resize incompatibility?

From: "Barry A. Warsaw" <[email-masked]>
Date: Thu, 1 Apr 1999 16:37:01 -0500 (EST)

>>>>> "DV" == Dominik Vogt <[email-masked]> writes:

    DV> The right bugfix. I've seen similar reports a few times, but
    DV> always with uncommon applications that none of the developers
    DV> have handy.  Would you be willing to help debugging this? A
    DV> good place to start looking would be HandleConfigureRequest()
    DV> in events.c or SetupFrame() (borders.c I believe). It would be
    DV> helpful to know exactly what requests are received and what
    DV> parameters are set in SetupFrame.  I think there is some debug
    DV> code that can be activated by compiling with DEBUG or DBUG
    DV> set.

I've done a little more investigating, without yet digging into the
code.  Here's another data point, but I'm not sure if it's a symptom
or a cause!

Here's how I've gotten things to work:

1. start window system with no window manager
2. start /usr/dt/bin/dtwm (remember: Solaris 2.6)
3. start CodeWarrior
4. kill dtwm
5. start Fvwm with my normal config file

Doing things in this order makes it so that when I resize CW windows,
the insides get painted correctly.  However, if while Fvwm is still
running, I kill CW and restart it, bang! they don't resize.

So it must not be /strictly/ wm related.  I had a feeling maybe
there's some property that's not getting set up right, so I hung a
xprop -spy on the CW windows as I resized them.

When resizing worked, I would get two property changes on
_MOTIF_DRAG_RECEIVER_INFO for every resize.  However, when resizing is
broken, I only get one property change on _MOTIF_DRAG_RECEIVER_INFO
for every resize.  Makes me think that somehow the stuff inside the CW 
window isn't getting the proper event that triggers the app to set
this property a second time.

Should I continue to investigate in this direction?  Would you like
more detailed xprop output, or is this a red herring?

Thanks,
-Barry
--
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]

---

From: Dan Espen <[email-masked]>
Date: Thu, 01 Apr 1999 17:05:12 -0500

> more detailed xprop output, or is this a red herring?

I think what we need to know is whether fvwm is generating a
"ConfigureNotify" for code warrior.  The code in borders.c seems
to take a lot of different conditions into account before it sends
the "ConfigureNotify" off to the application.

(The "ConfigureNotify" has the windows new dimensions in it.)

If you recompile borders.c with FVWM_DEBUG_MSGS defined, we should
get a look at the message being generated.

I don't see any part of fvwm that seems to be concerned with
_MOTIF_DRAG_RECEIVER_INFO.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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]

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Fri, 2 Apr 1999 00:32:28 -0500 (EST)

>>>>> "DE" == Dan Espen <[email-masked]> writes:

    DE> I think what we need to know is whether fvwm is generating a
    DE> "ConfigureNotify" for code warrior.  The code in borders.c
    DE> seems to take a lot of different conditions into account
    DE> before it sends the "ConfigureNotify" off to the application.

    DE> (The "ConfigureNotify" has the windows new dimensions in it.)

    DE> If you recompile borders.c with FVWM_DEBUG_MSGS defined, we
    DE> should get a look at the message being generated.

    DE> I don't see any part of fvwm that seems to be concerned with
    DE> _MOTIF_DRAG_RECEIVER_INFO.

Okay, thanks Dan.  I'll do this recompile as soon as possible and
report my findings.

-Barry

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Apr 1999 01:45:37 +0200

> Okay, thanks Dan.  I'll do this recompile as soon as possible and

Barry, did you find out something new on this bug?

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]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Apr 1999 01:31:49 +0200

On Mon, Mar 29, 1999 at 11:16:51AM -0500, Eddy J. Gurney wrote:
> On Mar 28 at 21:52, Dominik Vogt wrote:
> ,--
> | On Fri, Mar 26, 1999 at 07:44:41PM -0500, Barry A. Warsaw wrote:
> | > When I have a CodeWarrior window open, and I try to resize it using
> | > the `Resize' builtin function, the outer Fvwm frame resizes just fine,
> | > however the contents of the window don't repaint to fill the new
> | > borders[*].  No matter what I try, no matter what style settings I
> | > use, or options I set, I can never get the contents to fill the frame.
> | > It's almost as if some window manager event is not getting propagated
> | > to the app -- it doesn't know it's been resized and so it just sits
> | > there.
> |
> | The right bugfix. I've seen similar reports a few times, but always
> | with uncommon applications that none of the developers have handy.
> | Would you be willing to help debugging this? A good place to start
> | looking would be HandleConfigureRequest() in events.c or SetupFrame()
> | (borders.c I believe). It would be helpful to know exactly what
> | requests are received and what parameters are set in SetupFrame.
> | I think there is some debug code that can be activated by compiling
> | with DEBUG or DBUG set.
> `--
> This may be related to the bug report I submitted on February 16th
> (#176) that is still in the "Incoming" folder. Since bug #176 is
> reproducible via a Java applet, anybody should be able to reproduce
> it, although I've only verified it under Solaris.
> 
> Here it is for easy reference:
> 
> Datek's "Streamer" does not resize under FVWM2
> 
> Go to http://www.datek.com/streamer (with Java enabled in Netscape)
> and wait for the "Streamer" java app to appear. Sometimes it takes a
> few tries if their servers are busy.
> 
> Enter anything for a user name and hit "Ok" (it doesn't actually check
> username/password until you try to add a stock symbol). Now click the
> "Settings" button, and then the "Resize" button. Click the "Make bigger"
> button and notice that the Streamer window does NOT grow; the contents get
> bigger but NOT the window itself. Click "Make bigger" again and see the
> same thing again. Also notice that the windows shifts up and to the left.
> 
> This happens under both 2.0.46 and 2.1.12. *It works fine under vtwm.*
> 
> This merely demonstrates the problem; it makes the Streamer applet fairly
> useless in everyday use because you can't display more than two quotes
> since that is all that fit in the default window size.

I've hacked in a 'fix' for your problem. Give the window the
'ResizeHintOverride' style. This will allow you to resize it beyond
the program specified limits.

Bye

Dominik ^_^