Subject: bugs in FvwmIconMan

From: [email-masked] (Tim Phipps)
Date: Fri, 19 Nov 1999 16:36:08 GMT

Configuration Information [Automatically generated, do not change]:
uname output: SunOS tazmo 5.6 Generic sun4u sparc SUNW,Ultra-4
Compiler: gcc
Compilation CFLAGS: -g -O2
prefix: /home/tim
sysconfdir: /home/tim/etc
libexecdir: /home/tim/libexec

FVWM Version: 2.3.10
FVWM_CONFIGDIR: unset
FVWM_MODULEDIR: /home/tim/libexec/fvwm/2.3.10
FVWM_USERHOME: unset

Description:
	1) FvwmIconMan gets the wrong Icon when xterm starts.
	2) FvwmIconMan doesn't handle gradient colorsets well.
	3) *FvwmIconManHilightFocusWin doesn't work with colorsets.
	4) Bad hints->client_icon_window cause FvwmIconBox to crash.
Repeat-By:
	
	1) When FvwmIconBox starts it gets the correct but when I
	   open a new xterm it gets the icon set by the DefaultIcon command.
	   I have:
	   	DefaultIcon FileAPP.xpm
	   	Style *term Icon Dtterm.l.xpm
	   Terms that are present when FvwmIconBox start get Dtterm.l.xpm,
	   terms that start after get FileAPP.xpm.
	2) If *FvwmIconBoxColorset is set to a colorset that is a gradient
	   type the gradient isn't stretched to fit the window, If the
	   iconbox is resized the gradient is not stretched. The only time
	   the gradient is stretched is if FvwmTheme recreates the gradient.
	3) Setting *FvwmIconBoxIconColorset  and *FvwmIconBoxIconHiColorset
	   displays the labels in the correct colors but the focussed
	   window is not hilighted.
	4) One of my apps sets the client supplied icon window to 0.
	   FvwmIconBox crashes on a BadDrawable.

--
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: Brad Giaccio <[email-masked]>
Date: Fri, 19 Nov 1999 13:02:43 -0500

You scared me there for a second Tim I was sure I had killed the
colorset related bugs in FvwmIconMan, it seems you are speeking of
FvwmIconBox, since I started the colorset work on both of these I can
take a look, but could you clarify that all of the mentioned problems
are with IconBox and not IconMan.

Brad

-- 
--- 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: Tim Phipps <[email-masked]>
Date: Mon, 22 Nov 1999 09:40:18 +0000

> are with IconBox and not IconMan.
Good grief, how did that happen?  Yes, the bugs are for FvwmIconBox. I
think my fingers have learnt how to type FvwmIconMan all by themselves.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 24 Nov 1999 09:03:05 -0500

Alright Tim, find below a fix for #2 (thanks in advance for applying),
and I'm assuming your commits fixed #1 and #4 (but correct me if I'm
wrong).  As for 3 what window is not higlted? I don't see a difference
here betweeen colorsets and non colorsets.

As I mentioned in my last note to Dominik, if I still have your votes
I'm now able to commit from site.

Brad

On Fri, Nov 19, 1999 at 04:36:08PM +0000, Tim Phipps wrote:
> Description:
> 	1) FvwmIconBox gets the wrong Icon when xterm starts.
> 	2) FvwmIconBox doesn't handle gradient colorsets well.
> 	3) *FvwmIconBoxHilightFocusWin doesn't work with colorsets.

1999-11-24  Brad Giaccio  <[email-masked]>
    * FvwmIconBox/FvwmIconBox.c (Loop):
    if using a colorset gradient or pixmap it is now resized when
    then the manager changes sizes

------------
diff -u -b -B -r1.33 FvwmIconBox.c
--- FvwmIconBox.c       1999/11/23 16:16:35     1.33
+++ FvwmIconBox.c       1999/11/24 13:58:17
@@ -398,6 +398,14 @@
                                  icon_win_height);
                AdjustIconWindows();
                XClearWindow(dpy,main_win);
+               if (colorset >= 0) {
+                     SetWindowBackground(dpy, icon_win, icon_win_width, icon_win_height,
+                 &Colorset[(colorset)], Pdepth, NormalGC,
+                 True);
+                     SetWindowBackground(dpy, main_win, main_width, main_height,
+                 &Colorset[(colorset)], Pdepth, NormalGC,
+                 True);
+               }
                RedrawWindow();
              }
              break;

---

From: Tim Phipps <[email-masked]>
Date: Wed, 24 Nov 1999 15:06:36 +0000

> here betweeen colorsets and non colorsets.
Thanks, every thing is fixed now. The hilight problem is that when you
change focus FvwmIconBox should reflect that, it does now

If you're feeling keen you could change FvwmIconBox so that specifying
icons doesn't require quotes around the window name.  Or you implement
an FvwmIconBoxIconAction option so that Iconification animation can be
done.

Cheers,
Tim.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 25 Nov 1999 12:39:49 +0100

> an FvwmIconBoxIconAction option so that Iconification animation can be

Hello,
It seems also that there are no UseListSkip option. I can add it
if no body want to.
Olivier

---

From: Brad Giaccio <[email-masked]>
Date: Mon, 29 Nov 1999 15:13:15 -0500

> an FvwmIconBoxIconAction option so that Iconification animation can be

I took a look at IconAction and one problem is the icon structure
doesn't keep track, of where the real window is, or even its id, as near
as I can tell.  Do you have a vote on which module I should steal that
from?

Brad

---

From: Tim Phipps <[email-masked]>
Date: Tue, 30 Nov 1999 12:44:39 +0000

> as I can tell.  Do you have a vote on which module I should steal that

FvwmWinList tracks its location by listening for ConfigureNotify
events.  The code in there can pick out the synthetic ones sent by
fvwm.  I don't think you can rely on M_CONFIGURE_WINDOW messages from
fvwm as there is potential to receive information out of order when
things get busy.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 30 Nov 1999 07:51:26 -0500

> fvwm as there is potential to receive information out of order when

I don't think I phrased my question quite right, its not the iconbox
itself I can't track its the windows its managing.  You are right
configureNotify is the right place to track the box itself but
what should I do to track the windows IconBox is managing?  Is
M_CONFIGURE_WINDOW the right place?

---

From: Tim Phipps <[email-masked]>
Date: Tue, 30 Nov 1999 13:02:55 +0000

Brad Giaccio wrote:
> itself I can't track its the windows its managing.

Oh sorry.  Do you mean the location of the icon? If so I think
XTranslateCoordinates from item->icon_win to the root window would
work.  If you mean the location of the window that the icon represents:
the location is in the M_ICONIFY packet (see FvwmWinList)

Cheers,
Tim.