Subject: Notification: incoming/333

From: [email-masked]
Date: Sat, 8 May 1999 22:03:37 -0500 (CDT)

FVWM Bug Tracking notification

new message incoming/333

Message summary for PR#333
	From: [email-masked]
	Subject: 2.3.2 - Eterm & Icon Inconsistencies
	Date: Sat, 8 May 1999 22:03:36 -0500 (CDT)
	0 replies 	0 followups

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

---

From: Matthias Clasen <[email-masked]>
Date: Mon, 10 May 1999 14:20:42 +0200

> Hi folks & gurus!
> 
> I found in the last fvwm2-snapshot (May 7 1999), that although
> individual styles can be assigned to programs based on their 
> name/resource, this is not necessarily true for the icon name (and thus,
> icon).
> Specifically, there seems to be a problem with Eterms, other terminals 
> seem to work fine.
> 
> If I use a synthax like the following, the Eterms simply get their
> "default" gnome/Eterm-icon as if I didn't define anything for them, 
> whereas xterm, nxterm, rxvt, and gnome-terminal behave as they are told.
> The settings for window decorations work ok, though.
> 

This is a result of Dominik's last "fix" for active icons (dated May 4).
Previously we had the following order of precedence:

Style-supplied icon > client-supplied active icon > client-supplied pixmap

Dominiks fix changed this to

client-supplied active icon > Style-supplied icon > client-supplied pixmap

This gives the behaviour Dominik wanted for xterms (you can provide a 
style icon for xterms and still have xterms with active icons), but
it has the unpleasant side-effect, that it is no longer possible to 
override active icons. 

I think that for maximal flexibility and backwards compatibility, we
should revert to the old behaviour, but add a new trivalued style option
to change the "overriding strength" of the style-supplied icon. Something
like

IconOverride/NoActiveIconOverride/NoIconOverride

where IconOverride would be set by Icon style options to give the 
maximal overriding strength, which could then be lowered. With this
new option, the behaviour Dominik wants can be achieved via

Style ... Icon foo.xpm NoActiveIconOverride

Dominik, what do you say, would this be acceptable ? 

> In addition to that, the Eterm icon jumps around occasionally.

Don't know about that

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Dominik Vogt <[email-masked]>
Date: Mon, 10 May 1999 15:35:07 +0200

> it has the unpleasant side-effect, that it is no longer possible to 

Yup. My O'Reilley says this is The Right Thing To Do. If the application
wants to use its own icon window the window manager must not interfere.
If the user doesn't want it he should turn it off in the application, not
in the window manager. In case of an xterm it's very easy. Simply don't
start the xterm with '+ai'.

> Dominik, what do you say, would this be acceptable ? 

I have no strong feelings here, but I don't see a need. I believe all
applications with 'active icons' (should) have an option to turn it
off. Overriding the application supplied icon window may even confuse
the application. 

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [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: Matthias Clasen <[email-masked]>
Date: Mon, 10 May 1999 15:52:17 +0200

> wants to use its own icon window the window manager must not interfere.

Let me play the ICCCM advocate again: 
  (by the way, some time ago I found  a nice Q in the X faq: 
   What is the ICCCM ? The most-important of the least-read X docs)

"The icon_window field is the ID of a window the client wants used as its icon.
 Most, but not all, window managers will support icon windows. Those that do 
 not are likely to have a user interface in which small windows that behave 
 like icons are completely inappropriate. Clients should not attempt to 
 remedy the omission by working around it."

Thus clients must *not* depend on their icon window hint being respected.
The wm *can* interfere.

> start the xterm with '+ai'.

Seems that it is not so easy with Eterm (see the bug report). 

> applications with 'active icons' (should) have an option to turn it

Unfortunately, fixing the apps to work with the wm is not an option for
us.

> off. Overriding the application supplied icon window may even confuse

See my quote above. Apps which rely on their hints being obeyed are 
seriously broken. But they can still be catered for using the proposed
NoActiveIconOverride.

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 10 May 1999 16:04:52 +0200

>    What is the ICCCM ? The most-important of the least-read X docs)

And of the least quality ;-)

> seriously broken. But they can still be catered for using the proposed

If it's really a problem, okay. But please make the default that the
active icon has the highest priority. The problem is much worse in this
direction.

Bye

Dominik ^_^