Just to confirm, I've also verified this against GTK+ Version 3.24.34:

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34,
cairo version 1.16.0) of 2022-06-11

Emacs is built as follows:

./configure' '--prefix=/home/hdiags/hdiags/spack/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-11.3.0/emacs-master-tvikd2njjgseq47ywpa5zrlksnz3pylz' '--with-x' '--with-x-toolkit=gtk' '--with-gnutls'

For avoidance of doubt, the issue still occurs when the emacs is started as:

# No server currently running

emacs -q --fg-daemon

emacsclient -F '((name . "foobar") (title . "foobar-title"))' --create-frame

xprop reports:

WM_CLASS(STRING) = "emacs", "Emacs"
WM_ICON_NAME(STRING) = "foobar"
_NET_WM_ICON_NAME(UTF8_STRING) = "foobar-title"
WM_NAME(STRING) = "foobar-title"
_NET_WM_NAME(UTF8_STRING) = "foobar-title"

Using a previous version of emacs (26.3), the same steps produce:

WM_CLASS(STRING) = "foobar", "Emacs"

On Sat, 11 Jun 2022 at 14:00, Colin Horne <colin@cdfh.org.uk> wrote:

> I'm unable to reproduce this on the current trunk (x86_64-pc-linux-gnu,
> GTK+ Version 3.24.31, Debian/bookworm).
>
> Do you still see this issue on the current trunk?

I can confirm that this is still an issue on trunk.

My Emacs welcome screen says:

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29,
cairo version 1.16.0) of 2022-06-11

Invoked as:

emacsclient -F '((name . "foobar") (title . "foobar-title"))' --create-frame -a ""

xprop reports:

WM_CLASS(STRING) = "emacs", "Emacs"
WM_ICON_NAME(STRING) = "foobar"
_NET_WM_ICON_NAME(UTF8_STRING) = "foobar-title"
WM_NAME(STRING) = "foobar-title"
_NET_WM_NAME(UTF8_STRING) = "foobar-title"

This affects me in that I run simultaneous emacs instances as two different users and have different icons configured for the different users. Now that I can't change WM_CLASS, both emacs instances appear under the same icon under my desktop manager, which is very frustrating.

Cheers,
Colin