GNOME Flashback: setting/changing the icon used in the taskbar & app switcher


In a GNOME Flashback session using Metacity, which component, process or daemon is responsible for setting the inital application icon that appears in the taskbar & the Alt-Tab app switcher, and/or change/modify it during the application’s runtime (if it’s not done by the application itself)?

Here’s some background information for this admittedly rather strange question. :slight_smile:

In gnome-terminal, I have a profile called “Mutt”, which sets the initial terminal title to “Mutt” and starts, well, mutt, and another profile called “Slrn”, which sets the initial terminal title to “Slrn” and starts, you guessed it, slrn. After login, I always start a separate gnome-terminal window with the “Mutt” profile, and a second tab in that window with the “Slrn” profile.

In addition to that, I also have a little “daemon” (it’s actually just a backgrounded #!/bin/bash script) started on login, which waits for a window titled “Mutt” or “Slrn” to appear using xdotool, and then sets a special icon (one for “Mutt”, another one for “Slrn”) for that windows using xseticon. If the window title changes from “Mutt” to “Slrn” or vice versa, the “daemon” changes the window icon accordingly. This “daemon” keeps running as long as gnome-session-binary appears in ps, and then quits. So if I switch back and forth between the “Mutt” and “Slrn” tabs, the icon shown in the taskbar and the Alt-Tab app switcher changes accordingly, and shows which one of the two is currently active. And if I logout of my session, the “daemon” terminates as well.

So far, so good, all of this works actually fine … BUT. :wink:

Every now and then, in irregular intervals, not following any special “desktop actions” or other patterns that I would be aware of, the icon of that particular window gets reset to the normal gnome-terminal application icon, and loses its special “Mutt” or “Slrn” icon that was set by the “daemon”. I can immediately get the special icon back if I click into that window and switch tabs from “Mutt” to “Slrn” or vice versa, and then that special icon stays again … until, at some random time, by some unknown (to me) process and for some unknown (to me) reason, it gets reset to the default gnome-terminal app icon again. Rinse, repeat. :roll_eyes:

So I would like to be able to identify this particular component of the GNOME Flashback session that keeps doing this, and understand why, how, and when it does that, so I can possibly find a workaround that makes the special icon for my “Mutt”/“Slrn” window permanent.

Yes, I know, I could simply set the special icon every 0,5 seconds or so as long as the daemon “sees” the matching window title, but I’d rather only change the icon when I actually switch tabs.

I can also show you the “daemon” script if necessary, but I don’t think the root cause is in there. There’s nothing in it that would set the icon to gnome-terminal’s default app icon on any window. :man_shrugging:

Can anybody help me with this, and point me into the right direction? I would really appreciate that. Thanks! :+1: :slight_smile:

If the icon gets changed it almost certainly is the app itself that changes it and my guess would be that this happens at a toolkit level, i.e. gtk(3).

1 Like

Thanks for pointing that out!

So you think gnome-terminal (or rather gnome-terminal-server, which seems to be the only running process actually related to gnome-terminal) itself is changing the icon back to default? Hm, I haven’t thought of that, TBH.

Any specific GTK API calls that I should be looking for in the source code? :thinking:

I found gtk_window_set_default_icon_name (GNOME_TERMINAL_ICON_NAME); in terminal_app_init() in line 841 in src/, but this seems to only get called once per newly created app window (ie. “burger” menu => “New Window”, or Ctrl-Shift-N), so that shouldn’t be interfering with an icon that has been set later on by different means (like xseticon), no?

The only other occurence of GNOME_TERMINAL_ICON_NAME is in terminal_util_show_about() in line 258 in src/, and that only shows the default icon in the “burger” menu => About window.

Like I said, I would look rather at the toolkit level, not gnome-terminal itself.

Oh, sorry, seems like I misunderstood you then. :innocent:

So you mean I should be looking within GTK directly, if there’s anything that would automagically cause “GTK itself” to set/update the app icon, ie. as some sort of built-in automatic feature that is provided to any app linking against it, without the app itself having to explicitly request and/or care about it?

I actually assumed that you meant I should look for gnome-terminal making calls into into GTK that would cause that behaviour. Oops. :grimacing:

Thanks for clearing that up! :+1: Well then … grep -ril icon /usr/local/src/gtk+-3.24.41 can’t be that bad, now, can it? :stuck_out_tongue:

It looks like the code of gtk_window_set_default_icon_name gives a possible explanation.

Hm, does it? :thinking: I’ve been staring at the code for a while now, but there was no :bulb: appearing above my head, unfortunately. But then, I’m neither a programmer/developer, nor do I know anything about GTK’s internal runtime loops, so … :man_shrugging:

Or do you mean the loop iterating over all top level windows and doing gtk_window_unrealize_icon()/gtk_window_realize_icon() for each one? But as far as I understand it, that would mean it should always reset the icon whenever I start a new gnome-terminal window, via “burger” => “New Window” or Ctrl-Shift-N, no? However, this is not the case. I can start any number of new gnome-terminal windows, and the special icon remains as it should.

Until, of course, some random time later, when it doesn’t anymore. :wink:

And unfortunately I’ve never actually seen it happen “live”, at the very second it resets back, where I could have at least a theoretical chance of thinking “Oh, I just did X, and that could have caused it!”, or “Oh, Y just happened on the desktop, and the icon got reset with it!”. I only ever notice it after the fact, and at that point I have no idea how long it’s been like that already. :man_shrugging:

It will not happen when you open a window with a title that causes your “daemon” to change the icon immediately afterwards, but if you open a terminal with a different title, maybe due to running some application that starts in a terminal or opening a terminal from the file manager, those might use a different profile. That also depends on how exactly your “daemon” works. If it only applies the icons to the newly created window or if it goes through all windows whenever a new window is created.

Or it could be some other trigger. Like I said it is just “a possible” explanation, not necessarily the one that applies in your case. It should give you an idea what to look for though.

Well, figuring out what exactly is causing this on the toolkit (ie. GTK) level is way beyond my capabilities, I’m afraid. Meanwhile, I worked around the problem by modifying my “daemon” to stubbornly set the icon if it finds a matching window in every pass of the loop, instead of setting it only once, and then wait for the window title to change.

Here’s the “before” and “after” versions of the “daemon”, just for reference, and/or in case anyone is interested.


while sleep 0.5 && pgrep -f gnome-session-binary 2> /dev/null; do

    xseticon -id "$(while ! xdotool search --onlyvisible --name "^Mutt$"; do sleep 0.5; done)" /usr/local/share/icons/mutt-48x48.png &> /dev/null &
    xseticon -id "$(while ! xdotool search --onlyvisible --name "^Slrn$"; do sleep 0.5; done)" /usr/local/share/icons/slrn3_32x32.png &> /dev/null &

    wait %1 && echo "found Mutt window, setting icon" >&2
    wait %2 && echo "found Slrn window, setting icon" >&2



while sleep 1 && pgrep -f gnome-session-binary 2> /dev/null; do

    xseticon -name "Mutt" /usr/local/share/icons/mutt-48x48.png &> /dev/null
    xseticon -name "Slrn" /usr/local/share/icons/slrn3_32x32.png &> /dev/null


Good enough, works for me™. :man_shrugging: :wink: Thanks for all the input & feedback, much appreciated! :+1: :slight_smile: