Hello,
I don't have code to reproduce the things I mention below but all of
this runs fine on MS Windows. I suppose I can add workarounds for each
but I wonder if there is a simple answer behind all this. The Linux is
Debian 11.5 64 bit running inside a vm. Tcl version is 8.6.12, 64 bit.

I have a script that creates a window with a menubar and a canvas. The
menubar has a File sub-menu for selecting/deleting/copying files.

1) When I click on an item under File and make a selection, the menu
does not disappear. Instead, it stays on. Even after I move the window
to which it is connected, the menu stays where it was displayed. The
"-tearoff" option is off and set to zero. The action assigned to the
menu item starts running and popping up its own dialogs, etc. But the
menu lingers on.

2) I create a toplevel with "wm overrideredirect". This new window does
not respond to Events such as FocusIn/FocusOut/Enter/Leave/etc.

3) The window I created in step 2 above does a tk_popup menu. This does
not show up. Perhaps it is hidden under the window and it is invisible.
I am not sure.

4) Is there an alternative to fsdialog? It seems to have some bugs. But
I think I will post it separately with its own error messages.

saitology9 <saitology9@gmail.com> wrote:
> Hello,
> I don't have code to reproduce the things I mention below but all of
> this runs fine on MS Windows. I suppose I can add workarounds for each
> but I wonder if there is a simple answer behind all this. The Linux is
> Debian 11.5 64 bit running inside a vm. Tcl version is 8.6.12, 64 bit.
>
> I have a script that creates a window with a menubar and a canvas. The
> menubar has a File sub-menu for selecting/deleting/copying files.
>
> 1) When I click on an item under File and make a selection, the menu
> does not disappear. Instead, it stays on. Even after I move the window
> to which it is connected, the menu stays where it was displayed. The
> "-tearoff" option is off and set to zero. The action assigned to the
> menu item starts running and popping up its own dialogs, etc. But the
> menu lingers on.

Unable to recreate on Linux, even with code that intentionally blocks
the event loop:

menu .mb
menu .file
.file add command -label Open -command {after 10000}
.mb add cascade -menu .file -label File
. configure -menu .mb

The menu disappears, then the UI freezes for 10 seconds (before all of
the original menubar border is redrawn). After 10 seconds, all
returns to normal.

> 2) I create a toplevel with "wm overrideredirect". This new window does
> not respond to Events such as FocusIn/FocusOut/Enter/Leave/etc.

Expected under X11. overrideredirect windows are ignored by the window
manager, and it is the window manager that controls focus and
enter/leave events for windows on X11. This is mentioned in the Tk
docs (the 'ignore' part, the docs presume knowledge of what functions
the window manager performs on X11):

man wm:

wm overrideredirect window ?boolean?

... Setting the override-redirect flag for a window causes it to
be ignored by the window manager; among other things, this
means that the window will not be reparented from the root
window into a decorative frame and the user will not be able to
manipulate the window using the normal window manager
mechanisms. ...

> 3) The window I created in step 2 above does a tk_popup menu.

Windows themselves don't do anything. The tcl code that creates the
overrideredirect window also runs tk_popup.

> This does not show up. Perhaps it is hidden under the window and it
> is invisible. I am not sure.

Did you also create a menu to 'pop up' -- or are you 'poping up' the
menu from #1 that looks to be stuck? Which might be why the #1 menu
appears to 'get stuck'.

Are you doing anything else that might block the event loop?

On 10/26/2022 6:24 PM, Rich wrote:
>
> Expected under X11. overrideredirect windows are ignored by the window
> manager, and it is the window manager that controls focus and
> enter/leave events for windows on X11. This is mentioned in the Tk
> docs (the 'ignore' part, the docs presume knowledge of what functions
> the window manager performs on X11):
>
> man wm:
>
> wm overrideredirect window ?boolean?
>
> ... Setting the override-redirect flag for a window causes it to
> be ignored by the window manager; among other things, this
> means that the window will not be reparented from the root
> window into a decorative frame and the user will not be able to
> manipulate the window using the normal window manager
> mechanisms. ...
>

Thank you for input. Your code ran fine, of course. It was almost
identical to what my script had. Weird. Then I thought I'd remove the
override flag and guess what? Things are working better now. The
tk_popup, tk_optionMenu, etc. were all popping up, but under that
window! They were invisible and and since they required user input, I
can only guess, they were blocking other things as well. Interesting
difference between MS Windows and Linux.

Thanks again!

On Wed, 26 Oct 2022 17:19:19 -0400, saitology9 wrote:

> 4) Is there an alternative to fsdialog?

I am working on an alternative to tk_getOpenFile and tk_getSaveFile right now,
which I guess can also be counted as an alternative to fsdialog, but it's
still a work in progress.

And I only work on it in my free time, which I don't have every day. ETA is
one or two weeks. Probably two. Three is not out of question.

And I expect bugs to be found by people who actually know what they're doing
after I publish it.

And I'm not even testing it on Windows.

And I don't even have a Mac machine.

And it may seem a bit unusual to a lot of people. I never do things in the
most usual or popular ways.

And I have no plans for access to virtual file systems, which fsdialog has.

So you may not want to hold your breath about it.

--
Luc
>>

On 10/27/2022 1:20 AM, Luc wrote:
> On Wed, 26 Oct 2022 17:19:19 -0400, saitology9 wrote:
>
>> 4) Is there an alternative to fsdialog?
>
> I am working on an alternative to tk_getOpenFile and tk_getSaveFile right now,
> which I guess can also be counted as an alternative to fsdialog, but it's
> still a work in progress.

Actually, fsdialog is pretty decent. There may be a bug or two around
the edge cases but that is normal. The package owners seem responsive
and it is easy enough to fix when you need to.