Subject: Notification: incoming/582

From: [email-masked]
Date: Fri, 10 Mar 2000 13:35:57 -0600 (CST)

FVWM Bug Tracking notification

new message incoming/582

Message summary for PR#582
	From: [email-masked]
	Subject: IconMan does not draw miniIcons when apps are started iconified
	Date: Fri, 10 Mar 2000 13:35:55 -0600 (CST)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 21 Mar 2000 10:44:59 -0500

On Fri, Mar 10, 2000 at 01:35:57PM -0600, [email-masked] wrote:
> When starting X apps iconified, IconMan adds the iconified window name to
> it's list, but does not draw the mini-icon associated with the app as
> feedback that it knows that the app is iconified.  De-iconifying and re-
> iconifying the app fixes the problem.
> 
> Here are a couple of specific examples that cause the bug for me:
> 
> xcalc -iconic &
> 
> xterm -iconic &
> 
> 

I started tracking this down, but haven't had much luck.  I did notice
that FvwmWinList suffers the same problem so I started inspecting the
packet send in ADD_WINDOW.  It seems the is_iconified field is always
zero when the modulses get it.  Unfortunatelly I don't know to much
about the packet strucutre so maybe someone more in the know could take
a look at that side for me.

However the pager does handle iconified windows correctlly.  So I can't
believe that the packet is the real problem.  Both IconMan and WinList
being broken is probabbly a reflection of the fact that they share so
much code.

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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: Olivier Chapuis <[email-masked]>
Date: Tue, 21 Mar 2000 20:31:55 +0100

> being broken is probabbly a reflection of the fact that they share so

Note: The TaskBar and IconBox suffers the same problem ...
Olivier

---

From: Michael Han <[email-masked]>
Date: Wed, 22 Mar 2000 22:27:58 -0800

Previously from Olivier Chapuis
>Note: The TaskBar and IconBox suffers the same problem ...

I would venture the guess that there's something funny going on
related to the GSFR. I patched up FvwmDebug to be GSFR-aware and
debugged a sample 'xterm -iconic' for kicks. Here's the output showing
the M_ADD_WINDOW and M_OLD_ADD_WINDOW packets:

Add Window
         ID 4c0000e
         frame ID 8002f1
         fvwm ptr bfbff5f0
         frame x 0
         frame y 0
         frame w 671
         frame h 422
         desk 0
         title height 22
         border width 6
         window base width 19
         window base height 4
         window resize width increment 8
         window resize height increment 16
         window min width 27
         window min height 20
         window max 32767
         window max 32767
         icon label window 0
         icon pixmap window 0
         window gravity 1
         forecolor 0
         backcolor 8b7500
         flags 6
Old Add Window
         ID 4c0000e
         frame ID 8002f1
         fvwm ptr 80d9c00
         frame x 0
         frame y 0
         frame w 671
         frame h 422
         desk 0
         flags 62006400
         title height 22
         border width 6
         window base width 19
         window base height 4
         window resize width increment 8
         window resize height increment 16
         window min width 27
         window min height 20
         window max 32767
         window max 32767
         icon label window 0
         icon pixmap window 0
         window gravity 1

Strangely, each packet returns a different fvwm frame pointer. But
most important is the fact that the flags in an old-style packet are
*clearly* wrong. Something must be going wrong with the creation of
old-style vpackets. But I wouldn't expect the modules to be distracted
by these malformed packets. Any ideas here? I'll continue to dig
deeper.

BTW, I'll also diff FvwmDebug, if there's interest. It should probably
be kept up to date.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
A double negative is a no-no.
--
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]