How to bring Tkinter window in front of other windows? - python

I'm working with some Tkinter Python code (Python 3.4), and I've come across a problem. When I create my Tkinter window it doesn't show up in front. I do it currently with the following code:
from tkinter import *
win = Tk()
win.minsize(width=1440, height=828)
win.maxsize(width=1440, height=828)
The minsize() and maxsize() make the window cover my entire screen, but the original python running window (The one that wouldprint("Hello, World!")) ends up on top. Is there a way to fix this? I'm running OS X 10.10.1.

Set it as the topmost (but it will always stay in front of the others):
win.attributes('-topmost', True) # note - before topmost
To not make it always in front of the others, insert this code before the mainloop:
win.lift()
win.attributes('-topmost', True)
win.attributes('-topmost', False)
Don't forget win.mainloop() at the end of your code (even if in some cases it's not explicitly required)
Other discussions on the same problem:
How to put a Tkinter window on top of the others
How to make a Tkinter window jump to the front?

Related

Make Tkinter Notebook draggable

A similar question was asked back in '15 Make Tkinter Notebook be Draggable to Another View but that was a while ago and that also asked about re-binding the window.
I was wondering how I would make a notebook draggable, even if is just to reorder the tabs.
Any advice would be helpful and please let me know if this question has been answered
Tab dragging has been implemented in TCL: https://wiki.tcl-lang.org/page/ttk::notebook, https://wiki.tcl-lang.org/page/Drag+and+Drop+Notebook+Tabs. It can either be translated to python or evaluated through .tk.eval().
For the second solution, one can put the TCL tab dragging code from the first link (except the last block which creates an example notebook) in a string and evaluate it with root.tk.eval(TCL_CODE). Subsequently created notebooks will have tab dragging:
import tkinter as tk
from tkinter import ttk
tcl_code = """
put here the code from the dragging tab code section of https://wiki.tcl-lang.org/page/ttk::notebook
"""
root = tk.Tk()
root.tk.eval(tcl_code)
nb = ttk.Notebook(root)
nb.pack()
for i in range(10):
nb.add(ttk.Frame(nb, width=100, height=100), text=f"Tab {i}")
root.mainloop()
I also implemented tab dragging with animations (seeing the dragged tab move) as part of a larger project, the source code is available here.

Why packing widgets into frames instead of directly packing them into the root window?

I'm learning Python by building an airplane ticket app. I'm currently working on learning TkInter for the GUI, and I want to know why I have to create a container (frame) instead of just putting everything in root = Tk() which seems to work.
Also, isn't ttk part of tkinter, therefore I shouldn't have to have the 2nd line (from tkinter import ttk)?
Here's my code:
from tkinter import *
from tkinter import ttk
root = Tk()
frame = Frame(root)
root.title("AirTix")
flight_title = Label(frame, text = "Flights").grid()
root.mainloop()
Thanks!
I want to know why I have to create a container (frame) instead of just putting everything in root = Tk() which seems to work.
You do not have to create a container. Whatever tutorial or book is telling you that you must is wrong. There's nothing wrong with creating everything in the root window.
That being said, for anything but the most trivial of apps, it helps tremendously to organize your widgets in logical groups, with each logical group being a frame (or, perhaps, a Canvas or PanedWindow). This gives you the flexibility to use the best geometry manager (pack, place, or grid) for each section.
For example, it makes sense to have a toolbar that is a frame with a bunch of buttons packed left-to-right. The same might be true for a bottom status bar. The main body might be a frame with widgets arranged in a grid.
grid can be a bit more complicated to use, and pack excels at placing widgets either in a single horizontal row (toolbar or status bar), or column (toolbar on top, status bar on bottom, main area in the middle.
Also, isn't ttk part of tkinter, therefore I shouldn't have to have the 2nd line (from tkinter import ttk)?
Even though ttk is part of tkinter, it does not get imported when you import everything from tkinter. Many python packages are this way, with sub-modules that must be explicitly imported.
Further, it's bad practice to use a wildcard import. Instead of doing this:
from tkinter import *
root = Tk()
... it's arguably better to do it like this:
import tkinter as tk
root = tk.Tk()
With the former, you end up polluting the global namespace with a bunch of things you may or may not use. With the latter, you import exactly one thing. Plus, it makes your code more self-documenting because it makes it crystal clear when you are expecting to use an object or class from the tk package.

Tkinter window not filling screen in zoomed state on secondary display

I'm building a small python 3 tkinter program on windows (10). From a main window (root) I'm creating a secondary window (wdowViewer). I want it to be full screen (zoomed) on my secondary display. The code below works on my main setup with two identical screens. If I however take my laptop out of the dock and connect it to (any) external display, the new window only fills about 2/3 of the secondary display.
Two things to note:
- The laptop and external monitor have same resolution.
- The window is appropriately zoomed when overrideredirect is set to 0.
mon_primary_width = str(app.root.winfo_screenwidth()) # width of primary screen
self.wdowViewer = Toplevel(app.root) # create new window
self.wdowViewer.geometry('10x10+' + mon_primary_width + '+0') # move it to the secondary screen
self.wdowViewer.wm_state('zoomed') # full screen
self.wdowViewer.overrideredirect(1) # remove tool bar
app.root.update_idletasks() # Apply changes
After two days of experimenting I finally found a fix.
Consider the following example: Making a toplevel zoomed, works fine on any secondary display when using the following code:
from tkinter import *
# Make tkinter window
root = Tk()
sw = str(root.winfo_screenwidth())
Label(root, text="Hello Main Display").pack()
# Make a new toplevel
w = Toplevel(root)
w.geometry("0x0+" + sw + "+0")
w.state('zoomed')
w.overrideredirect(1)
Label(w, text='Hello Secondary Display').pack()
root.mainloop()
However, in my code I'm making a new Toplevel after running the mainloop command. Then, the issue arises. A code example with the issue:
from tkinter import *
# New Tkinter
root = Tk()
sw = str(root.winfo_screenwidth())
# Function for new toplevel
def new_wdow():
w = Toplevel(root)
w.geometry("0x0+" + sw + "+0")
w.state('zoomed')
w.overrideredirect(1)
Label(w, text='Hello Secondary Display').pack()
# Make button in main window
Button(root, text="Hello", command=new_wdow).pack()
root.mainloop()
Problem: The bug is only present if the DPI scaling in Windows is not set to 100%. Hence, there seems to be a bug in how tkinter handles the DPI scaling subsequent to running mainloop. It does not scale the window properly, but Windows is treating it as if it does.
Fix: Tell Windows that the app takes care of DPI scaling all by itself, and to not resize the window. This is achievable using ctypes. Put the following code early in your python script:
import ctypes
ctypes.windll.shcore.SetProcessDpiAwareness(2)
Hopefully others will find the solution helpful. Hopefully, someone may explain more of what is going on here!

ttk OptionMenu does not fit into its bounding box

I am facing a problem creating a Tkinter-application under Windows, using python 2.7. Basically, when I create an OptionMenu, its right corner (where a down button indicates that something happens when you click there) is truncated in the middle.
The following code reproduces the issue:
from Tkinter import Tk, StringVar
from ttk import OptionMenu
root = Tk()
options = list('ABC')
var = StringVar(value='A')
om = OptionMenu(root, var, var.get(), *options)
om.config(width=25)
om.pack()
root.mainloop()
The result looks on my computer like this:
I have played around with the padx and ipadx keywords of the packing layout manager and also tried a grid layout instead. None of them lets me see the down-arrow completely.
I appreciate your helpful comments on this issue.
The same happens to me on Windows 7 but not on XP, both using Python 2.7. I have found a bug report which states is should be fixed in Tk 8.5.8. Updating Tcl/Tk in Python seems to be very complicated though
The fix in question is for one of the script files shipped in the tk library. You could modify your local copy of vistaTheme.tcl to match this. In later versions I think it does actually request the size from the system properly but this should work if you are forced to use an older version of Tk.
You can find the path using:
from Tkinter import Tk
tk = Tk()
tk.eval("set tk_library")
and then edit the /ttk/vistaTheme.tcl file. I've got python3 here and it seems to have come with Tk 8.6.1 so has this fixed already.

Determining what tkinter window is currently on top

I have written an application in python 2.7 and tkinter. I created a tool bar with several buttons that open up respective top windows that display various options. I used ttk.Checkbutton with the 'toolbutton' style as an indicator to show whether the option windows are open or closed.
The problem is that the option windows will go to the back if another window is selected. Currently, if one selects the toolbutton again, the option window will close. However, I only want to close the window if it is on top. If the option window is not on top, I want the window to moved to the front.
Some of the code I have working:
class MainWindow:
def __init__(self,application):
self.mainframe=tk.Frame(application)
application.geometry("900x600+30+30")
self.otherOptionsSelect=tk.IntVar()
self.otherOptions_Button=ttk.Checkbutton(application,style='Toolbutton',variable=self.otherOptionsSelect,
onvalue=1, offvalue=0,image=self.optionsIcon, command=self.otherOptions)
def otherOptions(self):
if self.otherOptionsSelect.get()==0:
self.otherOptions.destroy()
return
self.otherOptions=tk.Toplevel()
self.otherOptions.title("IsoSurface Options")
self.otherOptions.geometry("200x165+"+str(int(application.winfo_x())+555)+"+"+str(int(application.winfo_y())+230))
self.otherOptApply_button=ttk.Button(self.otherOptions,text="Apply",command=self.showFrame)
self.otherOptApply_button.place(x=20,y=80,width=50,height=30)
self.otherOptClose_button=ttk.Button(self.otherOptions,text="Close",command=self.otherOptionsClose)
self.otherOptClose_button.place(x=80,y=80,width=50,height=30)
def otherOptionsClose(self):
self.otherOptionsSelect.set(0)
self.otherOptions.destroy()
Here is a picture of the entire application I have written:
In the above image, each window has their respective ttk.checkbutton. At the moment, toggling the checkbutton either opens or closes the window. However, what I really want it to do is close the window if the window is in front of the application, or bring the window to the front if it is behind the application.
Hopefully this clears some things up.
Thanks in advance!
It is in fact possible to check stacking order of windows. Using Tkinter, you have to do some funny tcl evals to get at the information. I found the answer at TkDoc in the section on Windows and Dialogs, scroll down until you get to "Stacking Order". The code baffled me until I started playing around with it interactively. My test code was:
import Tkinter as tk
root = tk.Tk()
root.title('root')
one = tk.Toplevel(root)
one.title('one')
two = tk.Toplevel(root)
two.title('two')
I then manipulated the windows so that two was on top, one under that and root below them all. In that configuration, the following weirdness can tell you relative layering of windows:
root.tk.eval('wm stackorder '+str(two)+' isabove '+str(root))
returns 1, meaning "Yes, window two is above window root." While the following:
root.tk.eval('wm stackorder '+str(root)+' isabove '+str(two))
returns 0, meaning "No, window root is not above window two." You can also use the command:
root.tk.eval('wm stackorder '+str(root))
Which gives back the full window stacking order in the form of a weird string something like this:
'. .68400520L .68401032L'
Which starts to make sense when you run the commands:
str(root)
str(one)
str(two)
and figure out that root has the internal name '.', one is '.68400520L' and two is '.68401032L'. You read the output of root.tk.eval('wm stackorder '+str(root)) backwards so it's saying two is on top, one is under that and root is below both.

Categories