Hi! This is reported every once in a while. If I remember correctly, this is because fvwm doesn't handle UTF-8 window title properly. Closing as INCOMPLETE until there is evidence that this is a GIMP problem.

I tracked it a little further, thanks for the hint about UTF-8 window
titles.

The problem is that even for systems (or users) where filenames are
restricted to plain ASCII (*), GIMP causes an artificial UTF-8ness of
the window title since it wants to append the name "GIMP" to the
title, separated by an UTF-8 endash character.  This used to be a
simple hyphen in previous GIMP versions, and changing it to endash
broke compatibility with all window managers that are not UTF-8 aware
(which I'm sure covers more than just fvwm, the well-known mwm is a
likely candidate, too).  The win of that change is a small cosmetic
difference most users probably won't even notice (when comparing a
computer where the GMIP title display worked, and one where it didn't,
I didn't see the difference without looking into the source code).

(*) which covers not only the English-speaking area of the world where
ASCII is the native charset but also at least older computer users of
the areas of ISO 8859-1 and ISO 8859-2 (iow., most of Europe), who are
simply used to have filenames in plain ASCII even though their native
language would require more than just ASCII characters

Currently, this endash character is appended to the filename
unconditionally in gimp_display_shell_update_title_idle(), so the user
cannot even change it through the (fairly flexible and sophisticated)
preference settings.  As a compromise, I'd suggest to just include the
endash character into the default title string (and the other
suggested title strings) in the preferences dialog, so those users who
experience UTF-8 incompatibility issues with their window managers at
least stand a chance of changing that in their personal preference
settings.  This obviously adds the risk that users might miss to add
the separator character entirely (so they end up in a window title
saying "foobar.png GIMP", rather than "foobar.png - GIMP"), but that's
certainly a very minor issue, in particular since they could always
revert to one of the pre-suggested title bar settings by pressing a
simple button.

If this compromise proposal gets some consensus, I'm willing to file
it as a patch here.

Why not make a patch against GTK+ instead that sets an ASCII version of the UTF-8 window title by substituting and/or removing characters outside the ASCII range?

Two things:

First, the image's filename can also be displayed there and it can contain
UTF-8, so there is nothing "artificial" about the window title GIMP sets.

Second, why on earth would we support something ancient that doesn't even
properly support UTF-8. Just get the outdated lagacy stuff fixed please.

> Why not make a patch against GTK+ instead that sets an ASCII version
> of the UTF-8 window title by substituting and/or removing characters
> outside the ASCII range?

I tried to analyze this, it seems gdk_window_set_title() (which is
called by gtk_window_set_title()) at least doesn't detect this
situation at all.  I didn't dig deep enough into it so far to see
whether it would be possible at all to detect the UTF-8-unawareness of
the WM.

> First, the image's filename can also be displayed there and it can
> contain UTF-8, so there is nothing "artificial" about the window
> title GIMP sets.

That's why I mentioned the large number of users who are still using
plain ASCII filenames.  Sure, there's no argument, anybody who wants
to use non-ASCII filenames (and wants proper window title support for
it, which would also cover many applications beyond GIMP) has to have
a UTF-8-aware WM.

Encoding policies have changed so much in the past 20 years, there are
simply people who are sick of it, and try to avoid it wherever
possible (and useful).  Filenames are one area where it is both
possible and useful, at least to me as a German (but I noticed the
same for "old farts" in Eastern European countries).

> Second, why on earth would we support something ancient that doesn't
> even properly support UTF-8.

Because you aren't working with soldiers but with humans, and humans
have their habits.  It's the same reason why I'm still using tcsh,
even though I'd never recommend it to anyone starting Unix today.
Same for fvwm: there's no single other window manager that does the
job the same way I am used to.  (Again, for anyone starting *today*,
the situation is very much different, and I'd never even mention fvwm
to them as an option.)

Finally, because it doesn't cost you anything to change it.  GIMP has
been using a hyphen there for many years, did anybody ever complain
about it, is there a bug report that says this must be an endash
instead?  As I wrote before, 99 % of all users won't even see the
difference.  And, I'm not even requesting you to change the default,
if you're happy about the endash character, continue using it.  Just
make it customizable.  Again, it doesn't cost anything, it would be
moved from hard-coding it:

 if (len)  /* U+2013 EN DASH */
   len += g_strlcpy (title + len, " \342\200\223 ", sizeof (title) - len);

into the respective customizable string.