Just to add to the general noise level (and perhaps induce some
knowlegeable one to look into the code to reconcile the conflicting
reports?)... It disturbs me to see information going out that runs
counter to what I observe, if for no other reason than that fvwm should do
the same thing on different platforms, and real discrepancies should be
tracked down and corrected. I get the man-advertised behavior for
FvwmIconBox (manpage dated Jun 24 1994, FvwmIconBox(0.64)):
Indeterminate icon style, or "Style Icon" gives me *no* FvwmIconBox entry
for a window.
Specifically calling out the NoIcon style results in an FvwmIconBox entry
for a window.
Defining "-" as the xpm name for xterm (put into the .fvwm2rc file, of
course, so FvwmIconBox would pick it up on instantiation) resulted in no
icon display for xterms in the FvwmIconBox, regardless of "Style Icon" or
"Style NoIcon".
I temporarily deleted all of my global Style options to avoid as far as I
could any inadvertent FvwmIconBox Style dependencies. With no deliberate
icon'ish Style options, I invoked xterm and xload windows and got no entry
in my newly created FvwmIconBox. Using FvwmTalk, I added "Style XLoad
NoIcon", and then new xload windows were reflected in FvwmIconBox entries.
Similarly for XTerm. "Style XLoad Icon" or "Style XTerm Icon" caused new
instances to be ignored by FvwmIconBox. Why others have different
behavior is an interesting mystery.
I am not using any clever tricks with FvwmM4 or FvwmCpp.
Michael Tiefenback
--
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 Nov 06 1996 - 14:55:49 GMT