Tkinter Output Blurry for icon and Text Python 2.7 - python-2.7

I have trawled the net and can't seem to find a satisfactory answer. Whenever I run a program that has a Tkinter GUI it always seems blurry/fuzzy (which I assume is a low resolution). It seems much lower resolution than the Windows 10 OS that is running on a couple of computers that I run these programs on.
It doesn't matter what program I run I still get the same results for all types of Tkinter entities such as buttons, labels, file dialogues etc. Which is why I have not included a sample of code.
I have copied some examples below:
Tkinter FD
Tkinter Label
Is this something I should just expect or is there some of setting on the OS\Python\Tkinter that I need to alter.
Any help would be very much appreciated.

It seems to be an OS tweak. I don't know the details (would be glad for an explanataion), but it does the job on Windows 10:
ctypes.windll.shcore.SetProcessDpiAwareness(1)
Call it before you initiate your GUI, i.e.:
import ctypes
.
.
.
if __name__ == "__main__":
if 'win' in sys.platform:
ctypes.windll.shcore.SetProcessDpiAwareness(1)
[call your Tkinter stuff]
Got it from here:
Attempting to resolve blurred tkinter text + scaling on Windows 10 high DPI displays, but concerned my approach is not Pythonic or is unsafe

I too had the same problem. I fixed it by disabling display scaling on high DPI settings on python.exe and pythonw.exe.
I followed the instructions on this page: http://www.thewindowsclub.com/fonts-appear-blurred-windows-8
1) Open your Python installation directory, this should be C:\Python27\
2) Find a executable file called python.exe
3) Right click it, and select properties
4) Go to the compatibility tab, and check Disable display scaling on high DPI settings
5) Repeat for pythonw.exe
This should fix your issues with blurry fonts

I was able so solve it! I had a look on this question: on Stackoverflow The answer from #Jay solved my problem completely. So it was not really a tkinter/python thing, but rather windows itself.

Related

Inkscape 0.92.2 quits trying to open old file with 90dpi scaling

My copy of Inkscape 0.92.2 has been working fine on my Mac OS Mojave system since installation last year. Now, today, for the first time, it pops up a dialog when I open pre-existing files
When I click "OK" the dialog window closes, and so does the image window. (Inkscape does not quit.) I have tried all combinations of choices in the dialog window, with the same result every time.
The Mac Console utility shows a message from Inkscape:
27366555: RECEIVED OUT-OF-SEQUENCE NOTIFICATION: 0 vs 2743, 513 <private>
There are similar messages from the contextstored process, whatever that is.
This does not occur with every old .svg file on my disk. It has been weeks since I used Inkscape at all, and months since I worked with the protesting files.
Does anyone have experience with this? Does Inkscape update itself automatically? Inkscape's date-last-modified on my system is today, but I did not [consciously] update it. And even so, the current downloadable version is 0.92.4 but mine is 0.92.2. I don't want to upgrade unless I have to, as my current Inkscape continues to work for some other mission-critical needs. Thanks.
I discovered that the problem affects images that were originally imported from a .ai file.
As a workaround I downloaded Inkscape 1.0 Beta 2 (for Mac OS) and opened the .ai file with that, then saved as .svg. The.svg saved by 1.0B2 opens without issue in Inkscape 0.92 on Mac OS.
So, the disease remains undiagnosed, but the symptoms can be treated and eradicated. :-)

Multiple Tkinter windows pop up at runtime after failed attempts

First of all, I'm quite new at Python, Stackoverflow and programming in general so please forgive any formal errors I might have made as I'm still trying to grasp many of the required conceptual programming protocols.
Here's the issue:
I'm trying to work around a specific, seemingly simple problem I've been having when using Tkinter: Whenever I'm fiddling with some code that confuses me, it generally takes many attempts until I finally find a working solution. So I write some code, run it, get an error, make some changes, run it again, get another error, change it again... and so on until a working result is achieved.
When the code finally works, I unfortunately also get additional Tkinter main windows popping up for every failed run I've executed. So if I've made, say, 20 changes before I eventually achieve working code, 20 additional Tkinter windows pop up. Annoying...
Now, I was thinking that maybe handling the exceptions with try/except might avoid this, but I'm unsure how to accomplish this properly.
I've been looking for a solution but can't seem to find a post that addresses this issue. I'm actually not really sure how to formulate the problem correctly... Anybody has some advice concerning this?
The following shows a simple but failed attempt of how I'm trying to circumvent this. The code works as is, but if you make a little typo in the code, run it a couple of times, then undo the typo and run the code again, you'll get multiple Tkinter windows which is what I'm trying to avoid.
Any help is, of course, appreciated...
(btw, I'm using Python 2.7.13.)
import Tkinter as tk
class App(tk.Frame):
def __init__(self, parent):
tk.Frame.__init__(self)
self.root = parent
self.canvas = tk.Canvas(self)
self.canvas.pack(expand=1,fill='both')
self.bindings()
def click(self,e):
print 'clicked'
def bindings(self):
self.root.bind('<1>',self.click)
def main():
root = tk.Tk()
app = App(root)
app.pack()
root.mainloop()
if __name__ == '__main__':
try:
main()
except:
print 'Run failed...'
Alright, great. The issue has indeed nothing to do with Tkinter or Python but with the IDE itself. Thank you Ethan for pointing that out.
PyScripter has several modes or engines. I've been running scripts with its internal engine which is faster but does not reinitialize with every run. I believe this causes the problem. The remote engine, on the other hand, does reinitialize with every run. This avoids the failed run popups.
A more in-depth explanation from the PyScripter manual below:
Python Engines:
Internal
It is faster than the other options however if there are problems with
the scripts you are running or debugging they could affect the
reliability of PyScripter and could cause crashes. Another limitation
of this engine is that it cannot run or debug GUI scripts nor it can
be reinitialized.
Remote
This the default engine of PyScripter and is the recommended engine
for most Python development tasks. It runs in a child process and
communicates with PyScripter using rpyc. It can be used to run and
debug any kind of script. However if you run or debug GUI scripts you
may have to reinitialize the engine after each run.
Remote Tk
This remote Python engine is specifically created to run and debug
Tkinter applications including pylab using the Tkagg backend. It also
supports running pylab in interactive mode. The engine activates a
Tkinter mainloop and replaces the mainloop with a dummy function so
that the Tkinter scripts you are running or debugging do not block the
engine. You may even develop and test Tkinter widgets using the
interactive console.
Remote Wx
This remote Python engine is specifically created to run and debug
wxPython applications including pylab using the WX and WXAgg backends.
It also supports running pylab in interactive mode. The engine
activates a wx MainLoop and replaces the MainLoop with a dummy
function so that the wxPython scripts you are running or debugging do
not block the engine. You may even develop and test wxPython Frames
and Apps using the interactive console. Please note that this engine
prevents the redirection of wxPython output since that would prevent
the communication with Pyscripter.
When using the Tk and Wx remote engines you can of course run or debug
any other non-GUI Python script. However bear in mind that these
engines may be slightly slower than the standard remote engine since
they also contain a GUI main loop. Also note that these two engines
override the sys.exit function with a dummy procedure.

Best solution for sys.stdout causing 'pythonw.exe' to crash

This (what i consiter a bug) plagued me for quite some time. After ALOT of searches on the topic i've found a decent solution, but i am not happy with it.
The bug is as follows;
#starts main.pyw
Import foo2.py
# foo2 contains print()
# After a few seconds(sometimes minutes) "'pythonw.exe' has stopped working."
After some research, i found out that this is due to python2 trying to force sys.stdout even know the context has no place to go. This was fixed in python3.
The program (main.pyw) is a Tkinter launcher for my game that captures the console output from foo.py. foo2.py is used by foo.py. main's console is never used, so the obvious choice was to hide it(and personally i have a small laptop, so the console was a space-hog/eye-sore)
Here is my make-shift solution:
# change 'main.pyw' to 'main.py
import ctypes
def HideConsole():
kernel32 = ctypes.Win.DLL('kernel32')
user32 = ctypes.Win.DLL('user32')
SW_HIDE = 0
hwnd = kernel32.GetConsoleWindow()
if hwnd:
user32.ShowWindow(hwnd, SW_HIDE)
HideConsole()
This works fine. Python.exe starts, the console opens, the console closes, then Tkinter starts, and the crashes are stopped. But i am getting the feeling that this isn't the right solution, what are your thoughts? Is there a better way to hide the console without using pythonw?
Edit: I have tried redirecting sys.stdout, and also the Print()'s are important to another script, so i'd rather not touch them.

"%matplotlib inline" in iPython Notebook doesnt change back to separate window when removed and re-run

I'm hoping someone can help me out.
I often find myself wanting to print figures in separate windows in iPython Notebook and within my browser when writing code and analysing figures, but keep running into a problem.
I noticed that if I add "%matplotlib inline" to my code somewhere to print the plots in the browser, but then remove it, the code continues to print the plot in the browser and not open in a new window. The only way around this I find is to just close the notebook and reopen it entirely from the command line.
Does anyone know of a simple "%" argument to place in the code that will reset it so that it prints plots to separate windows?
Just removing %matplotlib inline will not remove the effect the command had - which is in effect until the kernel is restarted (through notebook's menu) or until another gui is explicitly called (like %matplotlib qt or another one depending on your environment). See more in the docs.

Tkinter exe file - DOS screen flashes but GUI does not persist

I have created a GUI on Python 2.7.11 that consists of a main page along with page 1 and page 2 that are linked through buttons on main page. Converted main page to a python exe file using PyInstaller and there were no errors in the conversion. main page.exe appeared in the dist folder but on clicking it, a DOS screen flashed and the main page did not open nor persist on the screen.
Being a beginner, I am not sure about how to proceed further. Please help.
If you've got a line like root.mainloop() at the end (with root standing for your main Tk window) to make sure the event loop runs, then you'll need to debug your code. Try running a small segment of the code at a time to see if all goes well, and see where it is that all doesn't go well; then examine the offending part closely to find the error, maybe running some lines of code in the interpreter from the command line to see what (if any) error messages you get.
On the other hand, if you don't have a line like root.mainloop() at the end, that could produce the error you saw. Being a Python beginner myself, and having learned to program in Tcl where the Tk event loop runs automatically, I've seen that error a few times myself. :o(
There were multiple issues associated with converting the Python Script that links modules through button clicks. Keeping in mind these factors, it would be best to convert it to exe using Cx_Freeze. It is more user-friendly and was highly effective for the GUI when compared to PyInstaller and Py2Exe.