[7737] in Athena Bugs
7.3 emacs icon
daemon@ATHENA.MIT.EDU (ckclark@ATHENA.MIT.EDU)
Mon Jul 15 15:29:32 1991
From: ckclark@ATHENA.MIT.EDU
Date: Mon, 15 Jul 91 15:29:22 -0400
To: basch@MIT.EDU
Cc: testers@ATHENA.MIT.EDU, rel-eng@ATHENA.MIT.EDU
In-Reply-To: Richard Basch's message of Sat, 13 Jul 91 13:38:06 -0400 <9107131738.AA21684@tardis>
Reply-To: ckclark@mit.edu
>>>>> On Sat, 13 Jul 91 13:38:06 -0400, Richard Basch <basch@MIT.EDU> said:
Richard> Specifying "emacs*IconGeometry" in my .Xresources no
Richard> longer appears to work. In addition, the icon name has
Richard> changed from "emacs" to "emacs@<host>".
Richard> -Richard
In /mit/emacs/release, you will find two patches, one to
lisp/term/x-win.el and one to src/x11term.c. The patch to x-win.el is
mandatory, as it fixes problems with command line parsing which I just
noticed recently. The patch to x11term.c adds the "iconGeometry" and a
corresponding command line option -icongeometry. It also changes the
default window name and icon name to "emacs". You may apply it if you
want this feature enough to feel like recompiling emacs. (Actually,
with just one file changed, it shouldn't be too bad.) You can apply the
patch to x-win.el without doing this. You don't need to byte-compile
x-win.el. (Although it would only be consistent to remove the
-icongeometry entry in that file, if you choose to do so.) If you want
to have the default window name/icon name be "emacs" *without*
recompiling, then you can always create an app-defaults file for emacs
with the resources:
Emacs*title: emacs
Emacs*iconName: emacs
The rest of this message consists of a flame about why I shouldn't have
bothered with the icon geometry part, although it didn't take long to
write. :-)
(setq flame-mode t)
a) This is a feature request.
b) The ICCCM standard has this to say about the IconPostionHint window
manager hint:
"The (icon_x, icon_y) coordinate is a hint to the window manager as to
where it should position the icon. The policies of the window manager
control the positioning of icons, so clients should not depend on
attention being paid to this hint."
Well said. Modern window managers have there own ideas about icon
position and management, and it is really the window manager's
responsibility to deal with icons. Clients should not get in the way.
I'd like to add that many window managers will ignore or misuse this
information. Don't even think about trying to use geometries with
negative positioning. (Well, their is a way to do it, but it involves
querying the the window manager for all of its icon sizes and trying to
guess from that what the windowmanager will want. Xt programs attempt
this and fail.)
(setq flame-mode nil)
-Calvin
