[vim/vim] GVim seems to have lost its icons (Issue #17703)
Rhialto The M.
Rhialto created an issue (vim/vim#17703)Steps to reproduce
I built vim from the git repo (today's commit b3eaae2) with GTK 3 GUI on NetBSD 10.1
I started the newly build vim with src/vim -g
When I iconified Vim, it did not have an icon, even though it used to have one in the past. Instead my window manager gives me the representation of "this window has no icon, here is a simple default".
Note that on many so-called "desktops", when it claims you are iconifying a window, you are not doing that in the X sense of the word. Generally there is some desktop managing thing that unmaps the Vim window and shows some other window in a bar at the top or the bottom of the screen.
I am in fact using a a window manager that does real iconification, ctwm. Others are twm, fvwm, and many more.
You can see when a window has an associated icon, using a small tool that comes standard with X: xprop. You invoke xprop and it gives you a cursor to point at a window to show its properties.
Example of this on a window that does have an icon, in this case TortoiseHG:
$ xprop
_NET_WM_USER_TIME(CARDINAL) = 3479692782
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x40256e
_NET_WM_STATE(ATOM) =
_NET_WM_DESKTOP(CARDINAL) = 1
WM_OCCUPATION(STRING) = "Two"
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 23, 2
_NET_WM_VISIBLE_ICON_NAME(UTF8_STRING) = "src-public [trunk] - TortoiseHg Workbench"
_NET_WM_ICON_NAME(UTF8_STRING) =
_NET_WM_ICON(CARDINAL) = Icon (16 x 16):
``~~..
""____--.. ''}}ff}}
>>__````..__``..<<rrzz||
""`` <<iixxUUYYZZJJ{{{{!!nnxxrr
\\{{11;;((jjYYQQkkuuff[[rruu11''
iicczzxxxxUUQQZZ[[LLccii..
++ccJJJJjjzzzzffLLdd??
||xxUUllppvvffUUzzJJff~~
;;ffJJ,,~~}}ttff//[[{{
''.. ''<<++
Icon (32 x 32):
++[[11--
;;__>>__"" //ttllLLxx``
ii{{llii__ii//11++ ++rr11wwJJOOll
;;11__;;ii\\11{{\\++ii|| ..]]{{[[YYJJCC~~
^^||,,llxx{{uuxxnnxxzzuu++(('''' __??((JJrrXXCC
;;II,,??((UUrrJJttJJUUJJCCLL>>nnzz~~}}++{{fftt}}tt))
//>>,, ``\\''ll||{{OOXXhhJJooooQQXXYYrrxxff||++))ttJJttzztt\\
??nn[[))__ii__<<//11]]XXjjQQZZoohhhhaazzttOO)))){{nnJJJJJJuu~~
((CCzzuuZZll11)){{ccttttZZZZkkddbbhhLLffUU{{{{]]jj))}}\\
<<LLnn]][[LLZZvvccxxttYYaaddppbbddooXXYYvvjjzzII
,,UUZZ00LLvvffnnffXXhhddwwwwbbppffOOUUJJ??^^
!!nnttbbaaoottuuzzffuucc[[ccttttxxhhmmtt
;;[[{{nnXXOOvvYYQQLLff00ooQQooXXCCoo**bbtt>>
>>cc]]LLCCJJ::cc**kkhhooQQhhbbaaffbbhhJJYYJJ^^
++xxjjCCZZOO<<++QQqq{{))ccLLJJOO{{YYCCxxffUU~~
..nnXXrrzzUUll ..cc\\11nnLLffLL}}}}XXXXoouu
//ZZZZ(( ]]zz00||XX00|| ::''
..::!!nnxx++
Icon (64 x 64):
(not shown)
Icon (128 x 128):
(not shown)
XdndAware(ATOM) = BITMAP
WM_NAME(STRING) = "src-public [trunk] - TortoiseHg Workbench"
_NET_WM_NAME(UTF8_STRING) = "src-public [trunk] - TortoiseHg Workbench"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x3600009
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
window id # of group leader: 0x3600009
WM_CLIENT_MACHINE(STRING) = "murthe.falu.nl"
_NET_WM_PID(CARDINAL) = 18037
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 56623112
_GTK_APPLICATION_ID(UTF8_STRING) = "thg"
_KDE_NET_WM_DESKTOP_FILE(UTF8_STRING) = "thg"
WM_CLASS(STRING) = "thg", "TortoiseHgQt"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 295, 25
user specified size: 1536 by 1119
program specified minimum size: 271 by 484
window gravity: Static
_NET_WM_ICON(CARDINAL) shows a few sizes of icons that this program has supplied.
An older way to specify an icon is by preparing a bitmap and reporting that in a property. This is what XTerm has (excerpt):
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x1400016
bitmap id # of mask for icon: 0x1400018
Currently, Vim with gtk3 (I also saw this with gtk2) has neither, but it used to have this.
Expected behaviour
I expected to see the lovely green Vim icon.
Version of Vim
:version VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Jul 8 2025 18:31:13) Included patches: 1-1525
Environment
NetBSD
xterm
screen.xterm-256color (but irrelevant)
bash
Logs and stack traces
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Rhialto left a comment (vim/vim#17703)The problem does not exist for the Motif build:
$ xprop
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x0, 0x0, 0x48, 0x0, 0x0, 0x0, 0x25, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0xbf, 0x96, 0xa5, 0x7c, 0x0, 0x0, 0x0, 0x0, 0x42, 0x2, 0x0, 0x0, 0x0, 0x3, 0x11, 0x43, 0x2, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0xc4, 0xc4, 0xc4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x0, 0x0, 0x15, 0x0, 0x4b, 0x0, 0x17, 0x0, 0x30, 0x0
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x404c43
_NET_WM_STATE(ATOM) =
_NET_WM_DESKTOP(CARDINAL) = 0
WM_OCCUPATION(STRING) = "One"
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 23, 2
Vim(STRING) = "9.1"
_MOTIF_WM_MESSAGES(ATOM) = _MOTIF_WM_OFFSET
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_SAVE_YOURSELF
WM_CLIENT_LEADER(WINDOW): window id # 0x18002da
WM_LOCALE_NAME(STRING) = "C"
WM_CLASS(STRING) = "vim", "Vim"
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x180001f
bitmap id # of mask for icon: 0x1800021
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: 0, 0
program specified size: 578 by 768
program specified minimum size: 102 by 53
program specified resize increment: 7 by 13
program specified base size: 18 by 27
window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "murthe.falu.nl"
WM_ICON_NAME(STRING) = "[No Name]"
WM_NAME(STRING) = "[No Name] - VIM"
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17703)Can you pinpoint the patch that caused this?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Rhialto left a comment (vim/vim#17703)I guess I will have to bisect. It worked about half a year ago, but that is not a very precise indication. I usually update Vim with stable pkgsrc branches and they are created every 3 months; this is the 2nd time that the icon is missing, so I suppose between 3 and 6 months ago, give or take, it must have changed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Rhialto left a comment (vim/vim#17703)I suspect "patch 9.1.1199: gvim uses hardcoded xpm icon file". It removes a call to gtk_window_set_icon_list() and replaces it with the rather useless tk_window_set_icon_name.
(a few moments later): Yes, 1199 is broken, 1198 is ok.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Rhialto left a comment (vim/vim#17703)The commit message in patch 1199 is kind of bogus too. A window manager (well, the one I use, at least) is perfectly able to override the icon that is specified by the program itself.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17703)thanks, so this comes from #16859 . ping @agateau Seems like this regressed. If we cannot make both work (perhaps keep the gtk_window_set_icon_list() call?), we may have to revert that patch.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Rhialto left a comment (vim/vim#17703)Ah, I was thinking that this gtk_window_set_icon_name() call would do something with "classic" icons, like the name that is displayed under them. But apparently it is there so that the theme can choose an icon for itself? Yes, in that case I would optimistically expect that having both the old code and the new call would / could satisfy both use cases.
(A bit later): perhaps not... if I call gtk_window_set_icon_list() last then I see the icon properties on gvim's window. But if I call gtk_window_set_icon_name()` last, then the icons are absent. So the last call "wins" it seems. Gtk could have done this better...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Rhialto left a comment (vim/vim#17703)Maybe this code would work. It tries to check if there is a theme that has an icon, and if not, uses the old method.
#include "../runtime/vim32x32.xpm"
#include "../runtime/vim16x16.xpm"
#include "../runtime/vim48x48.xpm"
...
if (vim_strchr(p_go, GO_ICON) != NULL)
{
GtkIconTheme *icon_theme;
icon_theme = gtk_icon_theme_get_default ();
if (icon_theme && gtk_icon_theme_has_icon (icon_theme, "gvim")) {
gtk_window_set_icon_name(GTK_WINDOW(gui.mainwin), "gvim");
} else {
/*
* Add an icon to the main window. For fun and convenience of the user.
*/
GList *icons = NULL;
icons = g_list_prepend(icons, gdk_pixbuf_new_from_xpm_data((const char **)vim16x16));
icons = g_list_prepend(icons, gdk_pixbuf_new_from_xpm_data((const char **)vim32x32));
icons = g_list_prepend(icons, gdk_pixbuf_new_from_xpm_data((const char **)vim48x48));
gtk_window_set_icon_list(GTK_WINDOW(gui.mainwin), icons);
// TODO: is this type cast OK?
g_list_foreach(icons, (GFunc)(void *)&g_object_unref, NULL);
g_list_free(icons);
}
g_object_unref (icon_theme);
}
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Aurélien Gâteau
agateau left a comment (vim/vim#17703)I just spent some time looking at the code of gtk_window_set_icon_list() and gtk_window_set_icon_name() of the latest gtk3 release (gtk_window_set_icon_list() does not exist anymore in gtk4) and indeed gtk_window_set_icon_name() clears existing icons. gtk_window_set_icon_list() does not seem to clear the icon name though, so I assume the icon name would stay if gtk_window_set_icon_list() is called last. Will try to find time to test this tonight.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Rhialto left a comment (vim/vim#17703)@agateau I am quite familiar with Vice which uses gtk3, and it uses just gtk_window_set_icon() and nothing else. (For Vim I use gtk2 because I measured the speed compared to gtk3 once, and gtk2 was noticably faster). I have aumix-gtk (gtk2) which is fairly small and which seems to do
icon_pixmap = gdk_pixmap_create_from_xpm_d(window->window, &bitmap, &style->bg[GTK_STATE_NORMAL], aumix_xpm);
gdk_window_set_icon(window->window, NULL, icon_pixmap, bitmap);
C64/Amiga Emulator Denise uses just gtk_window_set_icon().
But what about the method I tried 3 comments up? It seems pretty flexible to me. If you have some icon theme and it has a "gvim" icon, then the icon name is set, otherwise the icon from Vim itself is set. This ought to work nicely even if you do have an icon theme, but the theme has no "gvim" icon. At least I would expect so, I don't even know how I would test icon themes in general (since I don't use gnome nor kde).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Aurélien Gâteau
agateau left a comment (vim/vim#17703)(I am guessing that gtk_window_set_icon_list() sets the _NET_WM_ICON property and gtk_window_set_icon() just the WM_HINTS).
It's a bit simpler than that. Quoting gtk_window_set_icon() doc: "This function is equivalent to calling gtk_window_set_icon_list() with a 1-element list."
But what about the method I tried 3 comments up? It seems pretty flexible to me.
I just tried it and it works for me 👍. I was hoping we could find a way to define the icon name and _NET_WM_ICON, but as it does not seem to be trivial to do, your solution is good enough.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rhialto The M.
Rhialto left a comment (vim/vim#17703)Okay, since nobody seems to come up with a better idea, I have put the code above in a merge request #17814. I could not fill in the patch number of course :) but apart from that I tried to follow the commit format I have seen for other patches.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #17703 as completed via 9d5bb58.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.