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

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

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
>>

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).

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.

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

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

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.

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..

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..

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.

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.

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

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.

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)

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..

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.