Tk Source Code

Resizing a toplevel by dragging a corner or edge causes the toplevel to receive button press and release events, which I do not observe on X11 and Windows.

This poses an annoyance if there is a widget at the edge of the window that responds to a button event. An example is the Tktable demos which have a redundant "Exit" button at the bottom; so on Aqua, just resizing the window tends to close the demo.

The problem might more generally be that the window receives mouse press events when all that is being clicked is the window manager decorations, which doesn't happen on X11 and Windows.

I have not examined the issue enough to have an idea of how to address it. However attempting to filter out button events that are outside of the area of the toplevel would not be sufficient, because the region for resizing windows is still a few pixels within the toplevel.

This is fixed (again) by the changes that fixed [39cbacb9e8], so I think I
can close the ticket.

Unfortunately, it does not work to convert the window coordinates of the mouse
to the contentView coordinates and test if the point is inside the view frame.
It can report yes when the mouse is inside the resize area, which apparently
extends 3 pixels into the contentView.

Also, it turns out that the resize area includes a 15 x 15 square at the lower
right corner of the window where the size grip would have been displayed on an
old mac.  That part of the resize area is detected by the enter / exit events
but was not detected before.

You can add an NSTrackingArea for the NSView and then NSMouseEntered and
NSMouseExited events would be generated when the mouse enters or leaves the
NSView.  But that doesn't change the requirement that state be remembered and
it adds additional checking of coordinates.  With the default setting we are
notified when the mouse goes inside or outside of the resizing halo union the
titlebar, which is exactly when we want to ignore the button press events.

However, there is one other thing worth trying, which might be even easier.
Maybe we can just check whether the mouse coordinates are inside the contentView.
I don't really know why that was not tested.

I have tried and tried to reproduce the issue from [39cbacb9e8] and have never
succeeded.  What is the magic trick?

I reported [39cbacb9e8] a while after this issue had first been fixed. I still observe that issue in core-8-6-branch [3745ef1194] and mac_enter_exit [5ea8262198].

I would be curious if there's an even cleaner way of listening for events only for the contentView, rather than the whole NSWindow and having to filter out events (e.g. based on position and/or by keeping track of state).

it works better here.

thanks.
++

Incidentally, I think that fixing this issue also fixed [d72abe6b54],
which reported that positioning the close button over a link in the demo
and closing the window would launch the demo.

I have reopened this ticket and re-implemented the fix using the
NSMouseExited and NSMouseEntered events.  This eliminates the hard-wired
3-pixel width for the resize halo, so should be more robust with
respect to changes in new operating system releases.

The new branch is called mac_enter_exit.

Hi Marc,
that's a good news !!

++

I just discovered something which looks like it will be helpful here.
It appears that there is an NSTrackingArea which is active for an
NSWindow.  This has the consequence that when the mouse enters the
resizing halo around a window, an NSMouseEntered event is sent to
the window, and when the mouse leaves the resizing halo and enters
either the NSWindow's contentView or the surrounding desktop, an
NSMouseExitedEvent is generated.

This means that we can track whether the mouse is in the resizing halo
of a window and ignore button press events when they are intended for
resizing.  We don't have to make assumptions about the size of the
halo.

just one more request about this, with the following script 'push' is prompted when I release the size grip.
I personally would much prefer if no event were trigger when releasing the grip of a window.

thanks.

package require Tk
package require Ttk

catch {namespace delete obj}
namespace eval obj {
    array set obj {}
}


proc displayStuff {namespace} {
    for {set x 1} {$x<10} {incr x} {
        set this($x) [\
        ttk::label .b$x -text push\
        ]
        bind .b$x <ButtonRelease-1> {puts "have pushed"}
        grid $this($x) -sticky news
    }
    grid columnconfigure . all -weight 1
    grid rowconfigure . all -weight 1
}

displayStuff obj

Closing the ticket.  This has been merged into mac_styles as well.

In macOS 10.6 (Snow Leopard) windows had a size grip at the lower left corner
and could not be resized by grabbing an edge of the window.  This was changed
in macOS 10.7 (Lion) which removed the size grip.  So I think this fix should
only be applied in 10.7 and later.  As far as I can tell there has been no
change in the width of the "edge" of a window since 10.7.  Needless to say,
however, there is no Apple documentation about the size of the edge.

Apple does provide a notifications for when "LiveResize" begins and ends.
However my tests showed that the callback for the start of LiveResize is not
called until after the button press event has been generated.  For us, this
means that a ButtonPress event has already been added to the Tcl queue when
the callback is executed.  Most of the time it does not actually get handled
until the resize finishes.  So it might be possible to remove that event from
the Tcl Queue in the LiveResizeWillBegin callback.  But that looks hugely more
complicated and fraught with risks of timing-related errors.  Given that the 3-pixel boundary size has been stable for 8 years now, I am inclined to use
the code as is, except on macOS 10.6.

Hi,
would it be possible to merge this into mac_styles branch?

++

Thanks, I have tested on Catalina, and the basic issue seems resolved. I'm not familiar with all of the different ways of making windows non-resizable and checking what differences might exist for those.

I don't think I can come up with a better approach. It would be nice if there was a way to directly check whether the pointer was in the area to perform the resize (rather than indirectly check by hardcoding the size of this area), but I have not found if such an approach is even possible.

hi,
tested on macOS 10.15.4 and it works great, at least it's much better than before.
before the fix as Christopher have reported trying to resize toplevel when a button was bottom right triggered the button command, now it's not which is better .

thanks,
++

The resize zone extends 3 pixels into the window (on Catalina, anyway).  I
pushed a bugfix branch bug-d72abe6b54 which ignores mouse down events in that
zone in the sense that no XEvent is generated for those NSEvents.

Please test!