Subject: FVWM: strings in icons

From: Achyutram Bhamidipaty <[email-masked]>
Date: Wed, 14 Aug 1996 15:53:49 -0700

My xterms frequently change the string that is displayed
in the icon.  I've noticed that fvwm-2.0.43 does not
resize the icon to take the new name into account.

Hmm. Now that I think about that its not completely true. If
the mouse moves over the icon then the whole name is displayed.
But when the mouse is moved away from the icon the original
(truncated) name comes back.  Finally if I restart fvwm the
icons end up with the correct info.

If there is some config parameter that can change this please
let me know.

Also if possible, please CC me since I am not on this mailing list.
-Ram
[email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Richard Lister <[email-masked]>
Date: Thu, 15 Aug 1996 10:14:59 +0100

On Wed, 14 Aug 1996 15:53:49 -0700
Achyutram Bhamidipaty <[email-masked]> 
> icons end up with the correct info.

Ram

If you use pixmaps for icons, the icon title will always be the same
width as the pixmap. If you use no pixmaps (i.e. something like
Style "xterm" Icon none.xpm) then you can fix the problem with
the following patch. Chuck said this will be included in the next release.

Apply the patch in the fvwm-2.0.43/ directory.

Ric

--- fvwm/icons.c.orig	Sun Jun  9 20:57:11 1996
+++ fvwm/icons.c	Thu Jun 13 10:55:51 1996
@@ -809,6 +809,15 @@
     else
       CreateIconWindow(tmp_win, def_x, def_y);
 
+  /* if no pixmap we want icon width to change to text width every iconify */
+  if( (tmp_win->icon_w != None) && (tmp_win->icon_pixmap_w == None) ) {
+    tmp_win->icon_t_width =
+      XTextWidth(Scr.IconFont.font,tmp_win->icon_name, 
+                 strlen(tmp_win->icon_name));
+    tmp_win->icon_p_width = tmp_win->icon_t_width+6;
+    tmp_win->icon_w_width = tmp_win->icon_p_width; 
+  }
+
   AutoPlace(tmp_win);
   tmp_win->flags |= ICONIFIED;
   tmp_win->flags &= ~ICON_UNMAPPED;
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Achyutram Bhamidipaty <[email-masked]>
Date: Thu, 15 Aug 1996 10:12:11 -0700

> the following patch. Chuck said this will be included in the next release.

This patch partly corrects the problem. When I start X up my .xinitrc
file starts a bunch of xterms iconified, and after a few seconds the
shell issues some escape sequence that changes the icon name... So in
this case the icon name for the initially display icon is truncated. If
I open the window and then re-inconify all is well.

In any case thanks for the quick response.

-Ram

---

From: Richard Lister <[email-masked]>
Date: Fri, 16 Aug 1996 00:42:50 +0100

On Thu, 15 Aug 1996 10:12:11 -0700
Achyutram Bhamidipaty <[email-masked]> 
> I open the window and then re-inconify all is well.

Yes, this is a timing problem. Originally fvwm only calculated the
icon width when the icon was created. This was why doing a Restart
fixed the icon width. My patch causes it to be recalculated on every
Iconify (if there is no icon pixmap). The problem here is that
the window is created and the initial iconify happens before the shell
starts and issues its comands to change the icon name. 

Now, perhaps someone out there with better knowledge of X than me will
tell me if I'm wrong, but there is no way for fvwm to be informed of
a change in the icon name. It must make explicit calls to XGetWMIconName().

Hmm, could one write a module (FvwmDaemon) that sat and polled 
windows for a set of properties, and issued fvwm commands based upon
the results? What would the overhead be? Is it a silly late-night idea? :-)

Anyway, Ram, perhaps you could get around your problem by putting a delay
in your .xinitrc, a bit like this:

xterm -iconic &
xterm -iconic &
sleep 10         # enough time for the shells to start
fvwm             # now safe to start wm and iconify windows

Ric

Richard J. Lister, Research Assistant    
Neural Computing Research Group, Aston University
[email-masked] 
http://www.ncrg.aston.ac.uk/~listerrj/ 
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Jason L Tibbitts III <[email-masked]>
Date: 15 Aug 1996 23:15:35 -0500

>>>>> "RL" == Richard Lister <[email-masked]> writes:

RL> Now, perhaps someone out there with better knowledge of X than me will
RL> tell me if I'm wrong, but there is no way for fvwm to be informed of a
RL> change in the icon name. It must make explicit calls to
RL> XGetWMIconName().

How does FVWMWinList do it?  It reacts to changes in the icon name
instantly and doesn't seem to be polling.  Hmm, from the source it seems it
waits for ConfigureWindow packets.  It's been a while since I was in that
code so I'm not really up to following it further.

 - J<

---

From: Richard Lister <[email-masked]>
Date: Fri, 16 Aug 1996 12:41:23 +0100

On Fri, 16 Aug 1996 00:42:50 +0100
Richard Lister <[email-masked]> 
> a change in the icon name. It must make explicit calls to XGetWMIconName().

Well, duh! Repeat after me, Ric: "I will not try to think about difficult
X things while half-asleep". :-)

OK, I wasn't thinking. *Obviously* fvwm is informed of the icon_name change
since it redraws the name string in the icon. It just doesn't do a redraw
of the whole icon window.

So, here's what happens. Fvwm get a PropertyNotify event with value
XA_WM_ICON_NAME, and HandlePropertyNotify() calls RedoIconName().
It also does a BroadcastName() so that modules know about it, too. 

RedoIconName() just does a redraw of the icon_name string in the icon
window. So, here's a patch to it that does a whole new Iconify() for
icons with no pixmap. (Can someone smart please check my call to
Iconify() isn't bogus). Note: if the icon name gets wider and the icon
window no longer fits in the icon box without overlap, the icon will move
to a new location. I find this OK ... do other people find this desirable? 

Anyway, Ram, try this (in addition to my other patch) and see if it fixes
your problem.

--- fvwm/icons.c.orig	Fri Aug 16 11:30:38 1996
+++ fvwm/icons.c	Fri Aug 16 12:38:30 1996
@@ -334,9 +334,15 @@
   
   Tmp_win->icon_t_width = XTextWidth(Scr.IconFont.font,Tmp_win->icon_name, 
 				     strlen(Tmp_win->icon_name));
-  /* clear the icon window, and trigger a re-draw via an expose event */
-  if (Tmp_win->flags & ICONIFIED)
-    XClearArea(dpy, Tmp_win->icon_w, 0, 0, 0, 0, True);
+
+  if (Tmp_win->flags & ICONIFIED) {
+    /* if no pixmap make new icon as the title may have changed size */
+    if( Tmp_win->icon_pixmap_w == None )
+      Iconify(Tmp_win, 0, 0);
+    else
+      /* clear the icon window, and trigger a re-draw via an expose event */
+      XClearArea(dpy, Tmp_win->icon_w, 0, 0, 0, 0, True);
+  }
   return;
 }

Ric