Subject: Re: FVWM: CDE resize incompatibility?

From: Dominik Vogt <[email-masked]>
Date: Sun, 28 Mar 1999 21:52:06 +0200

On Fri, Mar 26, 1999 at 07:44:41PM -0500, Barry A. Warsaw wrote:
> 
> Hi all,
> 
> I'm having the hardest time figuring out the following problem.  Any
> help, hints, or ideas will be greatly appreciated.  I am not on the
> Fvwm mailing list so please CC with any responses.  I will post a
> followup if there is any interest.  Will answer Python, Mailman, or CC
> Mode question for food (or help :-).
> 
> My system: Solaris 2.6 (w/ all recent patches), Open Windows 3.6 X
> server (also w/ all recent patches).  I have been using Fvwm 2.0.46
> since it came out, and love it.  I tried the following with Fvwm 2.2
> but that did not seem to fix my problem.
> 
> I have just started using CodeWarrior Pro4 for Solaris.  This is a
> commercial Java IDE.  I suspect that this was ported from a Mac using
> some kind of porting tool.  The GUI looks quite Mac-like in places;
> file name separators are `:' in some places too.
> 
> 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.
> 
> Naturally, I complained to Metrowerks (CodeWarrior's vendor).  They
> said Fvwm is not a supported window manager at this time -- they only
> support CDE.  So, I tried to be a good little Solaris user, and
> started up a vanilla stock CDE window system, fresh from dtlogin.
> Besides CDE (and I assume dtwm) being completely horrible, I tried to
> resize my CW windows, and sure enough, it worked!  I enlarge the
> frame, the app repaints to fill the new real-estate.
> 
> I figured maybe my Fvwm is just too old, so I downloaded Fvwm 2.2.
> Unfortunately, it still doesn't cause the resize.
> 
> What magic is CDE/dtwm doing that Fvwm is missing???

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.

> Is there some
> option, variable, style (or even #define in the code :-) I can twiddle
> to get this to work.  Please don't make me use CDE!

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: "Eddy J. Gurney" <[email-masked]>
Date: Mon, 29 Mar 1999 11:16:51 -0500

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.

Just a suggestion that it may be related,
Eddy

---

From: Dan Espen <[email-masked]>
Date: Mon, 29 Mar 1999 15:10:34 -0500

> Just a suggestion that it may be related,

Thanks for restating your instructions, the last time around I tried
it, and couldn't produce the window.

Anyway, I tried and got this:

fork> xwininfo -size

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x38074d9 (has no name)

  Normal window size hints:
      Program supplied location: 5, 3
      Program supplied size: 909 by 130
      Program supplied minimum size: 609 by 108
      Program supplied maximum size: 609 by 108
                                     ^^^    ^^^
      Program supplied window gravity: NorthWestGravity
  No zoom window size hints defined

As you can see, "Streamer" has set the window manager hints
for a minimum and maximum size of its window.  Fvwm2 being
a ICCCM complaint window manager is just doing what its told
to do.

I'd be interested to know if Barry Warsaw's application
does the same thing.  (I've copied him.)

I don't know if we should add the ability to ignore these hints,
or see if these applications can be fixed.  If Barry wanted to
hack out a solution just to get away from CDE, he should look
in fvwm/add_window.c for max_width and max_height and set
them to some other value.  (I haven't tested anything yet.)

--
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: Danek Duvall <[email-masked]>
Date: Mon, 29 Mar 1999 12:10:28 -0800

> it, although I've only verified it under Solaris.

I don't know whether Netscape's AWT code is based on Sun's implementation,
but if it is, god only knows what nasty interactions are going on with the
WM.  There are so many dtwm-specific hacks in AWT it ain't funny, and the
interesting interactions with Java apps just don't stop.

I've tried tracking some of these down in the AWT code, but aside from some
obvious (and commented) hacks, I haven't been able to find anything
particularly wrong (to my Motif-untrained eye).

I don't suppose by any chance Codewarrior is written in Java, is it?  :)

Danek

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Mon, 29 Mar 1999 19:10:13 -0500 (EST)

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

    DV> The right bugfix.

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

Okay, thanks for the hints, I'll try to turn on the debugging
information and see what I can find.

-Barry

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Mon, 29 Mar 1999 19:08:43 -0500 (EST)

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

    |   Normal window size hints:
    |       Program supplied location: 5, 3
    |       Program supplied size: 909 by 130
    |       Program supplied minimum size: 609 by 108
    |       Program supplied maximum size: 609 by 108
    |                                      ^^^    ^^^
    |       Program supplied window gravity: NorthWestGravity
    |   No zoom window size hints defined

    DE> As you can see, "Streamer" has set the window manager hints
    DE> for a minimum and maximum size of its window.  Fvwm2 being
    DE> a ICCCM complaint window manager is just doing what its told
    DE> to do.

    DE> I'd be interested to know if Barry Warsaw's application
    DE> does the same thing.  (I've copied him.)

I don't think this is what's happening for me.  Attached is some
output of xwininfo (I included a bit more than just -size).  Nothing
jumps out at me, so hopefully you'll see something I'm missing!

Thanks,
-Barry

-------------------- snip snip --------------------
@anthem[~:528]% xwininfo -size -stats -events -wm

xwininfo: Window id: 0x6400087 "Processes"

  Absolute upper-left X:  71
  Absolute upper-left Y:  150
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 496
  Height: 222
  Depth: 8
  Visual Class: PseudoColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x6400008 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +71+150  -713+150  -713-652  +71-652
  -geometry 496x222+68+130

  Someone wants these events:
      KeyPress
      KeyRelease
      EnterWindow
      LeaveWindow
      Exposure
      VisibilityChange
      StructureNotify
      FocusChange
      PropertyChange
      ColormapChange
  Do not propagate these events:
      ButtonPress
      ButtonRelease
  Override redirection?: No

  Window manager hints:
      Client accepts input or input focus: Yes
      Initial state is Normal State

  Normal window size hints:
      Program supplied location: 58, 55
      Program supplied size: 496 by 222
      Program supplied minimum size: 482 by 204
      Program supplied maximum size: 1280 by 1024
      Program supplied window gravity: NorthWestGravity
  No zoom window size hints defined
--
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: Tim Phipps <[email-masked]>
Date: Tue, 30 Mar 1999 09:01:49 +0100

>       Program supplied maximum size: 609 by 108
It's even worse than this, before the app tries to resize to Program
supplied size is 1 by 1 so we can't do a quick fix by letting PSS
override the min and max sizes.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Tue, 30 Mar 1999 08:19:28 -0500

> override the min and max sizes.

But you wouldn't want the program supplied size to override
the minimum and maximum.  You'd want something like:

Style "Streamer" IgnoreSizeHints

then   the   minimum  would   be   zero  and  the  maximum   would  be
MAX_WINDOW_WIDTH and MAX_WINDOW_HEIGHT.  But the application is
broken, putting junk into fvwm2 to fix it should be a last resort.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 1 Apr 1999 00:30:25 +0200

> broken, putting junk into fvwm2 to fix it should be a last resort.

Hmm, there is a lot of stuff to keep broken applications happy
in fvwm already (e.g. lenience and the double reparenting). By
default we could check if the application supplied min/max size
seem to be nonsense (min > max or current size < min or current
size > max) and ignore it then.

Bye

Dominik ^_^