How Does CTKDeb handle StartupWMClass?

[pdschneider]

In my desktop file, I am unable to figure out how to change the StartupWMClass value from "Tk". WM_INFO always returns "Tk" so every one of my apps has to be treated as being in the same app group internally, causing issues. I had a conversation about this with the CustomTkinter dev and he wasn't sure how to resolve it and pointed me here.

That conversation: TomSchimansky/CustomTkinter#2859 (comment)

Does anybody in this community know how to handle this case?

Thanks!

[ibamzjr]

CTkDeb does not need a special option for this; it can emit the standard desktop-entry key. The important part is to make the Tk window class and the desktop entry agree.

Create the root window with an explicit className:

import customtkinter as ctk

app = ctk.CTk(className="MyApp")

CustomTkinter's current CTk constructor forwards Tk arguments such as className (source). Then add the matching key to the CTkDeb configuration:

{
  "desktopEntry": {
    "Name": "My App",
    "StartupWMClass": "MyApp"
  }
}

CTkDeb merges the values in desktopEntry into the generated .desktop file, so the package should contain:

StartupWMClass=MyApp

After rebuilding and reinstalling the package, verify the real value rather than relying on the window title:

xprop WM_CLASS

Click the application window. The class (normally the second string) must match MyApp, including case. If it does not, use the value reported by xprop as StartupWMClass. Changing app.title(...) alone will not change WM_CLASS.

[pdschneider]

Thank you so much! I have my own build flow separate from CTkDeb (although if I had learned about this at the right point I definitely would have used it), but just knowing that I can set className is huge.

[JehadurRE]

This is a known limitation of Tkinter/CustomTkinter on Linux — the WM_CLASS is hardcoded to Tk by the Tk toolkit itself, and there is no supported Python-side API to change it before the window is mapped.

What works in practice:

Option A: Override WM_CLASS after window creation (X11 only)

import ctypes
# after root/main window is created
root.update_idletasks()
x11 = ctypes.cdll.LoadLibrary(libX11.so.6)
x11.XStoreName(root.winfo_id(), bYourAppName)
# For WM_CLASS you need XSetClassHint — requires a small C helper or python-xlib:

With python-xlib:

from Xlib import display, X
d = display.Display()
w = d.create_resource_object(window, root.winfo_id())
w.set_wm_class(yourapp, YourApp)
d.sync()

Call this after the window is realized but before mapping. It is fragile and X11-only (no Wayland).

Option B: Use a custom .desktop file with StartupWMClass
Set StartupWMClass=Tk in your .desktop file so the desktop environment groups all your Tk apps correctly — but as you noted, this lumps all Tk apps together.

Option C (recommended): Switch toolkit for the WM_CLASS problem
If per-app WM_CLASS matters for your workflow (window rules, tiling, icon grouping), CustomTkinter cannot solve it. Consider PySide6/PyQt6 where you can set QApplication.setDesktopFileName() and the WM_CLASS follows the application name natively.

Option D: Wrapper script that renames WM_CLASS post-launch
Use xdotool or a tiny C wrapper that forks, execs your Python app, then calls XSetClassHint on the child window once it appears. This is what several PyInstaller-packaged Tk apps use in production.