Hi,
I'm trying to have a number of canvasses that can be scrolled. When the user hovers over a canvas I'd like the outline to change as a highlight.

right now I have them set up as canvasses within frames on a larger canvas to scroll them all.

Enter/leave events for each canvas aren't usable since both seem to get triggered before each mouse event.. is this expected behavior, or a bug? this is on wish 8.6.11 (x11/xfce on mx linux)

Using 'motion' works when the user is moving the mouse, but I'd like the correct highlight to occur using the mouse wheel as well. (so after scrolling using the mouse wheel, the highlight changes to reflect the canvas under the mouse position). I can do
the geometry manually using the canvasy command but it takes math that it seems like tk should already be doing, and I have to account for padding manually etc. I'd also like to use enter/leave since motion triggers much more often..

maybe there would be some way to use bindtags or something? thanks for any suggestions

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, October 29, 2022 at 5:19:26 PM UTC-7, Seb Shader wrote:

Hi,
I'm trying to have a number of canvasses that can be scrolled. When the user hovers over a canvas I'd like the outline to change as a highlight.

right now I have them set up as canvasses within frames on a larger canvas to scroll them all.

Enter/leave events for each canvas aren't usable since both seem to get triggered before each mouse event.. is this expected behavior, or a bug? this is on wish 8.6.11 (x11/xfce on mx linux)

Using 'motion' works when the user is moving the mouse, but I'd like the correct highlight to occur using the mouse wheel as well. (so after scrolling using the mouse wheel, the highlight changes to reflect the canvas under the mouse position). I can

do the geometry manually using the canvasy command but it takes math that it seems like tk should already be doing, and I have to account for padding manually etc. I'd also like to use enter/leave since motion triggers much more often..

maybe there would be some way to use bindtags or something? thanks for any suggestions

for a simple script that triggers enter/leave on each mouse event:

set count 0
canvas .c -bd 0 -width 400 -height 400 -background blue
pack .c
bind .c <Leave> {
puts "$count leave"
incr count
}
bind .c <Enter> {
puts "$count enter"
incr count
}
bind .c <Button-4> {
puts "$count Mousewheel 1"
incr count
}
bind .c <Button-5> {
puts "$count Mousewheel -1"
incr count
}
bind .c <ButtonPress> {
puts "$count Click"
incr count
}

the output in the terminal is like
10 leave
11 enter
12 Mousewheel -1
13 leave
14 enter
15 Mousewheel 1
16 leave
17 enter
18 Mousewheel 1
19 leave
20 enter
21 Click

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 29 Oct 2022 17:31:37 -0700 (PDT), Seb Shader wrote:

On Saturday, October 29, 2022 at 5:19:26 PM UTC-7, Seb Shader wrote:

Hi,
I'm trying to have a number of canvasses that can be scrolled. When the user hovers over a canvas I'd like the outline to change as a
highlight.

right now I have them set up as canvasses within frames on a larger
canvas to scroll them all.

Enter/leave events for each canvas aren't usable since both seem to get triggered before each mouse event.. is this expected behavior, or a
bug? this is on wish 8.6.11 (x11/xfce on mx linux)

Using 'motion' works when the user is moving the mouse, but I'd like
the correct highlight to occur using the mouse wheel as well. (so after scrolling using the mouse wheel, the highlight changes to reflect the canvas under the mouse position). I can do the geometry manually using
the canvasy command but it takes math that it seems like tk should
already be doing, and I have to account for padding manually etc. I'd
also like to use enter/leave since motion triggers much more often..

maybe there would be some way to use bindtags or something? thanks for
any suggestions

for a simple script that triggers enter/leave on each mouse event:

set count 0
canvas .c -bd 0 -width 400 -height 400 -background blue
pack .c
bind .c <Leave> {
puts "$count leave"
incr count
}
bind .c <Enter> {
puts "$count enter"
incr count
}
bind .c <Button-4> {
puts "$count Mousewheel 1"
incr count
}
bind .c <Button-5> {
puts "$count Mousewheel -1"
incr count
}
bind .c <ButtonPress> {
puts "$count Click"
incr count
}

I don't know what you mean by "canvas that can be scrolled."

What about this code? Why is it not what you want and what do you want
more exactly?

----
package require Tk

set ofr [frame .outerframe -padx 15 -pady 15]
pack $ofr

canvas $ofr.c -bd 0 -width 400 -height 200 -background blue
pack $ofr.c

canvas $ofr.cc -bd 0 -width 400 -height 200 -background red
pack $ofr.cc

bind $ofr.c <Enter> {
$ofr.c configure -borderwidth 4 -relief solid
}
bind $ofr.c <Leave> {
$ofr.c configure -borderwidth 0 -relief flat
}
----


--
Luc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Seb Shader <sebshader@gmail.com> wrote:

for a simple script that triggers enter/leave on each mouse event:

set count 0
canvas .c -bd 0 -width 400 -height 400 -background blue
pack .c
bind .c <Leave> {
puts "$count leave"
incr count
}
bind .c <Enter> {
puts "$count enter"
incr count
}
bind .c <Button-4> {
puts "$count Mousewheel 1"
incr count
}
bind .c <Button-5> {
puts "$count Mousewheel -1"
incr count
}
bind .c <ButtonPress> {
puts "$count Click"
incr count
}

the output in the terminal is like
10 leave
11 enter
12 Mousewheel -1
13 leave
14 enter
15 Mousewheel 1
16 leave
17 enter
18 Mousewheel 1
19 leave
20 enter
21 Click

Fully expected results from your example code. Binding scripts are
executed at global level, so you have only one single shared count
variable across all five bindings.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Seb Shader <sebshader@gmail.com> wrote:

Hi,

I'm trying to have a number of canvasses that can be scrolled. When
the user hovers over a canvas I'd like the outline to change as a
highlight.
...
Enter/leave events for each canvas aren't usable since both seem to
get triggered before each mouse event.. is this expected behavior,
or a bug? this is on wish 8.6.11 (x11/xfce on mx linux)

Please explain how enter/leave events are not usable. This code below
prints the expected results under Linux on 8.6.11:

#!/usr/bin/wish

canvas .outer -width 800 -height 800

canvas .inner -width 200 -height 200 -background yellow

.outer create window 0 0 -anchor center -window .inner

pack .outer

bind .inner <Enter> [list enter %W]
bind .inner <Leave> [list leave %W]

proc enter {w} {
puts stderr "enter: w='$w'"
}

proc leave {w} {
puts stderr "leave: w='$w'"
}

When the mouse enters the inner canvas, an enter event is generated.
When it leaves the same, a leave event is generated. The enter event
can cause a border to appear around the canvas, and the leave event can teardown the border the enter event erected (borders are not
implemented in the example code above).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, October 29, 2022 at 9:00:14 PM UTC-7, Rich wrote:

Seb Shader <sebs...@gmail.com> wrote:

for a simple script that triggers enter/leave on each mouse event:

set count 0
canvas .c -bd 0 -width 400 -height 400 -background blue
pack .c
bind .c <Leave> {
puts "$count leave"
incr count
}
bind .c <Enter> {
puts "$count enter"
incr count
}
bind .c <Button-4> {
puts "$count Mousewheel 1"
incr count
}
bind .c <Button-5> {
puts "$count Mousewheel -1"
incr count
}
bind .c <ButtonPress> {
puts "$count Click"
incr count
}

the output in the terminal is like
10 leave
11 enter
12 Mousewheel -1
13 leave
14 enter
15 Mousewheel 1
16 leave
17 enter
18 Mousewheel 1
19 leave
20 enter
21 Click

Fully expected results from your example code. Binding scripts are
executed at global level, so you have only one single shared count
variable across all five bindings.

the count variable is just to have line numbers in the terminal output, that wasn't my issue

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Seb Shader <sebshader@gmail.com> wrote:

On Saturday, October 29, 2022 at 8:57:29 PM UTC-7, Rich wrote:

Seb Shader <sebs...@gmail.com> wrote:

Hi,

I'm trying to have a number of canvasses that can be scrolled. When
the user hovers over a canvas I'd like the outline to change as a
highlight.
...
Enter/leave events for each canvas aren't usable since both seem to
get triggered before each mouse event.. is this expected behavior,
or a bug? this is on wish 8.6.11 (x11/xfce on mx linux)

Please explain how enter/leave events are not usable. This code below
prints the expected results under Linux on 8.6.11:

#!/usr/bin/wish

canvas .outer -width 800 -height 800

canvas .inner -width 200 -height 200 -background yellow

.outer create window 0 0 -anchor center -window .inner

pack .outer

bind .inner <Enter> [list enter %W]
bind .inner <Leave> [list leave %W]

proc enter {w} {
puts stderr "enter: w='$w'"
}

proc leave {w} {
puts stderr "leave: w='$w'"
}

When the mouse enters the inner canvas, an enter event is generated.
When it leaves the same, a leave event is generated. The enter event
can cause a border to appear around the canvas, and the leave event can
teardown the border the enter event erected (borders are not
implemented in the example code above).

If I click or do a mousewheel scroll in the the yellow canvas in your example, both enter and leave events are triggered/printed for each
of those mouse events, before the actual events are (based on my
tests). This is an issue because it will create flickering if the
border 'highlight' is supposed to be bound to/based on them. The
issue isn't so much enter/leave events not working, but being
triggered by mouse events as well for some reason

Running my exact code, in a fresh wish interpreter, I can click, or
mousewheel, as much as I like on/above the yellow canvas and neither of
my 'enter' or 'leave' events fires.

So you have to provide more to us here (i.e., some code that shows the
issue). Everything looks to be working as expected, and to an extent
that borders can be created/removed via enter/leave events.

If you want to edit my code to make it do what you see, that is fine,
but, you need to supply the edited code so we can also see the issue.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 30, 2022 at 5:52:15 AM UTC-7, Rich wrote:

Seb Shader <sebs...@gmail.com> wrote:

On Saturday, October 29, 2022 at 8:57:29 PM UTC-7, Rich wrote:

Seb Shader <sebs...@gmail.com> wrote:

Hi,

I'm trying to have a number of canvasses that can be scrolled. When
the user hovers over a canvas I'd like the outline to change as a
highlight.
...
Enter/leave events for each canvas aren't usable since both seem to
get triggered before each mouse event.. is this expected behavior,
or a bug? this is on wish 8.6.11 (x11/xfce on mx linux)

Please explain how enter/leave events are not usable. This code below
prints the expected results under Linux on 8.6.11:

#!/usr/bin/wish

canvas .outer -width 800 -height 800

canvas .inner -width 200 -height 200 -background yellow

.outer create window 0 0 -anchor center -window .inner

pack .outer

bind .inner <Enter> [list enter %W]
bind .inner <Leave> [list leave %W]

proc enter {w} {
puts stderr "enter: w='$w'"
}

proc leave {w} {
puts stderr "leave: w='$w'"
}

When the mouse enters the inner canvas, an enter event is generated.
When it leaves the same, a leave event is generated. The enter event
can cause a border to appear around the canvas, and the leave event can
teardown the border the enter event erected (borders are not
implemented in the example code above).

If I click or do a mousewheel scroll in the the yellow canvas in your example, both enter and leave events are triggered/printed for each
of those mouse events, before the actual events are (based on my
tests). This is an issue because it will create flickering if the
border 'highlight' is supposed to be bound to/based on them. The
issue isn't so much enter/leave events not working, but being
triggered by mouse events as well for some reason

Running my exact code, in a fresh wish interpreter, I can click, or mousewheel, as much as I like on/above the yellow canvas and neither of
my 'enter' or 'leave' events fires.

So you have to provide more to us here (i.e., some code that shows the issue). Everything looks to be working as expected, and to an extent
that borders can be created/removed via enter/leave events.

If you want to edit my code to make it do what you see, that is fine,
but, you need to supply the edited code so we can also see the issue.

Both your example and the 1st example of code in my 2nd post emit Enter & Leave events before each mouse event (well scrollwheel & click, doesn't seem to happen with motion). I posted the output of my terminal to illustrate that in my 2nd post..
If you can't reproduce maybe it's because you aren't on x11 or 8.6.11? that seems to indicate that either it's either a bug on x11, or there's some x11 configuration/option that needs to be changed..

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 30, 2022 at 10:12:47 AM UTC-7, Seb Shader wrote:

On Sunday, October 30, 2022 at 5:52:15 AM UTC-7, Rich wrote:

Seb Shader <sebs...@gmail.com> wrote:

On Saturday, October 29, 2022 at 8:57:29 PM UTC-7, Rich wrote:

Seb Shader <sebs...@gmail.com> wrote:

Hi,

I'm trying to have a number of canvasses that can be scrolled. When
the user hovers over a canvas I'd like the outline to change as a
highlight.
...
Enter/leave events for each canvas aren't usable since both seem to
get triggered before each mouse event.. is this expected behavior,
or a bug? this is on wish 8.6.11 (x11/xfce on mx linux)

Please explain how enter/leave events are not usable. This code below
prints the expected results under Linux on 8.6.11:

#!/usr/bin/wish

canvas .outer -width 800 -height 800

canvas .inner -width 200 -height 200 -background yellow

.outer create window 0 0 -anchor center -window .inner

pack .outer

bind .inner <Enter> [list enter %W]
bind .inner <Leave> [list leave %W]

proc enter {w} {
puts stderr "enter: w='$w'"
}

proc leave {w} {
puts stderr "leave: w='$w'"
}

When the mouse enters the inner canvas, an enter event is generated.
When it leaves the same, a leave event is generated. The enter event
can cause a border to appear around the canvas, and the leave event can >> teardown the border the enter event erected (borders are not
implemented in the example code above).

If I click or do a mousewheel scroll in the the yellow canvas in your example, both enter and leave events are triggered/printed for each
of those mouse events, before the actual events are (based on my
tests). This is an issue because it will create flickering if the
border 'highlight' is supposed to be bound to/based on them. The
issue isn't so much enter/leave events not working, but being
triggered by mouse events as well for some reason

Running my exact code, in a fresh wish interpreter, I can click, or mousewheel, as much as I like on/above the yellow canvas and neither of
my 'enter' or 'leave' events fires.

So you have to provide more to us here (i.e., some code that shows the issue). Everything looks to be working as expected, and to an extent
that borders can be created/removed via enter/leave events.

If you want to edit my code to make it do what you see, that is fine,
but, you need to supply the edited code so we can also see the issue.

Both your example and the 1st example of code in my 2nd post emit Enter & Leave events before each mouse event (well scrollwheel & click, doesn't seem to happen with motion). I posted the output of my terminal to illustrate that in my 2nd post..
If you can't reproduce maybe it's because you aren't on x11 or 8.6.11? that seems to indicate that either it's either a bug on x11, or there's some x11 configuration/option that needs to be changed..

sorry, I didn't see that you were on linux (I presume x11) 8.6.11.. odd. Maybe it is actually some configuration issue, possibly w/ xfce..

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Seb Shader <sebshader@gmail.com> wrote:

On Sunday, October 30, 2022 at 10:12:47 AM UTC-7, Seb Shader wrote:

Both your example and the 1st example of code in my 2nd post emit
Enter & Leave events before each mouse event (well scrollwheel &
click, doesn't seem to happen with motion). I posted the output of
my terminal to illustrate that in my 2nd post.. If you can't
reproduce maybe it's because you aren't on x11 or 8.6.11? that
seems to indicate that either it's either a bug on x11, or there's
some x11 configuration/option that needs to be changed..

sorry, I didn't see that you were on linux (I presume x11) 8.6.11..
odd. Maybe it is actually some configuration issue, possibly w/
xfce..

Yup, X11. I am, however, running fvwm2 as window manager, so there is
a possibility it is an xfce related issue.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Seb Shader <sebshader@gmail.com> wrote:

Both your example and the 1st example of code in my 2nd post emit
Enter & Leave events before each mouse event (well scrollwheel &
click, doesn't seem to happen with motion).

Not for me.

I posted the output of my terminal to illustrate that in my 2nd
post.. If you can't reproduce maybe it's because you aren't on x11
or 8.6.11?

From my very first post in this sub-thread: "Linux on 8.6.11".

I'm on X11, Linux, and 8.6.11. My code I posted does not trigger
either the enter, nor the leave, events on either clicking or
scrollwheel motion.

that seems to indicate that either it's either a bug on x11, or
there's some x11 configuration/option that needs to be changed..

Unsure, but here, on X11 and 8.6.11, my code works as expected.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 30, 2022 at 11:32:36 AM UTC-7, Rich wrote:

Seb Shader <sebs...@gmail.com> wrote:

On Sunday, October 30, 2022 at 10:12:47 AM UTC-7, Seb Shader wrote:

Both your example and the 1st example of code in my 2nd post emit
Enter & Leave events before each mouse event (well scrollwheel &
click, doesn't seem to happen with motion). I posted the output of
my terminal to illustrate that in my 2nd post.. If you can't
reproduce maybe it's because you aren't on x11 or 8.6.11? that
seems to indicate that either it's either a bug on x11, or there's
some x11 configuration/option that needs to be changed..

sorry, I didn't see that you were on linux (I presume x11) 8.6.11..
odd. Maybe it is actually some configuration issue, possibly w/
xfce..

Yup, X11. I am, however, running fvwm2 as window manager, so there is
a possibility it is an xfce related issue.

Turns out this has been seen before, and is actually oddly dependent on being on using xfce or lxde:
https://linux.debian.user.narkive.com/dXxiVBcM/strange-event-handling-problem-with-xfce-lxde-which-pkg-responsible

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'm running Tcl/Tk 8.6.8 or 8.6.12 on Linux with fvwm, and cannot see the problems described above.
Perhaps adding more information to the puts in the bindings would help.
For example for Leave try something like:

bind .inner <Leave> {puts "[incr count] Leave %W mode: %m state: %s detail: %d"}

Dave B

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 30, 2022 at 8:53:53 PM UTC-7, clt.to...@dfgh.net wrote:

I'm running Tcl/Tk 8.6.8 or 8.6.12 on Linux with fvwm, and cannot see the problems described above.
Perhaps adding more information to the puts in the bindings would help.
For example for Leave try something like:

bind .inner <Leave> {puts "[incr count] Leave %W mode: %m state: %s detail: %d"}

Dave B

Like I said, this is a known bug (as logged in the debian bug tracker) and apparently only affects openbox, lxde, and xfce.
Though I can't see if there's been any attention on it.. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929090

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/10/2022 21:50, Seb Shader wrote:

sorry, I didn't see that you were on linux (I presume x11) 8.6.11..
odd. Maybe it is actually some configuration issue, possibly w/
xfce..

Yup, X11. I am, however, running fvwm2 as window manager, so there is
a possibility it is an xfce related issue.

Turns out this has been seen before, and is actually oddly dependent on being on using xfce or lxde:
https://linux.debian.user.narkive.com/dXxiVBcM/strange-event-handling-problem-with-xfce-lxde-which-pkg-responsible

I see a possible conceptual confusion in this thread (including the websites to which Seb referred
for a wider recognition of the issue) between a desktop environment and a window manager.

The issue described in this thread may be related to the desktop environment and/or window manager.
(Though personally, I would expect the window manager to be the culprit, first).

XFCE and LXDE are desktop environments. They may employ - or operate in concert with - different
window managers. Openbox appears to be a window manager. For example, I have XFCE installed, and I
can to make it work with Xfwm4 or Sawfish as the window manager.

Different window managers can make an essential difference (while keeping the desktop environment).

Regards,
Erik
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, October 31, 2022 at 1:10:21 AM UTC-7, Erik Leunissen wrote:

On 30/10/2022 21:50, Seb Shader wrote:

sorry, I didn't see that you were on linux (I presume x11) 8.6.11..
odd. Maybe it is actually some configuration issue, possibly w/
xfce..

Yup, X11. I am, however, running fvwm2 as window manager, so there is
a possibility it is an xfce related issue.

Turns out this has been seen before, and is actually oddly dependent on being on using xfce or lxde:
https://linux.debian.user.narkive.com/dXxiVBcM/strange-event-handling-problem-with-xfce-lxde-which-pkg-responsible

I see a possible conceptual confusion in this thread (including the websites to which Seb referred
for a wider recognition of the issue) between a desktop environment and a window manager.

The issue described in this thread may be related to the desktop environment and/or window manager.
(Though personally, I would expect the window manager to be the culprit, first).

XFCE and LXDE are desktop environments. They may employ - or operate in concert with - different
window managers. Openbox appears to be a window manager. For example, I have XFCE installed, and I
can to make it work with Xfwm4 or Sawfish as the window manager.

Different window managers can make an essential difference (while keeping the desktop environment).

Regards,
Erik
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

true, I guess it's more precise to say the issue likely occurs in xfwm, openbox and whatever lxde is using (seems likely to be openbox or xfwm)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/10/2022 18:41, Seb Shader wrote:

But I wonder why it works for you on xfwm4 then..

I just commented on the words used in this discussion thread. I didn't do any testing.

Erik.
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, October 31, 2022 at 8:40:39 AM UTC-7, Seb Shader wrote:

On Monday, October 31, 2022 at 1:10:21 AM UTC-7, Erik Leunissen wrote:

On 30/10/2022 21:50, Seb Shader wrote:

sorry, I didn't see that you were on linux (I presume x11) 8.6.11..
odd. Maybe it is actually some configuration issue, possibly w/
xfce..

Yup, X11. I am, however, running fvwm2 as window manager, so there is
a possibility it is an xfce related issue.

Turns out this has been seen before, and is actually oddly dependent on being on using xfce or lxde:
https://linux.debian.user.narkive.com/dXxiVBcM/strange-event-handling-problem-with-xfce-lxde-which-pkg-responsible

I see a possible conceptual confusion in this thread (including the websites to which Seb referred
for a wider recognition of the issue) between a desktop environment and a window manager.

The issue described in this thread may be related to the desktop environment and/or window manager.
(Though personally, I would expect the window manager to be the culprit, first).

XFCE and LXDE are desktop environments. They may employ - or operate in concert with - different
window managers. Openbox appears to be a window manager. For example, I have XFCE installed, and I
can to make it work with Xfwm4 or Sawfish as the window manager.

Different window managers can make an essential difference (while keeping the desktop environment).

Regards,
Erik
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

true, I guess it's more precise to say the issue likely occurs in xfwm, openbox and whatever lxde is using (seems likely to be openbox or xfwm)

But I wonder why it works for you on xfwm4 then..

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)