New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tkinter Tk args and Gnome Shell application name #57762
Comments
I want the app name to be displayed under the icon in Alt+Tab menu, but currently it only displays the className of the root, which by default is "Tk". So in Gnome3 all Tkinter apps show up as "Tk" in the panel and in the Alt+Tab menu. It is possible to override that to some extent by giving className attribute to Tk(), but I don't know what the side effects are and it doesn't preserve capitalization of the name - the first letter is capital, but all others are small. Moreover, default title of the window is taken from the className by making first letter small and leaving the rest as given, so at the end nothing is as intended. E.g., if I give calssName="APP", the app is called "App", but windows title is "aPP". There should be a way to give this information, but I don't see it exposed anywhere and it is not correctly inferred from args[0] either. Example program attached. |
The link below suggests that the problem with method 'iconname' http://www.pythonware.com/library/tkinter/introduction/x9905-icon-methods.htm summary: iconname iconname(newName=None), iconname(). Set (get) the icon name to use when this window is iconified. This method are ignored by some window managers (including Windows). |
Yes, I'm aware of the 'iconname' docs. In this case 'iconname' probably is not the right property to set, but I don't know which one should be. For GTK+ applications there is a special function for setting application name which should be shown to user and apparently Gnome 3 is using that. I don't know how to achieve the same for Tkinter. |
Does IDLE appear as "Tk" in Gnome3? |
No, it apears as "Toplevel". I'm not sure if the program.desktop file has something to do with that, but I didn't manage to get the application name from a desktop file to get used for Tkinter program. And I don't have any Tkinter or Tk app which would do what I'm trying to do. For example, Firefox shows up as "Mozilla Firefox", but I don't see any X property with that value for Firefox window.. it might be something Mutter is doing. Here is xprop for IDLE and Firefox: $ sleep 5; xprop
XKLAVIER_STATE(INTEGER) = 0, 0
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 24, 0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x1600094
bitmap id # of mask for icon: 0x1600095
window id # of group leader: 0x1600001
_NET_STARTUP_ID(UTF8_STRING) = "gnome-shell-17731-RD-OC-firefox-10_TIME71936264"
WM_WINDOW_ROLE(STRING) = "browser"
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
_NET_WM_ICON(CARDINAL) = Icon (16 x 16):
░ ░▒▒▒▒░
▒▒░▒▒▒ ░▒▒▒
░▒░▒▒░▒ ░░▒░▒
░░░░░░▒▒▓░░▒░░▒
▒░░░░░▒▒▓░░▒░ ░░
▒░░░░░░▒░░░▒▒ ░░
▒░░░░░░▒░▒▒▒▒ ░▒
▒░░▒▒▒▒▓▒▒▒▒▒ ░▒
▒░░░▒▒▓▒▒▒▒▒▒ ░▒
░▒░░▒▒▒▒▒▒▓▓░░░░
▒▒░░▒▒▒▒▓▒░░░▒░
▒▒░░░░▒▒▒▒░░▒▒
▒▒░░░░░░░░░▒
▒▒▒▒▒▒▒▒▒▒░
▒▒▒▒▒▒▒▒░
░░▒▒░░
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 23068819 |
It looks like this code will set the title properly in the latest GNOME shell (3.4): from Tkinter import *
app = Tk(className='App Name')
app.title('App Title')
app.mainloop() The documentation should be updated to explain the arguments to Tk(). |
The resolution of this issue should be to properly document the Tk class. The 3.4 docs currently say: "class tkinter.Tk(screenName=None, baseName=None, className='Tk', useTk=1) The signature is incomplete -- see below. The first sentence is wrong; there are arguments, they just all happen to have defaults. The next sentence should be something like "Return a toplevel Tk widget, which is usually the main window of an application." Tk.__doc__ is 'Toplevel widget of Tk which represents mostly the main window\n of an application. It has an associated Tcl interpreter.' This is probably ok. Tk.__init__ signature and Tk,init.__doc__ are __init__(self, screenName=None, baseName=None, className='Tk', useTk=1, sync=0, use=None) "Return a new Toplevel widget on screen SCREENNAME. A new Tcl interpreter will "Toplevel" should be "toplevel" as in : Tk is not a subclass of Toplevel. Rather Toplevel is similar to Tk but with the BaseWidget signature. The argument list needs to be completed and perhaps a bit more said about the one documented. Does 'screen' apply to anything other than X11? Could it be used on Windows to put the window on a secondary screen? Is Gnome the only user framework that uses classname? |
Took a couple years, but #4786 almost completes this. The only thing missing I can tell from @terryjreedy's comment above is the docstring disambiguation of "Toplevel", PR for this here: #98837 |
Mentioned as a desired change by terryjreedy on the corresponding issue, since Tk is not a subclass of Toplevel.
Mentioned as a desired change by terryjreedy on the corresponding issue, since Tk is not a subclass of Toplevel.
Mentioned as a desired change by terryjreedy on the corresponding issue, since Tk is not a subclass of Toplevel. (cherry picked from commit ad23da0) Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
Mentioned as a desired change by terryjreedy on the corresponding issue, since Tk is not a subclass of Toplevel. (cherry picked from commit ad23da0) Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
th9 mannequin commentedDec 8, 2011
•
edited by bedevere-bot
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: