After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 321915 - Icon name vs name for the tasklist
Icon name vs name for the tasklist
Status: RESOLVED FIXED
Product: libwnck
Classification: Core
Component: tasklist
2.12.x
Other All
: Normal normal
: ---
Assigned To: libwnck maintainers
libwnck maintainers
Depends on:
Blocks:
 
 
Reported: 2005-11-20 08:09 UTC by Kevin Saling
Modified: 2007-06-19 16:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Screenshot of bug (108.71 KB, image/png)
2005-11-20 08:32 UTC, Kevin Saling
Details
Screenshot of correct behavior (77.30 KB, image/png)
2005-11-20 08:42 UTC, Kevin Saling
Details

Description Kevin Saling 2005-11-20 08:09:15 UTC
Please describe the problem:
gnome-terminal provides an option for replacing the default window title.  In
previous versions of the windows-list component this window title was accurately
reflected.  In 2.12.1, it's broken.

Steps to reproduce:
1. launch `gnome-terminal -t top -e top`
2. Observe that gnome-terminal's window title correctly shows "top"
3. Observe that window-list button incorrectly displays whatever value is
configured in gnome-terminal's "Initial Title" field (Edit/Current Profile/Title
and Command)

Actual results:
window-list component does not show the correct window title from gnome-terminal.

Expected results:
window-list component should show correct window title from gnome-terminal.

Does this happen every time?
Yes

Other information:
By the way, after launching a gnome-terminal with a customized window title, I
can force the window-list component to update correctly by going into
gnome-terminal preferences and changing the "Dynamically-set Title" field
(Edit/Current Profile/Title and Command).  This forces the correct display based
on the option selected in this field.
Comment 1 Kevin Saling 2005-11-20 08:32:43 UTC
Created attachment 54963 [details]
Screenshot of bug
Comment 2 Kevin Saling 2005-11-20 08:42:15 UTC
Created attachment 54964 [details]
Screenshot of correct behavior

This is the way it should should work.	This was the behavior in Gnome-2.10.
Comment 3 Olav Vitters 2005-11-20 12:41:18 UTC
There are 3 commands to set the title;
1. Set the window title ('Top' in the screenshot)
2. Set the icons title ('Terminal' in the screenshot)
3. Set both at the same time

At some time gnome-terminal/vte didn't support anything other than the window
title. Since some version it does. Your workaround is just working around that
the option updates the icon title again from the window title (done for
consistency).

Please try the following:

 echo -ne "\033]1;Icon title\007\033]2;Window title\007"; sleep 10

This should change the icon title in 'Icon title' and the window title into
'Window title'.

To change both at the same time you would:

 echo -ne '\033;0;Both at same time\007"; sleep 10

If you disagree please reopen + attach a 'script' session (stores a copy of the
output in a file -- make it as short as possible).
Comment 4 Olav Vitters 2005-11-20 12:48:37 UTC
That both at same time was wrong, should be:

  echo -ne "\033]0;Both at same time\007"; sleep 10

(wrong quote character + the ']')
Comment 5 Vincent Untz 2005-12-30 11:49:23 UTC
I'm reopening and moving to libwnck since I'd like to have comments from Elijah, Havoc or Mark.

It seems the tasklist uses the icon name since bug #17994. However, when I read the libwnck doc for wnck_window_get_name(), I read: "Gets the name of the window, as it should be displayed in a pager or tasklist." And now, I'm confused :-)

However, in bug #50944, Havoc made a comment that really makes sense: "I think we should not change this; it's important that the name of the task button match what's in the titlebar, that's a more important UI concern than having a "short" name for the icon."

Also, note that for the selector, we only use wnck_window_get_name(), so if we really want to use the icon name, we should change the selector.
Comment 6 Elijah Newren 2006-01-03 23:17:15 UTC
Our IRC discussion, edited to shorten just slightly:

<elijah> "The WM_ICON_NAME property is an uninterpreted string that the client wants to be displayed in association with the window when it is iconified"
<vuntz> right
<vuntz> what is exactly "iconified"? :-)
<elijah> "minimized"
<vuntz> hrm
<vuntz> it doesn't make sense to me
<vuntz> displaying "Terminal" in the window list is unhelpful if the title shown in metacity is "toto"
<elijah> ah, true
<vuntz> that's what I don't get
<elijah> Perhaps this is part of the braindeadedness of the ICCCM in assuming that "showing" and "iconic" are _the_ two states?
<vuntz> and Havoc made one comment saying the same thing
<vuntz> oh
<vuntz> possible
<elijah> iconic is kind of an ancient anachronism; we have tasklists instead of windows becoming an icon on a desktop when being "minimized"
<elijah> for minimized-to-an-icon, having a different name probably makes sense, whereas it probably doesn't for minimized-to-tasklist.
<vuntz> yes, I remember this time
<vuntz> fondly
<elijah> also, bug 124463 (or a change of it) might be helpful/useful in resolving/mitigating this conflict
<elijah> though I'm guessing there multiple apps out there expecting to have an icon name shown when minimized and that do something special with that name and will be mad at us if we violate the ICCCM here
<vuntz> nod
<elijah> maybe we could just violate the ICCCM only when the title is "short"?  ;-)
<elijah> erm, I mean when the icon title is short and the real title isn't?


Anyway, it seems like the ICCCM was designed with absolutely no knowledge of tasklists/taskbars and made some decisions detrimental to the use of such.  However, some apps may have come to rely on this behavior to do weird stuff (e.g. see the comment by the reporter in bug 50944) so we might take some heat for explicitly violating the ICCCM.  It may be the best choice, though (as per Havoc's comments that Vincent quoted above).

I agree with Vincent that it'd be nice to get Havoc or Mark to comment.  :)
Comment 7 nutello 2006-09-25 13:37:21 UTC
There are programs that change the window title. The most popular one is probably GNU screen. Things got very annoying for me because the window list applet was not in sync with the gnome-terminal window title. If the window title changed to signal activity in another GNU screen virtual terminal, that change was not reflected in my window list. That's because the window list pays attention only to the icon name. I couldn't minimise the terminal any longer: I had to keep it visible at all times, pay attention to beeps or check on it from time to time.

I found that there's an alternate termcap entry which fixes the problem, xterm+sl. It uses both the window and icon names for the status line. There doesn't seem to be a way to tell gnome-terminal to set a different value for TERM, so I added a line to my ~/.bashrc file:


TERM=${TERM/%xterm/xterm+sl}

A comment introducing the termcap entry points to some applications that do care about the icon name:

# These entries allow access to the X titlebar and icon name as a status line.
# Note that twm (and possibly window managers descended from it such as tvtwm,
# ctwm, and vtwm) track windows by icon-name; thus, you don't want to mess
# with it.

For twm and descendants, there's a special xterm+sl-twm entry, too.

None of the above really fixes this bug, but at least I'm documenting a workaround for it, if anyone else is affected by it.
Comment 8 Vincent Untz 2007-06-19 16:09:27 UTC
I'm closing this now.

Rationale for this:

 + most (if not all) recent applications are using the same title for name and icon name
 + old applications might use different titles
 + people who don't really care are generally using recent applications
 + people who really care are the people who are customizing stuff or using old applications and they'll want to keep the icon names
 + applications changing the name and not the icon name to tell about a state change should probably be fixed, since it's probably the app author who didn't think about this issue

Also, for easy reference, those are other closed bugs related to this: bug #17994, bug #50944, bug #124463