Re: FVWM: FvwmIconMan Bug?

From: Allen Brady Montz <bradym_at_cs.arizona.edu>
Date: 23 Dec 1996 16:00:37 -0700

rugolsky_at_ead.dsa.com (Bill Rugolsky Jr.) writes:

>
> I are currently migrating from vtwm to fvwm-2.0.43 on SunOS 4.1.3 and
> Solaris 2.5.1. My enviroments are as follows:
>
...
> In the process of migrating, I have uncovered the following problems
> with FvwmIconMan:
>
> 1. The configuration option:
>
> *FvwmIconMan*resolution page
>
> causes FvwmIconMan to exhibit buggy behavior when switching pages; in
> particular, there appears to be an off-by-one error in the viewport
> bounds-checking logic. This bug causes a window that abuts the edge
> of the screen to appear in the icon manager on multiple pages. I
> traced the bug to the function win_in_viewport() in file
> modules/FvwmIconMan/fvwm.c . Rather than attempt to debug the logic,
> I just simplified it. The new function definition and context diff are
> appended to this message.


I'm the author of FvwmIconMan.

This might not be a problem with FvwmIconMan. In the last few years, I've seen
this behavior fairly often, but when looking REAL careful, it always turns out
that the offending window is actually extending into the next page by 1
pixel. Xv seems fond of doing this when it resizes and moves itself.I've
though about making a little fudge in the logic so that a window has to be in
the current page by at least a few pixels to count. Please check if this is
what's happening for you. An easy way to check is to set EdgeResistance in
your .fvwm2rc to something nice and big (I use "EdgeResistance 10000 100") and
then move the offending window up the the edge of the page. With
EdgeResistance set, fvwm should keep the window entirely in the current page.

As for your patch, it seems correct. How embarrassing.

>
> 2. There appears to be a problem with the "dontshow" configuration
> option. We have a misbehaving news application that continuously
> updates the icon name and title with progress information. This produces
> unpleasant behavior, particularly over ISDN. I tried using the following
> lines in my .fvwm2rc to suppress the headline window in the icon manager:
>
> Style "*Query*Headline*" Icon news.xpm
> Style "*received*of*" Icon news.xpm
> *FvwmIconMan*dontshow *Query*Headline*
> *FvwmIconMan*dontshow *received*of*
>
> This has the desired effect upon starting the application. However, if
> I iconify the window, it suddenly appears in the icon manager. Under
> FvwmIconMan-0.5, it remained in the icon manager. Using FvwmIconMan-0.9,
> the icon is removed from the icon manager when it is de-iconified. I tried
> creating separate lines with title= and icon= before the patterns, but
> this did not affect the behavior. I have successfully worked around the
> problem by using the "WindowListSkip" style for these patterns, in place
> of the "dontshow" option to FvwmIconMan.

FvwmIconMan determines which manager, if any, manages a window each time the
window name changes. I can't tell from what you said whether this is the cause
of your problem, or if the problem stems from a bug in this process. Could you
be more specific about what the title and icon names are when the program is
showing up in the manager, and when it isn't? Also, does the window title or
icon name change when the window is uniconified? A good thing to do is bind:

*FvwmIconBoxMouse 3 Click Module FvwmIdent

in your .fvwm2rc and then clicking the third mouse button on a window in the
manager runs FvwmIdent on it.

I haven't tested this code too thoroughly (ie, I don't use it in real life, so
I've only tested it with xterms changing their icon and title names), but I
can't reproduce this behavior.

Also, ouy of curiosity, what the "unpleasant behavior" that results when this
news program is listed in the manager?

-- 
 Brady Montz
 bradym_at_cs.arizona.edu
--
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 Mon Dec 23 1996 - 17:00:49 GMT

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