This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: tkinter.Tk() adds suffix to window class name when launching multiple instances
Type: behavior Stage: resolved
Components: Tkinter Versions:
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: hakonhagland, serhiy.storchaka, terry.reedy
Priority: normal Keywords:

Created on 2017-06-28 15:18 by hakonhagland, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg297191 - (view) Author: Håkon Hægland (hakonhagland) Date: 2017-06-28 15:18
Hello. In order to group several instances of a given application under one icon in the desktop launcher (I am using Ubuntu 17.04) they must have the same appName property of the WM_CLASS string. For example, if I run emacs twice:

$ emacs &
$ emacs &

Both instances will show up under the Emacs icon in the desktop launchbar. The reason is that both instances have the same WM_CLASS string. We can check this string using

$ xprop WM_CLASS

and then click on the Emacs window. It then shows:

WM_CLASS(STRING) = "emacs", "Emacs"
Here "emacs" is the resource (appName), and "Emacs" is the className.

Now, consider this program (my-tkapp.py):

#! /usr/bin/env python
import tkinter as tk
root = tk.Tk(className='myTkApp')
label = tk.Label(root, text="Hello World")
label.pack()
root.mainloop()


If I run this program twice:

$ my-tkapp.py &
$ my-tkapp.py &

and then run xprop to check the WM_CLASS property of both windows, the first window gives:

WM_CLASS(STRING) = "myTkApp", "Mytkapp"

whereas the second gives:

WM_CLASS(STRING) = "myTkApp #2", "Mytkapp"

Note that tkinter has added a #2 suffix to the app name property. This is not desired. It makes the window manager group the two windows under separate icons in the desktop launch bar.

How can I keep the same appName property of the WM_CLASS string for different instances of my application?

Note: This question was first asked at stackoverflow.com:

https://stackoverflow.com/q/44795622/2173773

I tried to follow the source from the call:

root = tkinter.Tk(className='myTkApp')

but at 5 levels down on the stack I ended up inside TCL code, and I was not able to determine who was responsible for adding the "#2" suffix.

However, a similar perl script gives the same behavior, so I suspect the problem is within the TCL TK code. Is there a way to change the
WM_CLASS property of the window after the call to tkinter.Tk, but before entering mainloop() in order to work around the issue?
After entering the mainloop(), I guess it is too late to do anything, since then the icon is already displayed in the window manager's launch bar.

I am using Ubuntu 17.04 and Python version 3.6.1.

Best regards,
Håkon Hægland
msg297445 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-30 21:59
> tkinter has added a #2
I think you yourself proved otherwise. Additional evidence is that ' #2' is not added on Windows.  I have 3 windows titled 'myApp' stacked behind my installed python/IDLE icon. root.winfo_class() returns the class name capitalized, but the window title is not.  root.winfo_class('newname') does not work.  Note: I added more chars to the label to make it big enough to force the window to be big enough to display the title.

There might be a reason why tcl deduplicates class names on *nix.  So even if you found a way to set a classname after the Tk call, tcl might still deduplicate it.  Or we might decide not to force change the current behavior.

I suspect that this will be closed as a 3rd-party issue.
msg297473 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-07-01 05:29
I concur with Terry. This is not a Tkinter issue, this is a Tk issue.

Ask help on Tcl/Tk resources. If this is considered a bug open a ticket on the Tk tracker: https://core.tcl.tk/tk/tktnew .
History
Date User Action Args
2022-04-11 14:58:48adminsetgithub: 74974
2017-07-01 05:29:36serhiy.storchakasetstatus: open -> closed
resolution: third party
messages: + msg297473

stage: resolved
2017-06-30 21:59:40terry.reedysetnosy: + terry.reedy, serhiy.storchaka
messages: + msg297445
2017-06-28 15:18:18hakonhaglandcreate