From klappnase at web.de  Wed Dec  4 13:25:45 2019
From: klappnase at web.de (Michael Lange)
Date: Wed, 4 Dec 2019 19:25:45 +0100
Subject: [Tkinter-discuss] tkinter.PhotoImage to PIL.Image
In-Reply-To: <0BC70B5D93E054469872FFD0FE07220E02E3729C24@CERNXCHG54.cern.ch>
References: <0BC70B5D93E054469872FFD0FE07220E02E3729C24@CERNXCHG54.cern.ch>
Message-ID: <20191204192545.df012e4186cf3250c5733a05@web.de>

Hi,

sorry for the late replay.

On Sat, 30 Nov 2019 13:52:11 +0000
Vasilis Vlachoudis <Vasilis.Vlachoudis at cern.ch> wrote:

> Hi all,
>
> I have several images loaded as tkinter.PhotoImage, I want some to
> resize them The PhotoImage zoom accepts only integer values and the
> result is not that great. While if load them with PIL resize them and
> then convert to PIL.ImageTk it is much better. I found several
> references on how to convert from PIL to tkinter but I cannot find how
> to do the opposite so I can use the PIL resizing with the existing
> tkinter images.

Do you mean something like:

from PIL import Image, ImageTk
im = Image.open("image.png")
resized = im.resize((height, width), IMAGE.ANTIALIAS)
photo = ImageTk.PhotoImage(image=resized)

does not do the trick, you want to pass the tkinter.PhotoImage object to
PIL.Image.open() ? I don't think this is possible, at least without some
sort of trickery. What is it exactly that you want to achieve?

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

	"What happened to the crewman?"
	"The M-5 computer needed a new power source, the crewman merely
got in the way."
		-- Kirk and Dr. Richard Daystrom, "The Ultimate Computer",
		   stardate 4731.3.

From klappnase at web.de  Wed Dec  4 13:28:39 2019
From: klappnase at web.de (Michael Lange)
Date: Wed, 4 Dec 2019 19:28:39 +0100
Subject: [Tkinter-discuss] tkinter.PhotoImage to PIL.Image
In-Reply-To: <20191204192545.df012e4186cf3250c5733a05@web.de>
References: <0BC70B5D93E054469872FFD0FE07220E02E3729C24@CERNXCHG54.cern.ch>
 <20191204192545.df012e4186cf3250c5733a05@web.de>
Message-ID: <20191204192839.a8606f2d83fb25bbdfb35ab8@web.de>

On Wed, 4 Dec 2019 19:25:45 +0100
Michael Lange <klappnase at web.de> wrote:

> resized = im.resize((height, width), IMAGE.ANTIALIAS)
                       ^^^^^^^^^^^^^

oops, should be

resized = im.resize((width, height), IMAGE.ANTIALIAS)



.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

The sight of death frightens them [Earthers].
		-- Kras the Klingon, "Friday's Child", stardate 3497.2

From Vasilis.Vlachoudis at cern.ch  Fri Dec  6 03:36:18 2019
From: Vasilis.Vlachoudis at cern.ch (Vasilis Vlachoudis)
Date: Fri, 6 Dec 2019 08:36:18 +0000
Subject: [Tkinter-discuss] tkinter.PhotoImage to PIL.Image
In-Reply-To: <20191204192839.a8606f2d83fb25bbdfb35ab8@web.de>
References: <0BC70B5D93E054469872FFD0FE07220E02E3729C24@CERNXCHG54.cern.ch>
 <20191204192545.df012e4186cf3250c5733a05@web.de>,
 <20191204192839.a8606f2d83fb25bbdfb35ab8@web.de>
Message-ID: <0BC70B5D93E054469872FFD0FE07220E02E6431AE3@CERNXCHG53.cern.ch>

Thanks Michael,

at present my program is based that all the images are loaded as tkinter.PhotoImage.
I am trying always to keep the python dependencies as low as possible. 
PIL is not required apart when the user wants some specific functionality (add-ons)

So for the case that someone wanted to resize them (PIL would be required)
and I was thinking  to resize them by temporarily converting them to PIL.Image
and then back to tkinter.PhotoImage.
Maybe my way is not the cleanest, but rather to do as you propose, load them as PIL.Images
process and convert them to tkinter.PhotoImage.

Vasilis


________________________________________
From: Tkinter-discuss [tkinter-discuss-bounces+vasilis.vlachoudis=cern.ch at python.org] on behalf of Michael Lange [klappnase at web.de]
Sent: Wednesday, December 04, 2019 19:28
To: tkinter-discuss at python.org
Subject: Re: [Tkinter-discuss] tkinter.PhotoImage to PIL.Image

On Wed, 4 Dec 2019 19:25:45 +0100
Michael Lange <klappnase at web.de> wrote:

> resized = im.resize((height, width), IMAGE.ANTIALIAS)
                       ^^^^^^^^^^^^^

oops, should be

resized = im.resize((width, height), IMAGE.ANTIALIAS)



.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

The sight of death frightens them [Earthers].
                -- Kras the Klingon, "Friday's Child", stardate 3497.2
_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss at python.org
https://mail.python.org/mailman/listinfo/tkinter-discuss

From klappnase at web.de  Fri Dec  6 03:58:13 2019
From: klappnase at web.de (Michael Lange)
Date: Fri, 6 Dec 2019 09:58:13 +0100
Subject: [Tkinter-discuss] tkinter.PhotoImage to PIL.Image
In-Reply-To: <0BC70B5D93E054469872FFD0FE07220E02E6431AE3@CERNXCHG53.cern.ch>
References: <0BC70B5D93E054469872FFD0FE07220E02E3729C24@CERNXCHG54.cern.ch>
 <20191204192545.df012e4186cf3250c5733a05@web.de>
 <20191204192839.a8606f2d83fb25bbdfb35ab8@web.de>
 <0BC70B5D93E054469872FFD0FE07220E02E6431AE3@CERNXCHG53.cern.ch>
Message-ID: <20191206095813.04f98f6a269da43681d088bd@web.de>

Hi,

On Fri, 6 Dec 2019 08:36:18 +0000
Vasilis Vlachoudis <Vasilis.Vlachoudis at cern.ch> wrote:

> Thanks Michael,
>
> at present my program is based that all the images are loaded as
> tkinter.PhotoImage. I am trying always to keep the python dependencies
> as low as possible. PIL is not required apart when the user wants some
> specific functionality (add-ons)
>
> So for the case that someone wanted to resize them (PIL would be
> required) and I was thinking  to resize them by temporarily converting
> them to PIL.Image and then back to tkinter.PhotoImage.
> Maybe my way is not the cleanest, but rather to do as you propose, load
> them as PIL.Images process and convert them to tkinter.PhotoImage.

maybe you could create a custom Image class that checks at program start
for the presence of PIL and if PIL is present uses scalable PIL
PhotoImages and if not plain tkinter ones, or let it depend on the user
configuration which ones to use.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

All your people must learn before you can reach for the stars.
		-- Kirk, "The Gamesters of Triskelion", stardate 3259.2

From aivar.annamaa at gmail.com  Tue Dec 10 05:49:27 2019
From: aivar.annamaa at gmail.com (Aivar Annamaa)
Date: Tue, 10 Dec 2019 12:49:27 +0200
Subject: [Tkinter-discuss] How to handle any Windows message (eg.
 WM_GETOBJECT)?
Message-ID: <34ace98d-cc07-2f7a-9fe6-0ee2730fdcc4@gmail.com>

Hi!

It looks like accessibility support in Tk won't happen 
(https://core.tcl-lang.org/tk/tktview/deb6cddecf55c6921281f8f855b6b366aed6467e). 
I'm wondering is it somehow possible to bolt on some accessibility 
support at least on Windows.

It looks like the starting point is that the app should be able to 
provide customized responses to WM_GETOBJECT messages. I didn't find 
such name in Tk source code. Does it mean Tk event loop simply drops 
these? Is it somehow possible to install an extra WM event handler to 
catch these?

Best regards,
Aivar


From klappnase at web.de  Tue Dec 10 06:11:50 2019
From: klappnase at web.de (Michael Lange)
Date: Tue, 10 Dec 2019 12:11:50 +0100
Subject: [Tkinter-discuss] How to handle any Windows message (eg.
 WM_GETOBJECT)?
In-Reply-To: <34ace98d-cc07-2f7a-9fe6-0ee2730fdcc4@gmail.com>
References: <34ace98d-cc07-2f7a-9fe6-0ee2730fdcc4@gmail.com>
Message-ID: <20191210121150.2ab6abb9a9cdbb351ed531b6@web.de>

Hi,

On Tue, 10 Dec 2019 12:49:27 +0200
Aivar Annamaa <aivar.annamaa at gmail.com> wrote:

> Hi!
>
> It looks like accessibility support in Tk won't happen
> (https://core.tcl-lang.org/tk/tktview/deb6cddecf55c6921281f8f855b6b366aed6467e).
> I'm wondering is it somehow possible to bolt on some accessibility
> support at least on Windows.
>
> It looks like the starting point is that the app should be able to
> provide customized responses to WM_GETOBJECT messages. I didn't find
> such name in Tk source code. Does it mean Tk event loop simply drops
> these? Is it somehow possible to install an extra WM event handler to
> catch these?

have you tried to do something like

def test():
    print('hello')
root.wm_protocol('WM_GETOBJECT', test)

I have no idea what WM_GETOBJECT does and if there is any chance that
this will work, though :)

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

I realize that command does have its fascination, even under
circumstances such as these, but I neither enjoy the idea of command
nor am I frightened of it.  It simply exists, and I will do whatever
logically needs to be done.
		-- Spock, "The Galileo Seven", stardate 2812.7

From aivar.annamaa at gmail.com  Tue Dec 10 16:36:07 2019
From: aivar.annamaa at gmail.com (Aivar Annamaa)
Date: Tue, 10 Dec 2019 23:36:07 +0200
Subject: [Tkinter-discuss] How to handle any Windows message (eg.
 WM_GETOBJECT)?
In-Reply-To: <20191210121150.2ab6abb9a9cdbb351ed531b6@web.de>
References: <34ace98d-cc07-2f7a-9fe6-0ee2730fdcc4@gmail.com>
 <20191210121150.2ab6abb9a9cdbb351ed531b6@web.de>
Message-ID: <92737213-4204-17e1-7ac2-4873ae482192@gmail.com>

Michael, thanks for the idea!

Unfortunately this does not work -- the callback is never called, even 
if the app is sent WM_GETOBJECT messages.

But I found another promising approach -- swapping Tk's message handler 
with my own handler:

    import tkinter as tk
    import win32gui
    import win32con

    root = tk.Tk()

    button = tk.Button(root, text="close", command=root.destroy)
    button.grid()


    hwnd = root.winfo_id()

    def new_wndproc(hWnd, msg, wParam, lParam):
     ??? if msg == win32con.WM_GETOBJECT:
     ??????? print(hWnd, msg, wParam, lParam)

     ??? # forward message to original (Tk) handler
     ??? return win32gui.CallWindowProc(old_wndproc, hWnd, msg, wParam,
    lParam)

    # install new windows message handler
    old_wndproc = win32gui.SetWindowLong(hwnd, win32con.GWL_WNDPROC,
    new_wndproc)

    root.mainloop()

I'll see where this road takes me.

Best regards,
Aivar




On 10.12.2019 13:11, Michael Lange wrote:
> Hi,
>
> On Tue, 10 Dec 2019 12:49:27 +0200
> Aivar Annamaa <aivar.annamaa at gmail.com> wrote:
>
>> Hi!
>>
>> It looks like accessibility support in Tk won't happen
>> (https://core.tcl-lang.org/tk/tktview/deb6cddecf55c6921281f8f855b6b366aed6467e).
>> I'm wondering is it somehow possible to bolt on some accessibility
>> support at least on Windows.
>>
>> It looks like the starting point is that the app should be able to
>> provide customized responses to WM_GETOBJECT messages. I didn't find
>> such name in Tk source code. Does it mean Tk event loop simply drops
>> these? Is it somehow possible to install an extra WM event handler to
>> catch these?
> have you tried to do something like
>
> def test():
>      print('hello')
> root.wm_protocol('WM_GETOBJECT', test)
>
> I have no idea what WM_GETOBJECT does and if there is any chance that
> this will work, though :)
>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> I realize that command does have its fascination, even under
> circumstances such as these, but I neither enjoy the idea of command
> nor am I frightened of it.  It simply exists, and I will do whatever
> logically needs to be done.
> 		-- Spock, "The Galileo Seven", stardate 2812.7
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> https://mail.python.org/mailman/listinfo/tkinter-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20191210/0b69bd99/attachment.html>

From mike_barnett at hotmail.com  Sat Dec 14 14:10:00 2019
From: mike_barnett at hotmail.com (Mike Barnett)
Date: Sat, 14 Dec 2019 19:10:00 +0000
Subject: [Tkinter-discuss] Lines around Tk Widgets on Linux but not
 Windows
In-Reply-To: <BY5PR05MB7090028B8C1715777BCFB707E0570@BY5PR05MB7090.namprd05.prod.outlook.com>
References: <BY5PR05MB7090028B8C1715777BCFB707E0570@BY5PR05MB7090.namprd05.prod.outlook.com>
Message-ID: <BY5PR05MB7090FF5DA830E309A57FAA77E0570@BY5PR05MB7090.namprd05.prod.outlook.com>

I figured it out!  Just took more digging.   I could swear I've set highlightthickness=0 before, but evidently not because that fixed it.


From: Mike Barnett <mike_barnett at hotmail.com>
Sent: Saturday, December 14, 2019 1:27 PM
To: Python-Tkinter <tkinter-discuss at python.org>
Subject: Lines around Tk Widgets on Linux but not Windows

I've had this problem for a very long time and have not been able to fix it regardless of what I've tried.

My tk widgets all have a white border, despite setting the border width to zero.


I don't have this problem on the Scale widget and on ttk widgets.

The buttons you see along the bottom of the attached screenshot are TK Buttons except for one of them which is a TTK Button.  The ttk one doesn't have a border.

Any clues as to what I need to configure to remove these?  They show up on Linux (including the Pi) and online on Trinket.

Thank you for any kind of clues at all for me to investigate!

-mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20191214/91b3df01/attachment.html>

From mike_barnett at hotmail.com  Sun Dec 15 13:29:18 2019
From: mike_barnett at hotmail.com (Mike Barnett)
Date: Sun, 15 Dec 2019 18:29:18 +0000
Subject: [Tkinter-discuss] The Async delete problem....
Message-ID: <BY5PR05MB70909F796CEF3C6517318DF5E0560@BY5PR05MB7090.namprd05.prod.outlook.com>

I've been fighting this error for a couple of years now and just when I think I've got it understood and "Fixed", it bites me again.



Here's the error:



Exception ignored in: <function Variable.__del__ at 0x0000016CA840C9D0>

Traceback (most recent call last):

  File "X:\Python\python3.8\lib\tkinter\__init__.py", line 351, in __del__

    if self._tk.getboolean(self._tk.call("info", "exists", self._name)):

RuntimeError: main thread is not in main loop

Exception ignored in: <function Variable.__del__ at 0x0000016CA840C9D0>

Traceback (most recent call last):

  File "X:\Python\python3.8\lib\tkinter\__init__.py", line 351, in __del__

    if self._tk.getboolean(self._tk.call("info", "exists", self._name)):

RuntimeError: main thread is not in main loop

Exception ignored in: <function Variable.__del__ at 0x0000016CA840C9D0>

Traceback (most recent call last):

  File "X:\Python\python3.8\lib\tkinter\__init__.py", line 351, in __del__

    if self._tk.getboolean(self._tk.call("info", "exists", self._name)):

RuntimeError: main thread is not in main loop

Exception ignored in: <function Image.__del__ at 0x0000016CA8446310>

Traceback (most recent call last):

  File "X:\Python\python3.8\lib\tkinter\__init__.py", line 4014, in __del__

    self.tk.call('image', 'delete', self.name)

RuntimeError: main thread is not in main loop

Tcl_AsyncDelete: async handler deleted by the wrong thread







It happens in programs that are multi-threaded.  The threads do NOT make any tkinter calls and do not touch any variable that has anything to do with tkinter.



What appears to be happening is that tkinter objects are marked to be deleted and then when Python's garbage collect runs and actually does the deletes, it is happening in the context of the thread, not the main thread.



My way around this at the moment is to keep the widgets around for the duration of the program rather than deleting them in any way.  I would really like to get this solved though as other people using my code run into this and don't know what to do.



Any ideas on how to dispose of widgets / windows in a way that immediately calls these delete methods? Or is it possible to tell tkinter that despite the deletes being called from another thread it's OK because the thread isn't actually changing anything at the same time as the main thread?



Thank you



-mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20191215/43993dda/attachment.html>

From klappnase at web.de  Sun Dec 15 17:15:48 2019
From: klappnase at web.de (Michael Lange)
Date: Sun, 15 Dec 2019 23:15:48 +0100
Subject: [Tkinter-discuss] The Async delete problem....
In-Reply-To: <BY5PR05MB70909F796CEF3C6517318DF5E0560@BY5PR05MB7090.namprd05.prod.outlook.com>
References: <BY5PR05MB70909F796CEF3C6517318DF5E0560@BY5PR05MB7090.namprd05.prod.outlook.com>
Message-ID: <20191215231548.63828cc33969ad371cd9568f@web.de>

Hi,

On Sun, 15 Dec 2019 18:29:18 +0000
Mike Barnett <mike_barnett at hotmail.com> wrote:

> I've been fighting this error for a couple of years now and just when I
> think I've got it understood and "Fixed", it bites me again.
>
>
>
> Here's the error:
>
>
>
> Exception ignored in: <function Variable.__del__ at 0x0000016CA840C9D0>
>
> Traceback (most recent call last):
>
>   File "X:\Python\python3.8\lib\tkinter\__init__.py", line 351, in
> __del__
>
>     if self._tk.getboolean(self._tk.call("info", "exists", self._name)):
>
> RuntimeError: main thread is not in main loop
(...)

> It happens in programs that are multi-threaded.  The threads do NOT
> make any tkinter calls and do not touch any variable that has anything
> to do with tkinter.
>
> What appears to be happening is that tkinter objects are marked to be
> deleted and then when Python's garbage collect runs and actually does
> the deletes, it is happening in the context of the thread, not the main
> thread.
>
> My way around this at the moment is to keep the widgets around for the
> duration of the program rather than deleting them in any way.  I would
> really like to get this solved though as other people using my code run
> into this and don't know what to do.
>
> Any ideas on how to dispose of widgets / windows in a way that
> immediately calls these delete methods? Or is it possible to tell
> tkinter that despite the deletes being called from another thread it's
> OK because the thread isn't actually changing anything at the same time
> as the main thread?
>

I am not sure what is happening here. It sounds a bit as if the tk gui is
not in the main program thread? If yes, maybe this causes the problem; as
far as I know it is imperative that the tk mainloop is inside
the main program thread.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

We're all sorry for the other guy when he loses his job to a machine.
But when it comes to your job -- that's different.  And it always will
be different.
		-- McCoy, "The Ultimate Computer", stardate 4729.4

From mike_barnett at hotmail.com  Sun Dec 15 17:18:22 2019
From: mike_barnett at hotmail.com (Mike Barnett)
Date: Sun, 15 Dec 2019 22:18:22 +0000
Subject: [Tkinter-discuss] The Async delete problem....
In-Reply-To: <20191215231548.63828cc33969ad371cd9568f@web.de>
References: <BY5PR05MB70909F796CEF3C6517318DF5E0560@BY5PR05MB7090.namprd05.prod.outlook.com>
 <20191215231548.63828cc33969ad371cd9568f@web.de>
Message-ID: <BY5PR05MB7090ABB59D05085B0BBA16DBE0560@BY5PR05MB7090.namprd05.prod.outlook.com>

That's how it looks.... but I can assure you that the thread are not running the mainloop.  There are no tkinter calls made from any thread other than the main thread.



-----Original Message-----
From: Tkinter-discuss <tkinter-discuss-bounces+mike_barnett=hotmail.com at python.org> On Behalf Of Michael Lange
Sent: Sunday, December 15, 2019 5:16 PM
To: tkinter-discuss at python.org
Subject: Re: [Tkinter-discuss] The Async delete problem....

Hi,

On Sun, 15 Dec 2019 18:29:18 +0000
Mike Barnett <mike_barnett at hotmail.com> wrote:

> I've been fighting this error for a couple of years now and just when 
> I think I've got it understood and "Fixed", it bites me again.
>
>
>
> Here's the error:
>
>
>
> Exception ignored in: <function Variable.__del__ at 
> 0x0000016CA840C9D0>
>
> Traceback (most recent call last):
>
>   File "X:\Python\python3.8\lib\tkinter\__init__.py", line 351, in 
> __del__
>
>     if self._tk.getboolean(self._tk.call("info", "exists", self._name)):
>
> RuntimeError: main thread is not in main loop
(...)

> It happens in programs that are multi-threaded.  The threads do NOT 
> make any tkinter calls and do not touch any variable that has anything 
> to do with tkinter.
>
> What appears to be happening is that tkinter objects are marked to be 
> deleted and then when Python's garbage collect runs and actually does 
> the deletes, it is happening in the context of the thread, not the 
> main thread.
>
> My way around this at the moment is to keep the widgets around for the 
> duration of the program rather than deleting them in any way.  I would 
> really like to get this solved though as other people using my code 
> run into this and don't know what to do.
>
> Any ideas on how to dispose of widgets / windows in a way that 
> immediately calls these delete methods? Or is it possible to tell 
> tkinter that despite the deletes being called from another thread it's 
> OK because the thread isn't actually changing anything at the same 
> time as the main thread?
>

I am not sure what is happening here. It sounds a bit as if the tk gui is not in the main program thread? If yes, maybe this causes the problem; as far as I know it is imperative that the tk mainloop is inside the main program thread.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

We're all sorry for the other guy when he loses his job to a machine.
But when it comes to your job -- that's different.  And it always will be different.
		-- McCoy, "The Ultimate Computer", stardate 4729.4 _______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss at python.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Ftkinter-discuss&amp;data=02%7C01%7C%7C1b1a8693fa62493a417108d781ac6023%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637120449647261354&amp;sdata=Rui1yhlJkmvxrA2xz9MtgdJG5zIJbHb8VjwQjqHKD6k%3D&amp;reserved=0

From greg.ewing at canterbury.ac.nz  Sun Dec 15 17:39:17 2019
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 16 Dec 2019 11:39:17 +1300
Subject: [Tkinter-discuss] The Async delete problem....
In-Reply-To: <BY5PR05MB7090ABB59D05085B0BBA16DBE0560@BY5PR05MB7090.namprd05.prod.outlook.com>
References: <BY5PR05MB70909F796CEF3C6517318DF5E0560@BY5PR05MB7090.namprd05.prod.outlook.com>
 <20191215231548.63828cc33969ad371cd9568f@web.de>
 <BY5PR05MB7090ABB59D05085B0BBA16DBE0560@BY5PR05MB7090.namprd05.prod.outlook.com>
Message-ID: <49d5ae65-5b1c-8e02-2add-4f39edf42034@canterbury.ac.nz>

On 16/12/19 11:18 am, Mike Barnett wrote:
> There are no tkinter calls made from any thread other than the main thread.

It looks like some tkinter objects are becoming part of garbage
cycles, and getting collected by whatever thread happens to be
running when the cyclic gc kicks in.

Seems to me this is fundamentally tk's fault for assuming that
__del__ methods will be called from any particular thread.

As a workaround, maybe you could manually trigger a gc whenever
you dispose of a widget.

-- 
Greg

From mike_barnett at hotmail.com  Sun Dec 15 17:46:48 2019
From: mike_barnett at hotmail.com (Mike Barnett)
Date: Sun, 15 Dec 2019 22:46:48 +0000
Subject: [Tkinter-discuss] The Async delete problem....
In-Reply-To: <49d5ae65-5b1c-8e02-2add-4f39edf42034@canterbury.ac.nz>
References: <BY5PR05MB70909F796CEF3C6517318DF5E0560@BY5PR05MB7090.namprd05.prod.outlook.com>
 <20191215231548.63828cc33969ad371cd9568f@web.de>
 <BY5PR05MB7090ABB59D05085B0BBA16DBE0560@BY5PR05MB7090.namprd05.prod.outlook.com>
 <49d5ae65-5b1c-8e02-2add-4f39edf42034@canterbury.ac.nz>
Message-ID: <BY5PR05MB7090AC2C20E01AF2ED2CB193E0560@BY5PR05MB7090.namprd05.prod.outlook.com>

I've been trying to figure out how to trigger the garbage collect.  Do you have any clues Greg?  This is EXACTLY what's happening.


-----Original Message-----
From: Tkinter-discuss <tkinter-discuss-bounces+mike_barnett=hotmail.com at python.org> On Behalf Of Greg Ewing
Sent: Sunday, December 15, 2019 5:39 PM
To: tkinter-discuss at python.org
Subject: Re: [Tkinter-discuss] The Async delete problem....

On 16/12/19 11:18 am, Mike Barnett wrote:
> There are no tkinter calls made from any thread other than the main thread.

It looks like some tkinter objects are becoming part of garbage cycles, and getting collected by whatever thread happens to be running when the cyclic gc kicks in.

Seems to me this is fundamentally tk's fault for assuming that __del__ methods will be called from any particular thread.

As a workaround, maybe you could manually trigger a gc whenever you dispose of a widget.

--
Greg
_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss at python.org
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Ftkinter-discuss&amp;data=02%7C01%7C%7Cceb5540d0dbd43ea8f0208d781afad89%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637120463832895147&amp;sdata=b8%2BnDr1VkUzIBS5ut1e4fg%2FeUhUDx%2BkNeE6f56370%2FQ%3D&amp;reserved=0

From mike_barnett at hotmail.com  Sun Dec 15 18:09:29 2019
From: mike_barnett at hotmail.com (Mike Barnett)
Date: Sun, 15 Dec 2019 23:09:29 +0000
Subject: [Tkinter-discuss] The Async delete problem....
In-Reply-To: <49d5ae65-5b1c-8e02-2add-4f39edf42034@canterbury.ac.nz>
References: <BY5PR05MB70909F796CEF3C6517318DF5E0560@BY5PR05MB7090.namprd05.prod.outlook.com>
 <20191215231548.63828cc33969ad371cd9568f@web.de>
 <BY5PR05MB7090ABB59D05085B0BBA16DBE0560@BY5PR05MB7090.namprd05.prod.outlook.com>
 <49d5ae65-5b1c-8e02-2add-4f39edf42034@canterbury.ac.nz>
Message-ID: <BY5PR05MB70905D2B670E8A366CE34FA6E0560@BY5PR05MB7090.namprd05.prod.outlook.com>

Aha!  Greg, you've given me the clue I needed.  I never thought to look into how to trigger a garbage collect.  I assumed (incorrectly) that it was something hidden away from users and that I couldn't do anything about it.  Researching more, I see that I can indeed trigger a garbage collect myself, etc.

Thank you for looking at this and coming to the same conclusion that I have about the garbage collect causing the crashes.  

Wow, I really appreciate this.  I've spent weeks/months on this problem off and on.

-mike



-----Original Message-----
From: Tkinter-discuss <tkinter-discuss-bounces+mike_barnett=hotmail.com at python.org> On Behalf Of Greg Ewing
Sent: Sunday, December 15, 2019 5:39 PM
To: tkinter-discuss at python.org
Subject: Re: [Tkinter-discuss] The Async delete problem....

On 16/12/19 11:18 am, Mike Barnett wrote:
> There are no tkinter calls made from any thread other than the main thread.

It looks like some tkinter objects are becoming part of garbage cycles, and getting collected by whatever thread happens to be running when the cyclic gc kicks in.

Seems to me this is fundamentally tk's fault for assuming that __del__ methods will be called from any particular thread.

As a workaround, maybe you could manually trigger a gc whenever you dispose of a widget.

--
Greg
_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss at python.org
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Ftkinter-discuss&amp;data=02%7C01%7C%7Cceb5540d0dbd43ea8f0208d781afad89%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637120463832895147&amp;sdata=b8%2BnDr1VkUzIBS5ut1e4fg%2FeUhUDx%2BkNeE6f56370%2FQ%3D&amp;reserved=0

From Vasilis.Vlachoudis at cern.ch  Wed Dec 18 10:54:04 2019
From: Vasilis.Vlachoudis at cern.ch (Vasilis Vlachoudis)
Date: Wed, 18 Dec 2019 15:54:04 +0000
Subject: [Tkinter-discuss] wait_window exception
Message-ID: <0BC70B5D93E054469872FFD0FE07220E02E64565D0@CERNXCHG53.cern.ch>

What is the correct way to open a dialog and wait for the window
Typically I am doing the following
on a class subclassed of Toplevel

	# ----------------------------------------------------------------------
	def __init__(self, title=None,
			master=None,
			**kw):


		super().__init__(master, class_="FileDialog")
		self.transient(master)
		self.title(title)
		self.protocol("WM_DELETE_WINDOW", self.close)

                # ... all initialization.... etc...


	def show(self):
		self.focus_set()
		try:
			self.deiconify()
			self.wait_visibility()
			self.update_idletasks()
			self.grab_set()
		except tk.TclError:
			pass
		self.wait_window()
 
Unfortunately, several times when the system is not very responsive I get a traceback
report from my users like
  ...
  File \"/usr/local/flair/lib/bFileDialog.py\", line 361, in show
    self.wait_window()
  File \"/usr/lib64/python3.7/tkinter/__init__.py\", line 642, in wait_window
    self.tk.call(\'tkwait\', \'window\', window._w)
_tkinter.TclError: bad window path name \".!flair.!configdialog3.!opendialog\"


Is there the possibility that the user clicks on the "Ok" or "Cancel" button before
the code execution arrives to the wait_window(), so when it is there it gives the error message.
Or can be something else that I am missing.

Thanks in advance
Vasilis

From mike_barnett at hotmail.com  Sat Dec 14 13:27:05 2019
From: mike_barnett at hotmail.com (Mike Barnett)
Date: Sat, 14 Dec 2019 18:27:05 +0000
Subject: [Tkinter-discuss] Lines around Tk Widgets on Linux but not Windows
Message-ID: <BY5PR05MB7090028B8C1715777BCFB707E0570@BY5PR05MB7090.namprd05.prod.outlook.com>

I've had this problem for a very long time and have not been able to fix it regardless of what I've tried.



My tk widgets all have a white border, despite setting the border width to zero.





I don't have this problem on the Scale widget and on ttk widgets.



The buttons you see along the bottom of the attached screenshot are TK Buttons except for one of them which is a TTK Button.  The ttk one doesn't have a border.



Any clues as to what I need to configure to remove these?  They show up on Linux (including the Pi) and online on Trinket.



Thank you for any kind of clues at all for me to investigate!



-mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20191214/edcd7d16/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SNAG-0608.jpg
Type: image/jpeg
Size: 263172 bytes
Desc: SNAG-0608.jpg
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20191214/edcd7d16/attachment-0001.jpg>

From klappnase at web.de  Tue Dec 24 07:59:42 2019
From: klappnase at web.de (Michael Lange)
Date: Tue, 24 Dec 2019 13:59:42 +0100
Subject: [Tkinter-discuss] wait_window exception
In-Reply-To: <0BC70B5D93E054469872FFD0FE07220E02E64565D0@CERNXCHG53.cern.ch>
References: <0BC70B5D93E054469872FFD0FE07220E02E64565D0@CERNXCHG53.cern.ch>
Message-ID: <20191224135942.a80b36f9dcbb19075cc3e965@web.de>

Hi,

sorry for the late reply.

On Wed, 18 Dec 2019 15:54:04 +0000
Vasilis Vlachoudis <Vasilis.Vlachoudis at cern.ch> wrote:

> What is the correct way to open a dialog and wait for the window
> Typically I am doing the following
> on a class subclassed of Toplevel
>
> 	# ----------------------------------------------------------------------
> 	def __init__(self, title=None,
> 			master=None,
> 			**kw):
>
>
> 		super().__init__(master, class_="FileDialog")
> 		self.transient(master)
> 		self.title(title)
> 		self.protocol("WM_DELETE_WINDOW", self.close)
>
>                 # ... all initialization.... etc...
>
>
> 	def show(self):
> 		self.focus_set()
> 		try:
> 			self.deiconify()
> 			self.wait_visibility()
> 			self.update_idletasks()
> 			self.grab_set()
> 		except tk.TclError:
> 			pass
> 		self.wait_window()
>
> Unfortunately, several times when the system is not very responsive I
> get a traceback report from my users like
>   ...
>   File \"/usr/local/flair/lib/bFileDialog.py\", line 361, in show
>     self.wait_window()
>   File \"/usr/lib64/python3.7/tkinter/__init__.py\", line 642, in
> wait_window self.tk.call(\'tkwait\', \'window\', window._w)
> _tkinter.TclError: bad window path name \".!flair.!configdialog3.!
> opendialog\"
>
>
> Is there the possibility that the user clicks on the "Ok" or "Cancel"
> button before the code execution arrives to the wait_window(), so when
> it is there it gives the error message. Or can be something else that I
> am missing.

I am not sure what may be the problem here. What does the close() method
do exactly, is it possible that the problem lies there?

A happy Christmas to all of you!

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

One of the advantages of being a captain is being able to ask for
advice without necessarily having to take it.
		-- Kirk, "Dagger of the Mind", stardate 2715.2

From Vasilis.Vlachoudis at cern.ch  Wed Dec 25 12:04:04 2019
From: Vasilis.Vlachoudis at cern.ch (Vasilis Vlachoudis)
Date: Wed, 25 Dec 2019 17:04:04 +0000
Subject: [Tkinter-discuss] wait_window exception
In-Reply-To: <20191224135942.a80b36f9dcbb19075cc3e965@web.de>
References: <0BC70B5D93E054469872FFD0FE07220E02E64565D0@CERNXCHG53.cern.ch>,
 <20191224135942.a80b36f9dcbb19075cc3e965@web.de>
Message-ID: <0BC70B5D93E054469872FFD0FE07220E02E645B288@CERNXCHG53.cern.ch>

Thanks Michael
my best wishes to you too.
The close method is the following, apart some bookkeeping nothing special.
	# ----------------------------------------------------------------------
	def close(self):
		FileDialog._active = False
		FileDialog.width   = self.winfo_width()
		FileDialog.height  = self.winfo_height()
		FileDialog.sash    = [self.fileList.paneframe.sash_coord(i)[0]
					for i in range(len(self.fileList.listboxes())-1)]
		tkExtra.ExListbox.resetSearch()
		self.grab_release()
		self.destroy()

I've realized that the "deiconify()" was creating some problems on Windows, so I removed it, and it seems it works better.
When I will deploy this version I will know after if it still generates problems.

Thanks
Vasilis


________________________________________
From: Tkinter-discuss [tkinter-discuss-bounces+vasilis.vlachoudis=cern.ch at python.org] on behalf of Michael Lange [klappnase at web.de]
Sent: Tuesday, December 24, 2019 13:59
To: tkinter-discuss at python.org
Subject: Re: [Tkinter-discuss] wait_window exception

Hi,

sorry for the late reply.

On Wed, 18 Dec 2019 15:54:04 +0000
Vasilis Vlachoudis <Vasilis.Vlachoudis at cern.ch> wrote:

> What is the correct way to open a dialog and wait for the window
> Typically I am doing the following
> on a class subclassed of Toplevel
>
>       # ----------------------------------------------------------------------
>       def __init__(self, title=None,
>                       master=None,
>                       **kw):
>
>
>               super().__init__(master, class_="FileDialog")
>               self.transient(master)
>               self.title(title)
>               self.protocol("WM_DELETE_WINDOW", self.close)
>
>                 # ... all initialization.... etc...
>
>
>       def show(self):
>               self.focus_set()
>               try:
>                       self.deiconify()
>                       self.wait_visibility()
>                       self.update_idletasks()
>                       self.grab_set()
>               except tk.TclError:
>                       pass
>               self.wait_window()
>
> Unfortunately, several times when the system is not very responsive I
> get a traceback report from my users like
>   ...
>   File \"/usr/local/flair/lib/bFileDialog.py\", line 361, in show
>     self.wait_window()
>   File \"/usr/lib64/python3.7/tkinter/__init__.py\", line 642, in
> wait_window self.tk.call(\'tkwait\', \'window\', window._w)
> _tkinter.TclError: bad window path name \".!flair.!configdialog3.!
> opendialog\"
>
>
> Is there the possibility that the user clicks on the "Ok" or "Cancel"
> button before the code execution arrives to the wait_window(), so when
> it is there it gives the error message. Or can be something else that I
> am missing.

I am not sure what may be the problem here. What does the close() method
do exactly, is it possible that the problem lies there?

A happy Christmas to all of you!

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

One of the advantages of being a captain is being able to ask for
advice without necessarily having to take it.
                -- Kirk, "Dagger of the Mind", stardate 2715.2
_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss at python.org
https://mail.python.org/mailman/listinfo/tkinter-discuss

From klappnase at web.de  Fri Dec 27 02:20:38 2019
From: klappnase at web.de (Michael Lange)
Date: Fri, 27 Dec 2019 08:20:38 +0100
Subject: [Tkinter-discuss] wait_window exception
In-Reply-To: <0BC70B5D93E054469872FFD0FE07220E02E645B288@CERNXCHG53.cern.ch>
References: <0BC70B5D93E054469872FFD0FE07220E02E64565D0@CERNXCHG53.cern.ch>
 <20191224135942.a80b36f9dcbb19075cc3e965@web.de>
 <0BC70B5D93E054469872FFD0FE07220E02E645B288@CERNXCHG53.cern.ch>
Message-ID: <20191227082038.7c3b1479902d9a8b762a1185@web.de>

Hi,

On Wed, 25 Dec 2019 17:04:04 +0000
Vasilis Vlachoudis <Vasilis.Vlachoudis at cern.ch> wrote:

> Thanks Michael
> my best wishes to you too.
> The close method is the following, apart some bookkeeping nothing
> special.
> 	# ----------------------------------------------------------------------
> 	def close(self):
> 		FileDialog._active = False
> 		FileDialog.width   = self.winfo_width()
> 		FileDialog.height  = self.winfo_height()
> 		FileDialog.sash    = [self.fileList.paneframe.sash_coord
> (i)[0] for i in range(len(self.fileList.listboxes())-1)]
> 		tkExtra.ExListbox.resetSearch()
> 		self.grab_release()
> 		self.destroy()
>
> I've realized that the "deiconify()" was creating some problems on
> Windows, so I removed it, and it seems it works better. When I will
> deploy this version I will know after if it still generates problems.

it seems rather odd if actually deiconify() is the culprit here.
Another thought that occurred to me, is the window path name ".!flair.!
configdialog3.!opendialog\" assigned manually? If yes, is it possible
that a second window that tries to go by the same path name interferes
here?

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

If some day we are defeated, well, war has its fortunes, good and bad.
		-- Commander Kor, "Errand of Mercy", stardate 3201.7