Develop Reference

Very slow window refresh (update) via tkinter in macOS [python, PySimpleGUI, Tkinter, macOS]

Our app (Python-based, cythonised and packaged for usage on computers without installed Python) has its GUI based on PySimpleGUI / Tkinter port.
In macOS, we sometimes experience an extremely slow start. On my Mac, from app launch until the main window is completely rendered and ready to use it only takes about 2-3 seconds. But on some of my colleagues' Macs, it sometimes takes 45s or even several minutes. We had this problems with an earlier version of the app but solved it in May by adding a splash window as discussed in PySimpleGUI / Tk: very slow startup on Mac. The new version (= with the splash window) always started quickly (2-3s) on all available computers at various places for several weeks but then (while we haven't changed anything in the app), the slow-start problem appeared again - only on some Macs and even depending on the location: on my colleague's computer, the app always starts in max. 3s at work, but 45s+ when she's at home.
There are Mac, Windows and Linux versions of our app. Only the Mac version has this problem (so far never observed under Win, Linux and also never in Win/Linux emulators on Mac), only on some computers in combination with some locations. At work, it's quick for all the computers our team uses but slow on computers of some of our guests; for my colleague, slow at (her) home; at (my) home, quick on my computer but slow on another one. This is what completely puzzles me!
I've added a lot of logging to the code to be able to see which parts of code take a lot of time. There's only one network interaction (license verification) and it doesn't seem to be slow: the whole function (setting up connection, retrieving the data, processing the data, closing the connection) does not take more than 2s even with those 45s+ starts. All the delays we can see are related to main-window refresh:
logging.info('.created background window', session_log=True)
main_window.refresh()
logging.info('.refreshed main window', session_log=True)
Just this refresh() takes anything between 3-10s or even more on those slow starts. It is a function of PySimpleGUI defined like this:
def refresh(self):
if self.TKrootDestroyed:
return self
try:
rc = self.TKroot.update()
except:
pass
return self
The same functions are used many times after the main window has been rendered completely, but then they are never slow again; it's always just in the start phase of the application.
So, it seems to be Tkinter's update() that takes so long. But why only on some Macs, and (on the same Macs) why only at some places?
Have you ever experienced such a behaviour in your GUI? Do you have any ideas how to deal with it?
I'd be very grateful for any hints.

I recommend replacing calls to .update() with .updateidletasks(). update not only causes the window to refresh, but it has to process all pending events of all types, and won't return until all events are processed. If, while processing an event this code is called again, you end up with event loops nested inside of event loops.
updateidletasks only process the events in the idle queue, which is mostly screen updates and jobs queue with after_idle, greatly reducing the chance you will end up with nested event loops.

Getting screenshot via printwindow not redrawing if laptop screen off

My goal is to take screenshots off an application while the laptop screen is off, but instead the screenshot will always be the same as just before turning off the screen. It does not redraw itself once the screen is off, and remains frozen.
I'm obtaining a screenshot using printwindow from Python (using method described here: Python Screenshot of inactive window PrintWindow + win32gui
This method works nicely as long as I have my laptop screen on, but if I turn it off, it simply returns the last image before the screen turned off. I've tried using win32gui.RedrawWindow, hoping that this would force a redraw, but I haven't gotten it to work, even trying all the different flags. I've also tried getting screenshots via pyautogui, but this also has the same problem. Is there any way to redraw the application while the laptop screen is off?

It would be nice if there were a straightforward way to do what you want to do, but unfortunately it's just not possible without some convoluted low-level work.
In the underlying WinAPI, native windows redraw themselves only when they receive WM_PAINT messages, and they only receive WM_PAINT messages if they are visible. They don't get the messages if they're behind another window, or if they're dragged off screen, or minimized, or their visibility is set to False. They also aren't visible when the screen is off. Since they aren't visible, they simply never get told to redraw themselves. That's why the screen capture image doesn't change after the screen is turned off.
There is no command you can issue that will override this -- it is implemented as a fundamental part of the windowing paradigm.
One solution is to have the application paint itself in something that's not a window (e.g., a dialog box) and capture that rather than capturing the screen. You could also modify the application by overriding OnPaint and using a timer to invalidate and call your OnPaint function periodically (since WM_PAINT messages won't be received).
If it were me I'd override OnPaint, make my application draw itself to a background context bitmap rather than the normal window, then use a timer to invalidate and redraw periodically and just take the bitmap of the background context whenever I wanted to capture the output.
If you don't own the code for the applications that are running, you may still be able to get applications to redraw themselves by running everything in a virtual machine. I've done that successfully for headless computing in the past, but it was many OS versions ago and things may be different now, so YMMV...
Information on manual screenshots under VMWare is here.
Information on programmatic screenshots under Hyper-V is here.

TkInter; Non-responsive when being told to update

I have a GUI program built using Tkinter in python 2.7.10.
It works flawlessly, for it's root cause anyways.
Unfortunately, it briefly goes into windows dreaded "Not Responding" state when being interacted with.
Here's the layout in short:
Launch script launches Main script.
Main script reads settings file and boots GUI script.
GUI script starts GUI.
User enters a term to search for in a series of files.
GUI script goes into a side script to process files and retrieve results.
Side script inherits certain aspects of GUI script.
Side script attempts to update user while working using the inherited elements; the GUI has none of it.
GUI goes non-responsive briefly before returning to the GUI script and displaying the results.
Here's how I need it to go in short:
Launch script launches Main script.
Main script reads settings file and boots GUI script.
GUI script starts GUI.
User enters a term to search for in a series of files.
GUI script goes into a side script to process files and retrieve results.
Side script inherits certain aspects of GUI script.
Side script updates the user with a progress bar and imagery while working, using the GUI elements.
GUI returns to the GUI script and displays the results.
I have the progress bar built, but the imagery is not yet, but if the progress bar will not work, I will not waste my time on the imagery.
Sample impossible, not-being-used-but-shows-the-point code;
GUI;
import Tkinter, PIL, SideScript1
Tkinter()
ShowText()
ShowStuff()
input = GetInput()
ShowProgressBar()
SideScript1.processfilesbasedoninput(input, progressbarcontrolvar)
DisplayResults()
SideScript1
def proccessfilesbasedoninput(input, pbcv):
DoStuff()
pbcv.gofurther(5)
DoMoreStuff()
pbcv.goevenfurther(10)
a1sauce = RandomMathsStuffs()
for all the data in every file in that one directory:
ReadData()
pbcv.goabitfurther(a1sauce)
if data is what I want:
break
pbcv.step(-100)
return data
I guess my question is, How would I get the GUI to update those elements instead of going unconscious?
We are talking 100 000 files and 1.5 seconds its done in.
UPDATE: This question has been marked as a duplicate of another. Is it? Yep. but that's both because I was ((and still am)) unsure of how to search for this kind of question, and that the three solutions there; multithreading, multiprocessing, and smaller tasks. Unfortunately, the program was built to run on a single thread and process, and without a complete rewrite, getting the intended GUI response would cause a massive slowdown, if it worked at all.
I do see the issue, being TKinter is a blocking module. Unfortunately, I am fresh out of ideas on how I would un-block it without causing mass errors, and or a total rewrite.

The linked duplicate question held an answer. A bad one - but an answer none the less.
update_idletasks.
I tried that, and, it Worked! Well. Sort of.
It worked at first, then the same result came about. The GUI temporarily froze.
Then an idea popped in my head. Why not try update instead?
I did so, and it worked as I needed it to, however, it had a massive performance hit - nearly identical to update_idletasks.
To tackle this new problem, I added a bit more math to cause updates to happen, in my case, every 300 files, instead of every single file-balancing the performance hit and users not instantly deleting my program, because yes, it takes a toll on your resources. No, I did not initially heed that advice. Shoot first, ask questions later, right?
How did I use it? Glad I asked! Here's an example;
#GUI Code
DoStuff()
SideScript1.proccessdata(arg, kwarg, debate)
DoMoreStuff()
#File Management Code
DoStuff()
filenumber = 0
maxfilenumber = 0
for every file I need to search:
SearchFile()
filenumber +=1
if filenumber == maxfilenumber:
tkinter.update() #in my case, it was tkinst, or "TkInter Instance", since it was inherited from the GUI attributes.
filenumber = 0
if data is what I want:
break
return data
I'm not sure about all the backend and hard facts, but update() seemed a lot more user friendly and quicker than update_idletasks(), and a lot less prone to errors and slowdowns as well.
My shenanigans are now back in order, running in 60 ((30? 120? 250 million??)) frames a seconds, smoothly and efficiently - and Tk doesn't have a sit-down strike every time I ask it for info anymore!
Thanks #Rawing for the attempt to help!

Bring terminal to the front in Python

Is there a way to bring the Linux terminal to the front of your screen from a python script? Possibly using some kind of os. command
I.e - Your python script opens up a GUI that fills the screen, but if a certain event happens that you want to see printed in the terminal to be viewed, but don't want to / can't show this information on the GUI (so please don't suggest that)
And if possible, hide it back behind your other windows again, if needed.
(Python 2, by the way)
Any suggestions greatly appreciated.

Not in any generally supported way.
Some terminal applications may support the following control sequences. However, these sequences are not standardized, and most terminals do not implement them.
\e[5t - move window to front
\e[6t - move window to back
\e[2t - minimize ("iconify") window
\e[1t - un-minimize window
— from http://rtfm.etla.org/xterm/ctlseq.html

That "bring the Linux terminal to the front of your screen" is likely talking about terminal emulators running in an X Window environment. Ultimately this is accomplished by making a request to the window manager. There is more than one way to do this.
xterm (and some other terminal emulators) implement the Sun control sequences for window manipulation (from the 1980s) which were reimplemented in dtterm during the early 1990s. xterm has done this since 1996 (patch #18).
Python: Xlib — How can I raise(bring to top) windows? mentions wmctl, a command-line tool which allows you to make various requests to the window manager.
xdotool is another command-line tool which performs similar requests.
finally, Can a WM raise or lower windows? points out that you can write your own application (and because python can use shared libraries written in C, you could write a script using the X library).

Graphics Window Crashing in IDLE

A real newbie question here.
I'm using IDLE 2.7.2 on OSX 10.7.2 and reading Zelle's Python:Programming. I haven't programmed since the 80's, so after going through the command line stuff, I'm excited to dive into Objects. I grab his graphics.py file and copy it into documents (this seems like the default location for IDLE) and start up IDLE.
He then suggests a few commands into the shell:
from graphics import *
win = GraphWin() #which opens a graphics window with no problem
He then goes on to have you draw some lines and shapes in the window. Those graphics show up just fine in the window.
Here's my problem. If I try to mouse over the graphics window, I get the Mac pinwheel. Moving the window doesn't help. So the window seems like it's crashing (though IDLE is doing fine), but strangely, if I keep entering commands into IDLE, the shapes keep drawing normally in the window.
Am I doing something wrong? Is this normal? Thanks,
Henry

Idle runs the python commands you enter in another process, so it's reasonable to expect this "lock up" behavior to be different between the program controlled window and Idle.
What's probably going on, though is that everything is fine, but you have not yet started the event loop in the program you're typing in. The operating system notices that the program is not emptying out its event queue when you mouse over it (which creates lots of events) and it's helpfully informing you (by way of the pinwheel) that the program seems to be busy.
You will likely reach a point later in the tutorial where you do start the event loop, and the pinwheel will magically go away.