Subject: CVS domivogt: * Fixed an icon_override problem and put some debug output in the icon selection code.

From: CVS <[email-masked]>
Date: Thu, 4 Jan 2001 17:04:06 -0600 (CST)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	01/01/04 17:04:06

Modified files:
	.              : ChangeLog 
	fvwm           : add_window.c events.c icons.c 

Log message:
* Fixed an icon_override problem and put some debug output in the icon selection code.

--
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: Dan Espen <[email-masked]>
Date: Mon, 08 Jan 2001 07:31:40 -0500

> * Fixed an icon_override problem and put some debug output in the icon select

This morning (7:30AM EST), XEmacs live-icons don't work at all.
I haven't picked up last nights CVS yet.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Dan Espen <[email-masked]>
Date: Mon, 08 Jan 2001 09:28:09 -0500

> I haven't picked up last nights CVS yet.

Using current CVS, the problem remains.

Recapture changes the icon into an active icon, but
the icon still doesn't update on iconify.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 8 Jan 2001 19:35:18 +0100

> the icon still doesn't update on iconify.

Uh, yes.  With these changes I synchronised handling of the
(No)IconOverride/NoActiveIconOverride styles so that
applications can't enforce their icon wish by changing the icon
hint after the window was mapped.  Xemacs' live icon is not
considered to be an active icon because xemacs uses the icon
pixmap hint, not the window hint.  In other words: you have to
use the "NoIconOverride" style for your xemacs windows.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Dan Espen <[email-masked]>
Date: Mon, 08 Jan 2001 18:43:05 -0500

> use the "NoIconOverride" style for your xemacs windows.

Yep, that makes it work.

Now all we need to do is make "NoIconOverride" the default.

---

From: Dan Espen <[email-masked]>
Date: Mon, 08 Jan 2001 19:45:35 -0500

Dan Espen <[email-masked]> writes:
> > > > > * Fixed an icon_override problem and put some debug output in the ico
> n
> > > > > selection code.
> > > > 

I need to revise these comments.

After I entered:

Style * NoIconOverride

another icon I used changed.

Just setting NoIconOverride as the default won't restore the old
behavior.

The icon that changes is a second XEmacs frame with the resource name
"xmh".  I have:

Style "xmh" Icon mail2.xpm

I used to see the "mail2.xpm" icon, I now see the XEmacs builtin icon.

It looks like, by default, I override program supplied icons, but
when XEmacs "actively" supplies an icon, fvwm used to accept it,
and now it doesn't.

Shouldn't fvwm treat a program changing its pixmap hint the
same way it treats a change in window hint?  Isn't the goal
of the application the same in both cases?

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 9 Jan 2001 10:57:41 +0100

> of the application the same in both cases?

Hm. Possibly we need a new style.  The current three styles were
originally meant to do:

  IconOverride:

    Always use the fvwm provided icon.

  NoIconOverride:

    Always use the application provided icon, if any.

  NoActiveIconOverride:

    Only use live icons provided by the application.

The problem is to define a live icon.  For the old code, a live
icon was identical to an icon provided by an icon window hint.
But the style was only honoured when the window was created.  If
the applications changed the icon later, fvwm would *always* use
the new one, even with IconOverride.

It seems that we need a better definition of live icons.  Will
this one do:

  When window is created:

    Icon provided with icon window hint.

  When icon is changed:

    Any application provided icon pixmap or window hint.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 09 Jan 2001 10:51:00 -0500

>     Any application provided icon pixmap or window hint.

If your latest commit implemented these changes, then it didn't work.
The live icon is working, but the override isn't.  The icon starts out
with the icon I specified but then the built in one replaces it.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 9 Jan 2001 19:50:55 +0100

On Tue, Jan 09, 2001 at 10:51:00AM -0500, Dan Espen wrote:
> If your latest commit implemented these changes,

Yes.

> then it didn't work.

I feared it wouldn't work.  If the application sets the icon hint
too late, fvwm will use it.  Do you have any idea what else we
could do?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Fri, 12 Jan 2001 18:09:25 -0500

> too late, fvwm will use it.  Do you have any idea what else we

I actually don't remember what you were trying to fix.
If it just goes back to the old behavior, it would be
fine with me.