FVWM: Bug: 1.24 and 2.0.43

From: Dave Bodenstab <imdave_at_synet.net>
Date: Wed, 9 Oct 1996 14:25:19 -0500

The FAQ said to send bug reports to the mailing list, so...

There is a strange interaction between fvwm (both 1.24 and 2.0.43) with
the ImageMagick display program. I've enclosed my email correspondence
about the problem. Here's some info on my configuration:

- Describe the problem as best you can
  See below.
- What OS & version you are running under
  FreeBSD 2.0.5-950622-SNAP on an Intel 486
- What version of X11 are you running under
  name of display: base486:0.0
  version number: 11.0
  vendor string: The XFree86 Project, Inc
  vendor release number: 3110
  motion buffer size: 0
  bitmap unit, bit order, padding: 32, LSBFirst, 32
  image byte order: LSBFirst
  number of supported pixmap formats: 2
  supported pixmap formats:
      depth 1, bits_per_pixel 1, scanline_pad 32
      depth 8, bits_per_pixel 8, scanline_pad 32
  keycode range: minimum 8, maximum 134
  focus: window 0x200000d, revert to Parent
  number of extensions: 11
      BIG-REQUESTS
      MIT-SCREEN-SAVER
      MIT-SHM
      MIT-SUNDRY-NONSTANDARD
      Multi-Buffering
      SHAPE
      SYNC
      X3D-PEX
      XC-MISC
      XIE
      XTEST
- What exact version of FVWM you are running
  Both 1.24r and 2.0.43
- How was FVWM compiled (compiler & version, options, etc)
  gcc 2.6.3, -O2 -m486


The remainder of this message is the email describing the problem, the
debug output suggested by ImageMagick's author, and his conclusion.

Dave Bodenstab
imdave_at_synet.net

PS. I am not subscribed to the fvwm mailing list.

----------------------------------------------------------------------
  From imdave Tue Oct 8 13:24:25 1996
  To: cristy_at_dupont.com
  Subject: Weird 3.7.7 bug with fvwm window manager

  I tried ImageMagick 3.7.7 with FreeBSD, XFree86 3.11, eight-bit display.

  Here are (maybe) some rather bizzare bugs:

    1. display junk.gif
    2. iconize the window

  The image is now shrunk to about 90x90

    3. un-iconize the window

  The image window expands to its original size

    4. left button -- view -- original size

  The image window is suddenly shrunken to the size (I assume) that the
  image was when it was when iconized! Another small "locator" window
  appears (containing a representation of the entire image) that allows
  one to move a small box about which then causes the original image
  window to show that portion of the image that is inside the small box.
  I couldn't find a way to enlarge the image window back to its original
  size without reloading the original image file. Even then, any
  operation on the newly loaded image results in the same shrinking
  window.

  I noticed this because of another problem (which, I suppose, might not
  be a bug exactly): if one displays a gif and then clicks the left
  button, the menu window appears. Both the menu window and the image
  window seem to use the same colormap. Then, if one does, say, an
  EMBOSS operation, the color map gets remade, and sometimes the menu
  window becomes completly black when the pointer is in either the image
  window or the menu window. This makes using the menu impossible.
  However, if one iconizes the image and brings it back, then the
  colormap used seems to allow both the image and the menu to be seen at
  the same time. Of course, this triggers the first bug. (I've since
  noticed that if the left button is clicked to remove the menu, and
  then clicked again to bring the menu back, then the menu is visible
  again)


  Hmmm... as I've been playing with display 3.7.7 to make sure that my
  description is accurate, it's getting weirder:

    1. display junk.gif
    2. left button -- effects -- emboss

  colormap changes, menu goes black, image -- briefly -- shows the
  result, then suddenly the image window shrinks to what appears to be
  the size when iconized... I thought maybe I've got a goofy .displayrc
  or app-defaults/Display, but here they are:

  .displayrc:
    display.confirmExit: False
    display.backdrop: False
    display.usePixmap: False
    display.colormap: Private
    display.dither: False
    display.gammaCorrect: True

  app-defaults/Display:
    *.displayGamma: 4.0
    *.backdrop: False
    *.dither: True
    *.usePixmap: False
    *.sharedMemory: True

  An `xrdb -edit file' also showed nothing strange.

  I also just tried this with display 3.7.5 and got the same results. I
  know I've done this before, and had no problems as long as I hadn't
  iconized the window.

  So, I killed the X server and started a new one. The result: the
  image is not shrunk after an emboss using either 3.7.5 or 3.7.7
  display. However, once I've iconized the image once, from that time
  on every emboss operation (and probably others, but I didn't try)
  shrinks the image window. Aparently some switch is being set (inside
  the X server? inside the window manager?) that triggers this bug for
  all subsequent invocations of display.

  So, next experiment: I restarted the window manager (fvwm). The
  result: the image is not shrunk after an emboss using either 3.7.5 or
  3.7.7 display as long as I didn't iconize the window. That means that
  display, after being iconized once, is somehow retrieving something
  from the window manager that causes it to shrink the image size to
  the iconized image size?

  So, next experiment: I tried the twm and gwm window managers. The
  result: no shrinking.

  My conclusion: something is being remembered by the fvwm window
  manager after iconizing display's window. This is somehow affecting
  all subsequent invocations of display and causing the images to be
  shrunken. Very strange. I've not had any other problems using this
  window manager with any other X application. Wish I knew more about
  X, but I don't know what I'd be looking for from this point.

----------------------------------------------------------------------

  From: cristy_at_magick.es.dupont.com (Cristy)
  Date: Tue, 8 Oct 1996 16:45:20 -0330
  To: Dave Bodenstab <imdave_at_synet.net>
  Subject: Re: Weird 3.7.7 bug with fvwm window manager

  You can help track the fvwm bug with -debug

    display -debug some.image

  Save off the output in a file. Then try the exact same sequence with another
  window manager and produce a diff of the two. This should help identify
  what the problem is. More than likely, an extra configure notify is
  showing up when it not supposed too. This could be a bug in either
  display or fvwm. Perhaps fvwm should not be sending the extra configure
  event or perhaps display should be able to handle it more gracefully. However,
  I suspect that the problem is with fvwm.

  The colormap problem sounds like it might be a window manager problem as
  well. It's possible that the window manager is not installing the private
  colormap when focus is brought to the image window. This problem does not
  occur on my 8-bit SUN workstation (or IBM, or SGI, or ...).

  Window managers are supposed to follow the ICCCM protocol. It's possible
  that fvwm does not. However, I do not know for sure if that's the case...

  cristy_at_dupont.com

----------------------------------------------------------------------

  From imdave Wed Oct 9 12:43:43 1996
  To: cristy_at_dupont.com
  Subject: -debug output for weird fvwm problem

  Here are the logs of my weird window manager problem. As far as possible I
  tried to follow the exact same steps:

    start display
    position window (twm only; fvwm placed it for me)
    (mouse is outside of window)
    move mouse to iconize spot on title bar
    click (to iconize)
      wait for small image to appear in icon
    move mouse to icon
    click (to un-iconize)
    (mouse is on window title bar; twm only)
    move mouse into image window
    click left button
    move mouse to menu
    click left button effects
    click left button emboss
    (mouse is now outside of both windows)
      wait for fvwm instance to shrink window
    move mouse into image window
    click right button
    click left button quit
    click left button don't save

  I've matched up the lines in what appears to be the correct match...

  Dave Bodenstab
  imdave_at_synet.net

  PS. I'm using v1.24 of fvwm; there is a beta version 2.0.43 available, so I
  built it and gave it a try. I got the same behavior with display.
  If you determine that it's a bug with fvwm, I'll forward this report
  to the fvwm maintainers.

  FVWM TWM
  Script started on Tue Oct 8 18:20:36 1996 | Script started on Tue Oct 8 18:09:17 1996
  bash$ display -debug email.gif | bash$ display -debug email.gif
  Version: _at_(#)ImageMagick 3.7.7 96/10/15 crist| Version: @(#)ImageMagick 3.7.7 96/10/15 crist
  Visual: | Visual:
    visual id: 0x22 | visual id: 0x22
    class: PseudoColor | class: PseudoColor
    depth: 8 planes | depth: 8 planes
    size of colormap: 256 entries | size of colormap: 256 entries
    red, green, blue masks: 0x0 0x0 0x0 | red, green, blue masks: 0x0 0x0 0x0
    significant bits in color: 6 bits | significant bits in color: 6 bits
  Protocols: | Protocols:
    Window Manager: 0x81 | Window Manager: 0x81
      delete window: 0x80 | delete window: 0x80
      take focus: 0x8b | take focus: 0x8b
    ImageMagick: 0xe1 | ImageMagick: 0xe1
      update widget: 0xe2 | update widget: 0xe2
      update colormap: 0xe3 | update colormap: 0xe3
      update signature: 0xe4 | update signature: 0xe4
      former image: 0xe5 | former image: 0xe5
      next image: 0xe6 | next image: 0xe6
      retain colors: 0xe7 | retain colors: 0xe7
      exit: 0xe8 | exit: 0xe8
    Drag and Drop: 0xe9 | Drag and Drop: 0xe9
  Image: email.gif[0] 607x590 8c GIF | Image: email.gif[0] 607x590 8c GIF
  Standard Colormap: | Standard Colormap:
    colormap id: 0x21 | colormap id: 0x21
    red, green, blue max: 0 0 0 | red, green, blue max: 0 0 0
    red, green, blue mult: 0 0 0 | red, green, blue mult: 0 0 0
  Window id: 0x2000005 (context) | Window id: 0xc00005 (context)
  Window id: 0x200000b (icon) | Window id: 0xc0000b (icon)
  Window id: 0x2000011 (image) | Window id: 0xc00011 (image)
  XImage: | XImage:
    width, height: 607x590 | width, height: 607x590
    format: 2 | format: 2
    byte order: 0 | byte order: 0
    bitmap unit, bit order, pad: 32 0 32 | bitmap unit, bit order, pad: 32 0 32
    depth: 8 | depth: 8
    bytes per line: 608 | bytes per line: 608
    bits per pixel: 8 | bits per pixel: 8
    red, green, blue masks: 0x0 0x0 0x0 | red, green, blue masks: 0x0 0x0 0x0
  Window id: 0x2000015 (info) | Window id: 0xc00015 (info)
  Window id: 0x200001c (command) | Window id: 0xc0001c (command)
  Window id: 0x200001f (widget) | Window id: 0xc0001f (widget)
  Window id: 0x2000022 (pop up) | Window id: 0xc00022 (pop up)
  Window id: 0x200002a (magnify) | Window id: 0xc0002a (magnify)
  XImage: | XImage:
    width, height: 256x256 | width, height: 256x256
    format: 2 | format: 2
    byte order: 0 | byte order: 0
    bitmap unit, bit order, pad: 32 0 32 | bitmap unit, bit order, pad: 32 0 32
    depth: 8 | depth: 8
    bytes per line: 256 | bytes per line: 256
    bits per pixel: 8 | bits per pixel: 8
    red, green, blue masks: 0x0 0x0 0x0 | red, green, blue masks: 0x0 0x0 0x0
  Pixmap: | Pixmap:
    width, height: 256x256 | width, height: 256x256
  Window id: 0x2000030 (pan) | Window id: 0xc00030 (pan)
  Client Message: 0x2000011 0xe1 32 0xe4 | Client Message: 0xc00011 0xe1 32 0xe4
  Configure Notify: 0x2000011 607x590+800+800 0| Configure Notify: 0xc00011 607x590+800+800 0
  Reparent Notify: 0x80006c=>0x2000011 | Reparent Notify: 0x8000b1=>0xc00011
  Configure Notify: 0x2000011 607x590+637+28 1 | Configure Notify: 0xc00011 607x590+649+129 1
  Map Notify: 0x2000011 | Map Notify: 0xc00011
  Expose: 0x2000011 607x590+0+0 | Expose: 0xc00011 607x590+0+0
                                               | Client Message: 0xc00011 0x81 32 0x8b
  Event type: 65 | Event type: 65
  Configure Notify: 0x200002a 256x256+1269+28 0| Configure Notify: 0xc0002a 256x256+1281+129 0
  Configure Notify: 0x2000030 96x93+1269+334 0 | Configure Notify: 0xc00030 96x93+1281+435 0
  Event type: 65 | Event type: 65
  Client Message: 0x2000011 0x81 32 0x8b | Client Message: 0xc00011 0x81 32 0x8b
  Client Message: 0x2000011 0x81 32 0x8b |
  Client Message: 0x2000011 0x81 32 0x8b |
  Client Message: 0x2000011 0x81 32 0x8b |
  Unmap Notify: 0x2000011 |
  Reparent Notify: 0x2b=>0x200000b |
  Configure Notify: 0x200000b 96x93+415+1 0 | Configure Notify: 0xc0000b 96x93+654+110 0
  Configure Notify: 0x200000b 96x93+415+1 0 | Configure Notify: 0xc0000b 96x93+654+110 0
  Map Notify: 0x200000b | Map Notify: 0xc0000b
  Standard Colormap: | Standard Colormap:
    colormap id: 0x21 | colormap id: 0x21
    red, green, blue max: 0 0 0 | red, green, blue max: 0 0 0
    red, green, blue mult: 0 0 0 | red, green, blue mult: 0 0 0
  XImage: | XImage:
    width, height: 96x93 | width, height: 96x93
    format: 2 | format: 2
    byte order: 0 | byte order: 0
    bitmap unit, bit order, pad: 32 0 32 | bitmap unit, bit order, pad: 32 0 32
    depth: 8 | depth: 8
    bytes per line: 96 | bytes per line: 96
    bits per pixel: 8 | bits per pixel: 8
    red, green, blue masks: 0x0 0x0 0x0 | red, green, blue masks: 0x0 0x0 0x0
  Pixmap: | Pixmap:
    width, height: 96x93 | width, height: 96x93
  Expose: 0x200000b 86x93+10+0 | Expose: 0xc0000b 96x93+0+0
                                               | Unmap Notify: 0xc00011
  Configure Notify: 0x2000015 150x28+2+2 0 | Configure Notify: 0xc00015 150x28+2+2 0
  Map Notify: 0x2000015 | Map Notify: 0xc00015
  Event type: 65 | Event type: 65
  Unmap Notify: 0x2000015 | Unmap Notify: 0xc00015
  Event type: 13 | Event type: 13
  Map Notify: 0x2000011 | Map Notify: 0xc00011
  Expose: 0x2000011 607x590+0+0 | Expose: 0xc00011 607x590+0+0
  Unmap Notify: 0x200000b | Unmap Notify: 0xc0000b
  Standard Colormap: | Standard Colormap:
    colormap id: 0x21 | colormap id: 0x21
    red, green, blue max: 0 0 0 | red, green, blue max: 0 0 0
    red, green, blue mult: 0 0 0 | red, green, blue mult: 0 0 0
  Event type: 65 | Event type: 65
  Client Message: 0x2000011 0x81 32 0x8b | Client Message: 0xc00011 0x81 32 0x8b
  Client Message: 0x2000011 0xe1 32 0xe3 | Client Message: 0xc00011 0x81 32 0x8b
  Client Message: 0x2000011 0x81 32 0x8b | Client Message: 0xc00011 0xe1 32 0xe3
  Client Message: 0x2000011 0x81 32 0x8b |
  Client Message: 0x2000011 0x81 32 0x8b |
  Client Message: 0x2000011 0x81 32 0x8b |
  Client Message: 0x2000011 0x81 32 0x8b |
  Button Press: 0x2000011 1 +16+12 | Button Press: 0xc00011 1 +21+37
  Button Release: 0x2000011 1 +16+12 | Button Release: 0xc00011 1 +21+37
  Client Message: 0x2000011 0x81 32 0x8b |
  Unmap Notify: 0x200001f |
  Unmap Notify: 0x200001f |
  Standard Colormap: | Standard Colormap:
    colormap id: 0x21 | colormap id: 0x21
    red, green, blue max: 0 0 0 | red, green, blue max: 0 0 0
    red, green, blue mult: 0 0 0 | red, green, blue mult: 0 0 0
  Configure Image: 607x590=>607x590 | Configure Image: 607x590=>607x590
  XImage: | XImage:
    width, height: 607x590 | width, height: 607x590
    format: 2 | format: 2
    byte order: 0 | byte order: 0
    bitmap unit, bit order, pad: 32 0 32 | bitmap unit, bit order, pad: 32 0 32
    depth: 8 | depth: 8
    bytes per line: 608 | bytes per line: 608
    bits per pixel: 8 | bits per pixel: 8
    red, green, blue masks: 0x0 0x0 0x0 | red, green, blue masks: 0x0 0x0 0x0
  Unmap Notify: 0x200001f | Unmap Notify: 0xc0001f
  Configure Notify: 0x2000015 160x28+2+2 0 | Configure Notify: 0xc00015 160x28+2+2 0
  Map Notify: 0x2000015 | Map Notify: 0xc00015
  Configure Notify: 0x2000015 202x28+2+2 0 | Configure Notify: 0xc00015 202x28+2+2 0
  Configure Notify: 0x2000015 195x28+2+2 0 | Configure Notify: 0xc00015 195x28+2+2 0
  Unmap Notify: 0x2000015 | Unmap Notify: 0xc00015
  Client Message: 0x2000011 0xe1 32 0xe3 | Client Message: 0xc00011 0xe1 32 0xe3
  Event type: 65 | Event type: 65
  Configure Notify: 0x2000011 96x93+0+0 0 |
  Expose: 0x2000011 96x93+0+0 |
  Event type: 65 |
  Configure Notify: 0x2000030 96x93+1269+334 0 |
  Reparent Notify: 0x80007d=>0x2000030 |
  Configure Notify: 0x2000030 96x93+1278+343 1 |
  Map Notify: 0x2000030 |
  XImage: |
    width, height: 96x93 |
    format: 2 |
    byte order: 0 |
    bitmap unit, bit order, pad: 32 0 32 |
    depth: 8 |
    bytes per line: 96 |
    bits per pixel: 8 |
    red, green, blue masks: 0x0 0x0 0x0 |
  Pixmap: |
    width, height: 96x93 |
  Expose: 0x2000030 96x93+0+0 |
  Configure Notify: 0x2000015 150x28+2+2 0 |
  Map Notify: 0x2000015 |
  Event type: 65 |
  Unmap Notify: 0x2000015 |
  Client Message: 0x2000011 0x81 32 0x8b |
  Client Message: 0x2000011 0x81 32 0x8b |
  Client Message: 0x2000011 0x81 32 0x8b |
  Client Message: 0x2000011 0x81 32 0x8b | Client Message: 0xc00011 0x81 32 0x8b
  Button Press: 0x2000011 3 +35+75 | Button Press: 0xc00011 3 +45+449
  Unmap Notify: 0x200001f | Unmap Notify: 0xc0001f
  Client Message: 0x2000011 0xe1 32 0xe8 | Client Message: 0xc00011 0xe1 32 0xe8
  bash$ exit | bash$ exit
  exit | exit
                                               |
  Script done on Tue Oct 8 18:22:31 1996 | Script done on Tue Oct 8 18:10:57 1996

----------------------------------------------------------------------

  From: cristy_at_magick.es.dupont.com (Cristy)
  Date: Wed, 9 Oct 1996 14:50:54 -0330
  To: Dave Bodenstab <imdave_at_synet.net>
  Subject: Re: -debug output for weird fvwm problem

  It's all coming back to me now... I investigated this problem a couple of
  years ago. I'm convinced the problem is with fvwm. Fvwm is sending
  a suprious configure notify:

    Configure Notify: 0x2000011 96x93+0+0 0

  This notify does not occur unless you iconify first and it appears that the
  notify is the same size as the icon. However, the icon window is a different
  ID than the image window.

  ImageMagick is just doing what it is told. Fvwm says to resize yourself to
  96x93, so it does. No other window manager (that I know of) sends this
  particular message.

  cristy_at_dupont.com

----------------------------------------------------------------------

END of bug report


--
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 Wed Oct 09 1996 - 14:26:30 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:59 BST