vtwm-hackers — People who use and modify vtwm

[Vtwm-hackers] Menu Colour Conundrum

[Graham B. <ad...@cp...>]

Hi list!

Coming back to vtwm after a long time away can I ask;

How can I influence the menu highlight colour?

That is - when I scroll over a menu item?

 From plain old twm this is what I have in my menu;

"Fileman"            ("#1A88F2":"#3a3a3a") f.exec "xfe &"
"Terminal"           ("#FFB816":"#3a3a3a") f.exec "xterm &"

normally the text is coloured and the background is the
same colour as the rest of the menu background. When I
scroll over it, the highlight area becomes coloured and
the font colour swap places.

In vtwm something else happens? The 'highlight' colour
goes a shade darker and the font colour reverts back
to the rest of the menu font colour from the global
MenuForeground?

What am I missing?

Cheers!

-- 
Graham Bentley
Custom PC North West
Web: www.cpcnw.co.uk
Mobile: 07970 040237
Office: 01704 778241

Re: [Vtwm-hackers] function f.scroll from tvtwm and/or add f.scroll ?

[Kurt J. <vt...@op...>]

Hi!

Callum wrote:
> Here is what I use (I have a 3440x1440 panel, so desktop coords are
> in multiples of that).
> 
> # Virtual Desktop Direct Dial
> "KP_0"          = c     : all                   : f.setrealscreen "+0+0"
> "KP_F1"         = c     : all                   : f.setrealscreen "+0+0"
> "KP_Divide"     = c     : all                   : f.setrealscreen "+3440+0"
> "KP_Multiply"   = c     : all                   : f.setrealscreen "+6880+0"

Oh my... I overlooked that!

Thanks, I'll test and work with that!

-- 
pi...@op...            +49 171 3101372                    Now what ?

Re: [Vtwm-hackers] function f.scroll from tvtwm and/or add f.scroll ?

[Callum G. <cal...@op...>]

Here is what I use (I have a 3440x1440 panel, so desktop coords are
in multiples of that).

# Virtual Desktop Direct Dial
"KP_0"          = c     : all                   : f.setrealscreen "+0+0"
"KP_F1"         = c     : all                   : f.setrealscreen "+0+0"
"KP_Divide"     = c     : all                   : f.setrealscreen "+3440+0"
"KP_Multiply"   = c     : all                   : f.setrealscreen "+6880+0"
"KP_7"          = c     : all                   : f.setrealscreen "+0+1440"
"KP_8"          = c     : all                   : f.setrealscreen "+3440+1440"
"KP_9"          = c     : all                   : f.setrealscreen "+6880+1440"
"KP_4"          = c     : all                   : f.setrealscreen "+0+2880"
"KP_5"          = c     : all                   : f.setrealscreen "+3440+2880"
"KP_6"          = c     : all                   : f.setrealscreen "+6880+2880"
"KP_1"          = c     : all                   : f.setrealscreen "+0+4320"
"KP_2"          = c     : all                   : f.setrealscreen "+3440+4320"
"KP_3"          = c     : all                   : f.setrealscreen "+6880+4320"

As you can see vtwm's virtual desktop does not represent itself in terms of
numbered desktops, but this allows additional flexibility like panning by
only half a screen or a panel at a time if you have if you have dual screen
setup.

    C

On 15Jan24 08:11, Callum Gibson wrote:
> Yes, this function already exists so save yourself the trouble. I have it
> setup on my work machine where I use Ctrl-<Numpad> to warp to 12(!) different
> virtual desktops.  I'm pretty sure it's f.setrealscreen you need. Will confirm
> in a couple of hours when I get there.
> 
>     C
> 
> On 14Jan24 20:10, Kurt Jaeger wrote:
> > Hello,
> > 
> > I'm a long-term tvtwm user migrating to vtwm, because tvtwm will
> > no longer be supported by the FreeBSD ports tree.
> > 
> > I've made the jump already, and everything somewhat works fine,
> > and it looks *very* much like the old setup, so I'm an almost happy camper 8-)
> > 
> > But: I have two questions:
> > 
> > 1) Is there a f.scroll function in vtwm which I did not find in the
> > man pages ?
> > 
> > My use-case has this config snippet in .twmrc:
> > 
> > "F1"    = m     : all   : f.scrollhome
> > "F2"    = m     : all   : f.scroll "+1+1"
> > "F3"    = m     : all   : f.scroll "+2+1"
> > "F4"    = m     : all   : f.scroll "+3+1"
> > "F5"    = m     : all   : f.scroll "+4+1"
> > "F6"    = m     : all   : f.scroll "+5+1"
> > "F7"    = m     : all   : f.scroll "+6+1"
> > 
> > which basically switches the viewport between one of seven
> > 'screens' using Alt-F<n> (with n from 1 to 7).
> > 
> > It's similar to the f.panleft/f.panright, but those are relative,
> > and do not allow to jump to some absolut screen number. It
> > works, but it's annoying to have to press multiple times to jump
> > to screen 'n'.
> > 
> > 2) How do I add a f.scroll function ?
> > 
> > I attempted to patch by adding
> > 
> > 2.1)
> > 
> > #define F_SCROLL              72
> > 
> > to parse.h,
> > 
> > 2.2)
> > 
> > {"f.scroll", FSKEYWORD, F_SCROLL},
> > 
> > to parse.c in the static TwmKeyword keytable[],
> > 
> > 2.3) and
> > 
> >      case F_SCROLL:
> >        SetRealScreen((atoi(action) * Scr->MyDisplayWidth), 0);
> >        break;
> > 
> > to menus.c
> > 
> > The problem: When I rebuild the window manager, it no longer
> > finds the keywords f.move, f.menu and does not find f.scroll.
> > 
> > So I guess I oversaw some magic, probably in lex.l and gram.y ?
> > 
> > Can someone give me a pointer on how to get this done properly ?
> > I'll submit a proper patch as soon as it works.
> > 
> > For the time being, I replaced the call in
> > 
> > case F_PANUP:
> >   PanRealScreen(0, -((atoi(action) * Scr->MyDisplayHeight) / 100), NULL, NULL);
> > 
> > with
> > 
> > case F_PANUP:
> >   SetRealScreen((atoi(action) * Scr->MyDisplayWidth), 0);
> > 
> > because I do not use F_PANUP in my .vtwmrc. It's a hack, but it works fine 8-}
> > 
> > -- 
> > pi...@op...            +49 171 3101372                    Now what ?
> > 
> > 
> > _______________________________________________
> > Vtwm-hackers mailing list
> > Vtw...@li...
> > https://lists.sourceforge.net/lists/listinfo/vtwm-hackers
> 
> -- 
> 
>     Callum Gibson
> 

-- 

    Callum Gibson

Re: [Vtwm-hackers] function f.scroll from tvtwm and/or add f.scroll ?

[Seth R. <in...@ba...>]

Welcome!

I have two solutions, neither of which were tested.

Solution one, create a new function which does f.panup "1000"\n
f.panleft "1000"\n and then right/down as appropriate.  Not elegant,
but it should work (well, assuming that it prevents you from going
negative and instead will cap your movement at 0).

Second, use f.setrealscreen which is documented to teleport you to
some virtual window coordinates.  This seems the best option.

Also, make sure you are using the latest vtwm--I don't know if FreeBSD
has the latest version packaged.

Please let us know if it doesn't work and we can investigate further.


Thanks,
					-Seth Robertson




From: Kurt Jaeger
Date: Sun, 14 Jan 2024 20:10:13 +0100
To: vtw...@li...
Subject: [Vtwm-hackers] function f.scroll from tvtwm and/or add f.scroll ?

Hello,

I'm a long-term tvtwm user migrating to vtwm, because tvtwm will
no longer be supported by the FreeBSD ports tree.

I've made the jump already, and everything somewhat works fine,
and it looks *very* much like the old setup, so I'm an almost happy camper 8-)

But: I have two questions:

1) Is there a f.scroll function in vtwm which I did not find in the
man pages ?

My use-case has this config snippet in .twmrc:

"F1"    = m     : all   : f.scrollhome
"F2"    = m     : all   : f.scroll "+1+1"
"F3"    = m     : all   : f.scroll "+2+1"
"F4"    = m     : all   : f.scroll "+3+1"
"F5"    = m     : all   : f.scroll "+4+1"
"F6"    = m     : all   : f.scroll "+5+1"
"F7"    = m     : all   : f.scroll "+6+1"

which basically switches the viewport between one of seven
'screens' using Alt-F<n> (with n from 1 to 7).

It's similar to the f.panleft/f.panright, but those are relative,
and do not allow to jump to some absolut screen number. It
works, but it's annoying to have to press multiple times to jump
to screen 'n'.

2) How do I add a f.scroll function ?

I attempted to patch by adding

2.1)

#define F_SCROLL              72

to parse.h,

2.2)

{"f.scroll", FSKEYWORD, F_SCROLL},

to parse.c in the static TwmKeyword keytable[],

2.3) and

     case F_SCROLL:
       SetRealScreen((atoi(action) * Scr->MyDisplayWidth), 0);
       break;

to menus.c

The problem: When I rebuild the window manager, it no longer
finds the keywords f.move, f.menu and does not find f.scroll.

So I guess I oversaw some magic, probably in lex.l and gram.y ?

Can someone give me a pointer on how to get this done properly ?
I'll submit a proper patch as soon as it works.

For the time being, I replaced the call in

case F_PANUP:
  PanRealScreen(0, -((atoi(action) * Scr->MyDisplayHeight) / 100), NULL, NULL);

with

case F_PANUP:
  SetRealScreen((atoi(action) * Scr->MyDisplayWidth), 0);

because I do not use F_PANUP in my .vtwmrc. It's a hack, but it works fine 8-}

-- 
pi...@op...            +49 171 3101372                    Now what ?


_______________________________________________
Vtwm-hackers mailing list
Vtw...@li...
https://lists.sourceforge.net/lists/listinfo/vtwm-hackers

Re: [Vtwm-hackers] function f.scroll from tvtwm and/or add f.scroll ?

[Callum G. <cal...@op...>]

Yes, this function already exists so save yourself the trouble. I have it
setup on my work machine where I use Ctrl-<Numpad> to warp to 12(!) different
virtual desktops.  I'm pretty sure it's f.setrealscreen you need. Will confirm
in a couple of hours when I get there.

    C

On 14Jan24 20:10, Kurt Jaeger wrote:
> Hello,
> 
> I'm a long-term tvtwm user migrating to vtwm, because tvtwm will
> no longer be supported by the FreeBSD ports tree.
> 
> I've made the jump already, and everything somewhat works fine,
> and it looks *very* much like the old setup, so I'm an almost happy camper 8-)
> 
> But: I have two questions:
> 
> 1) Is there a f.scroll function in vtwm which I did not find in the
> man pages ?
> 
> My use-case has this config snippet in .twmrc:
> 
> "F1"    = m     : all   : f.scrollhome
> "F2"    = m     : all   : f.scroll "+1+1"
> "F3"    = m     : all   : f.scroll "+2+1"
> "F4"    = m     : all   : f.scroll "+3+1"
> "F5"    = m     : all   : f.scroll "+4+1"
> "F6"    = m     : all   : f.scroll "+5+1"
> "F7"    = m     : all   : f.scroll "+6+1"
> 
> which basically switches the viewport between one of seven
> 'screens' using Alt-F<n> (with n from 1 to 7).
> 
> It's similar to the f.panleft/f.panright, but those are relative,
> and do not allow to jump to some absolut screen number. It
> works, but it's annoying to have to press multiple times to jump
> to screen 'n'.
> 
> 2) How do I add a f.scroll function ?
> 
> I attempted to patch by adding
> 
> 2.1)
> 
> #define F_SCROLL              72
> 
> to parse.h,
> 
> 2.2)
> 
> {"f.scroll", FSKEYWORD, F_SCROLL},
> 
> to parse.c in the static TwmKeyword keytable[],
> 
> 2.3) and
> 
>      case F_SCROLL:
>        SetRealScreen((atoi(action) * Scr->MyDisplayWidth), 0);
>        break;
> 
> to menus.c
> 
> The problem: When I rebuild the window manager, it no longer
> finds the keywords f.move, f.menu and does not find f.scroll.
> 
> So I guess I oversaw some magic, probably in lex.l and gram.y ?
> 
> Can someone give me a pointer on how to get this done properly ?
> I'll submit a proper patch as soon as it works.
> 
> For the time being, I replaced the call in
> 
> case F_PANUP:
>   PanRealScreen(0, -((atoi(action) * Scr->MyDisplayHeight) / 100), NULL, NULL);
> 
> with
> 
> case F_PANUP:
>   SetRealScreen((atoi(action) * Scr->MyDisplayWidth), 0);
> 
> because I do not use F_PANUP in my .vtwmrc. It's a hack, but it works fine 8-}
> 
> -- 
> pi...@op...            +49 171 3101372                    Now what ?
> 
> 
> _______________________________________________
> Vtwm-hackers mailing list
> Vtw...@li...
> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers

-- 

    Callum Gibson

[Vtwm-hackers] function f.scroll from tvtwm and/or add f.scroll ?

[Kurt J. <vt...@op...>]

Hello,

I'm a long-term tvtwm user migrating to vtwm, because tvtwm will
no longer be supported by the FreeBSD ports tree.

I've made the jump already, and everything somewhat works fine,
and it looks *very* much like the old setup, so I'm an almost happy camper 8-)

But: I have two questions:

1) Is there a f.scroll function in vtwm which I did not find in the
man pages ?

My use-case has this config snippet in .twmrc:

"F1"    = m     : all   : f.scrollhome
"F2"    = m     : all   : f.scroll "+1+1"
"F3"    = m     : all   : f.scroll "+2+1"
"F4"    = m     : all   : f.scroll "+3+1"
"F5"    = m     : all   : f.scroll "+4+1"
"F6"    = m     : all   : f.scroll "+5+1"
"F7"    = m     : all   : f.scroll "+6+1"

which basically switches the viewport between one of seven
'screens' using Alt-F<n> (with n from 1 to 7).

It's similar to the f.panleft/f.panright, but those are relative,
and do not allow to jump to some absolut screen number. It
works, but it's annoying to have to press multiple times to jump
to screen 'n'.

2) How do I add a f.scroll function ?

I attempted to patch by adding

2.1)

#define F_SCROLL              72

to parse.h,

2.2)

{"f.scroll", FSKEYWORD, F_SCROLL},

to parse.c in the static TwmKeyword keytable[],

2.3) and

     case F_SCROLL:
       SetRealScreen((atoi(action) * Scr->MyDisplayWidth), 0);
       break;

to menus.c

The problem: When I rebuild the window manager, it no longer
finds the keywords f.move, f.menu and does not find f.scroll.

So I guess I oversaw some magic, probably in lex.l and gram.y ?

Can someone give me a pointer on how to get this done properly ?
I'll submit a proper patch as soon as it works.

For the time being, I replaced the call in

case F_PANUP:
  PanRealScreen(0, -((atoi(action) * Scr->MyDisplayHeight) / 100), NULL, NULL);

with

case F_PANUP:
  SetRealScreen((atoi(action) * Scr->MyDisplayWidth), 0);

because I do not use F_PANUP in my .vtwmrc. It's a hack, but it works fine 8-}

-- 
pi...@op...            +49 171 3101372                    Now what ?

Re: [Vtwm-hackers] menus evaporate

[Callum G. <cal...@op...>]

Well, only when the focus has changed from an application to a popup menu
belonging to that application. Is that possible? Is there an example of
a focus-follows-mouse window manager where these obstreperous menus work?

If the focus actually changed to another app I don't want the original app
grabbing the focus back (too many examples of applications doing that already
- I'm looking at you java).

    C

On 31Oct23 22:31, Seth Robertson wrote:
> 
> Huh, so all we have to do is cause the f.focus function to
> automatically execute every time vtwm thinks the focus has changed?
> 
> Conceptually that is hacking HandleFocusChange() to call
> FocusOnClient() though I wonder if, once we have focused, whether vtwm
> gets notified of the focus change events (FocusIn|FocusOut) to be able
> to change again (or maybe it gets told of enter/leaveNotify and we can
> hack it that way?).
> 
> I'm not sure I have time to play with this immediately, but it seems
> possibly promising, if f.focus works for all cases (it worked for one
> Firefox test I did).
> 
> Thanks,
> 					-Seth Robertson
> 
> 
> From: Callum Gibson
> Date: Tue, 31 Oct 2023 08:50:20 +1100
> To: Bruno Melo
> Subject: Re: [Vtwm-hackers] menus evaporate
> 
> Ugh, I had quite a long reply half-formulated and then accidentally quit my
> whole session while trying to test it... Let's have another, but less complete,
> go as I need to run...
> 
> In response to Michael's comment, yes I use Button3 on title to f.focus for
> those temporary assignments.
> 
> For click-to-focus, there is an example in the contrib directory of the
> distribution. Thusly (uncommenting the two lines as indicated in the example below):
> 
> Function "move-or-raise"
> {
>        f.move
> # These two set up a click-to-type focus policy
> # (omitting the first allows it to be "togglable")...
> #       f.unfocus    <------ uncomment these
> #       f.focus      <------
>        f.deltastop
>        f.raise
> }
> 
> Button1 = : title|frame : f.function "move-or-raise"
> 
> So clicking on title or frame will focus on that window.
> 
> You could bind this to "window" as well, but then you can't use the click in
> the application - this is the one limitation of twm/vtwm/etc implementation
> using focus. To work around this, use a slightly different binding which uses
> Alt (signified by the "m" below) as well.
> 
> Button1 = m : window : f.function "move-or-raise"
> 
> There may be other ways to do it which don't have the work around, perhaps
> using f.unbindkeys or something, but I don't have time to play with it.
> Perhaps moving f.deltastop to the top of the function and getting rid of the
> f.move would do it. I would try this:
> 
> Function "move-or-raise2"
> {
>        f.deltastop
>        f.unfocus
>        f.focus
>        f.raise
> }
> 
> Button1 = : window : f.function "move-or-raise2"
> 
> However, I have not tested this to see if it works.  I'm not sure how other
> window managers get around this problem of who processes an event. That's
> some ideas to start with anyway for anyone who cares to try.
> 
> It would also be possible to bind Alt-Tab to cycle through the windows. This
> interacts weirdly with focus set, so unfortunately it's not as
> straightforward as
> 
> "Tab"         = m   : all                   : f.nexticonmgr
> 
> it appears to be necessary to define a function to unfocus the window first,
> then call f.nexticonmgr (and then refocus), but that's just a guess - again I
> haven't tested this, I just noted that f.nexticonmgr didn't work the same as
> it normally does when I use it when I had click-to-focus enabled.
> 
> It probably would be worth adding a complete example vtwmrc using click-to-focus
> to the contrib and/or web page (and name it "devil's focus model" or something... ;)
> 
>    C
> 
> On 30Oct23 13:33, Bruno Melo wrote:
> > And how to emulate ClickToFocus behavior? I'm not aware about it.
> 
> -- 
> 
>    Callum Gibson
> 
> 
> 
> _______________________________________________
> Vtwm-hackers mailing list
> Vtw...@li...
> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers

-- 

    Callum Gibson

Re: [Vtwm-hackers] menus evaporate

[Seth R. <in...@ba...>]

Huh, so all we have to do is cause the f.focus function to
automatically execute every time vtwm thinks the focus has changed?

Conceptually that is hacking HandleFocusChange() to call
FocusOnClient() though I wonder if, once we have focused, whether vtwm
gets notified of the focus change events (FocusIn|FocusOut) to be able
to change again (or maybe it gets told of enter/leaveNotify and we can
hack it that way?).

I'm not sure I have time to play with this immediately, but it seems
possibly promising, if f.focus works for all cases (it worked for one
Firefox test I did).

Thanks,
					-Seth Robertson


From: Callum Gibson
Date: Tue, 31 Oct 2023 08:50:20 +1100
To: Bruno Melo
Subject: Re: [Vtwm-hackers] menus evaporate

Ugh, I had quite a long reply half-formulated and then accidentally quit my
whole session while trying to test it... Let's have another, but less complete,
go as I need to run...

In response to Michael's comment, yes I use Button3 on title to f.focus for
those temporary assignments.

For click-to-focus, there is an example in the contrib directory of the
distribution. Thusly (uncommenting the two lines as indicated in the example below):

Function "move-or-raise"
{
        f.move
# These two set up a click-to-type focus policy
# (omitting the first allows it to be "togglable")...
#       f.unfocus    <------ uncomment these
#       f.focus      <------
        f.deltastop
        f.raise
}

Button1 = : title|frame : f.function "move-or-raise"

So clicking on title or frame will focus on that window.

You could bind this to "window" as well, but then you can't use the click in
the application - this is the one limitation of twm/vtwm/etc implementation
using focus. To work around this, use a slightly different binding which uses
Alt (signified by the "m" below) as well.

Button1 = m : window : f.function "move-or-raise"

There may be other ways to do it which don't have the work around, perhaps
using f.unbindkeys or something, but I don't have time to play with it.
Perhaps moving f.deltastop to the top of the function and getting rid of the
f.move would do it. I would try this:

Function "move-or-raise2"
{
        f.deltastop
        f.unfocus
        f.focus
        f.raise
}

Button1 = : window : f.function "move-or-raise2"

However, I have not tested this to see if it works.  I'm not sure how other
window managers get around this problem of who processes an event. That's
some ideas to start with anyway for anyone who cares to try.

It would also be possible to bind Alt-Tab to cycle through the windows. This 
interacts weirdly with focus set, so unfortunately it's not as straightforward as

"Tab"         = m   : all                   : f.nexticonmgr

it appears to be necessary to define a function to unfocus the window first,
then call f.nexticonmgr (and then refocus), but that's just a guess - again I
haven't tested this, I just noted that f.nexticonmgr didn't work the same as
it normally does when I use it when I had click-to-focus enabled.

It probably would be worth adding a complete example vtwmrc using click-to-focus
to the contrib and/or web page (and name it "devil's focus model" or something... ;)

    C

On 30Oct23 13:33, Bruno Melo wrote:
> And how to emulate ClickToFocus behavior? I'm not aware about it.

-- 

    Callum Gibson



_______________________________________________
Vtwm-hackers mailing list
Vtw...@li...
https://lists.sourceforge.net/lists/listinfo/vtwm-hackers

Re: [Vtwm-hackers] menus evaporate

[Kevin Vincent-S. {C. P. C. <ke...@jo...>]

On Mon, 30 Oct 2023, Michael Richardson wrote:

> Date: Mon, 30 Oct 2023 11:36:02 -0400
> From: Michael Richardson <mc...@sa...>
> To: Callum Gibson <cal...@op...>,
>     Bruno Melo via Vtwm-hackers <vtw...@li...>
> Subject: Re: [Vtwm-hackers] menus evaporate
> 
>
> Callum Gibson <cal...@op...> wrote:
>    > I agree it's not about dbus; it's about applications which assume a
>    > click to focus model. I use focus follows mouse. The fact firefox has
>    > a config option to alter the behaviour indicates it's a decision made
>    > by toolkits to assume that everyone wants to use Windows or macOS.
>
> I also use focus follow mouse, and frankly, I think it's the only true way to
> use a windowing system.  (I think that the windows/mac choice is driven by
> endless newbies.)

amen.  I'd like to use vtwm on Ubuntu 22.04.  I got follow-mouse to work by 
switching back to Xorg (from wayland), but still hate not having vtwm there.

> But, we are a very small minority: I think that we'll have to find a way to
> compensate.   I would tolerate some kind of control that I could bind to a
> key/mouse-chord that would either set/unset click-to-focus, toggle it, or
> maybe just set it for 10 to 30 seconds.

It used to work.  Heck, it even worked on 20.04 until some bloody update.

Anything I can do to help?

Re: [Vtwm-hackers] menus evaporate

[Callum G. <cal...@op...>]

Ugh, I had quite a long reply half-formulated and then accidentally quit my
whole session while trying to test it... Let's have another, but less complete,
go as I need to run...

In response to Michael's comment, yes I use Button3 on title to f.focus for
those temporary assignments.

For click-to-focus, there is an example in the contrib directory of the
distribution. Thusly (uncommenting the two lines as indicated in the example below):

Function "move-or-raise"
{
        f.move
# These two set up a click-to-type focus policy
# (omitting the first allows it to be "togglable")...
#       f.unfocus    <------ uncomment these
#       f.focus      <------
        f.deltastop
        f.raise
}

Button1 = : title|frame : f.function "move-or-raise"

So clicking on title or frame will focus on that window.

You could bind this to "window" as well, but then you can't use the click in
the application - this is the one limitation of twm/vtwm/etc implementation
using focus. To work around this, use a slightly different binding which uses
Alt (signified by the "m" below) as well.

Button1 = m : window : f.function "move-or-raise"

There may be other ways to do it which don't have the work around, perhaps
using f.unbindkeys or something, but I don't have time to play with it.
Perhaps moving f.deltastop to the top of the function and getting rid of the
f.move would do it. I would try this:

Function "move-or-raise2"
{
        f.deltastop
        f.unfocus
        f.focus
        f.raise
}

Button1 = : window : f.function "move-or-raise2"

However, I have not tested this to see if it works.  I'm not sure how other
window managers get around this problem of who processes an event. That's
some ideas to start with anyway for anyone who cares to try.

It would also be possible to bind Alt-Tab to cycle through the windows. This 
interacts weirdly with focus set, so unfortunately it's not as straightforward as

"Tab"         = m   : all                   : f.nexticonmgr

it appears to be necessary to define a function to unfocus the window first,
then call f.nexticonmgr (and then refocus), but that's just a guess - again I
haven't tested this, I just noted that f.nexticonmgr didn't work the same as
it normally does when I use it when I had click-to-focus enabled.

It probably would be worth adding a complete example vtwmrc using click-to-focus
to the contrib and/or web page (and name it "devil's focus model" or something... ;)

    C

On 30Oct23 13:33, Bruno Melo wrote:
> And how to emulate ClickToFocus behavior? I'm not aware about it.

-- 

    Callum Gibson

Re: [Vtwm-hackers] menus evaporate

[Michael R. <mc...@sa...>]

Callum Gibson <cal...@op...> wrote:
    > I agree it's not about dbus; it's about applications which assume a
    > click to focus model. I use focus follows mouse. The fact firefox has
    > a config option to alter the behaviour indicates it's a decision made
    > by toolkits to assume that everyone wants to use Windows or macOS.

I also use focus follow mouse, and frankly, I think it's the only true way to
use a windowing system.  (I think that the windows/mac choice is driven by
endless newbies.)

But, we are a very small minority: I think that we'll have to find a way to
compensate.   I would tolerate some kind of control that I could bind to a
key/mouse-chord that would either set/unset click-to-focus, toggle it, or
maybe just set it for 10 to 30 seconds.

Re: [Vtwm-hackers] menus evaporate

[Bruno M. <bm...@pr...>]

And how to emulate ClickToFocus behavior? I'm not aware about it.

Re: [Vtwm-hackers] menus evaporate

[Callum G. <cal...@op...>]

I agree it's not about dbus; it's about applications which assume a
click to focus model. I use focus follows mouse. The fact firefox has
a config option to alter the behaviour indicates it's a decision made
by toolkits to assume that everyone wants to use Windows or macOS.

Click to focus is not the native focus-model of vtwm, but you can
configure it to operate like that with appropriate bindings. If you do, I
think those misbehaving menus will work without any patching or additional
enhancement required.

    C

On 29Oct23 03:47, Bruno Melo via Vtwm-hackers wrote:
> About the menus evaporating the conclusion was not accurate.
> 
> Yes, this is a vtwm issue. Why am I sure about it? Because ctwm has the
> same issue. "So, this is not a vtwm issue". Yes, it is since ctwm works
> perfectly if you set ClickToFocus in .ctwmrc. So, this is a problem with
> vtwm focus. It's not about dbus, it's about focus. I dont see this issue in
> ctwm with dbus disabled like my NetBSD box.
> 
> Maybe vtwm can import ClickToFocus from ctwm to fix this. Steam menus are
> completely unusable, except in ctwm with ClickToFocus enabled.
> 
> Thanks.
> 
> 
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> 
> _______________________________________________
> Vtwm-hackers mailing list
> Vtw...@li...
> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers

-- 

    Callum Gibson

Re: [Vtwm-hackers] menus evaporate

[Bruno M. <bm...@pr...>]

About the menus evaporating the conclusion was not accurate.

Yes, this is a vtwm issue. Why am I sure about it? Because ctwm has the same issue. "So, this is not a vtwm issue". Yes, it is since ctwm works perfectly if you set ClickToFocus in .ctwmrc. So, this is a problem with vtwm focus. It's not about dbus, it's about focus. I dont see this issue in ctwm with dbus disabled like my NetBSD box.

Maybe vtwm can import ClickToFocus from ctwm to fix this. Steam menus are completely unusable, except in ctwm with ClickToFocus enabled.

Thanks.



Sent from ProtonMail, Swiss-based encrypted email.

Re: [Vtwm-hackers] menus evaporate

[Kevin Vincent-S. {C. P. C. <ke...@jo...>]

On Fri, 20 Oct 2023, Kevin Vincent-Sheehan {Consulting Poster Child} wrote:

>>> >  For me, using ubuntu and vtwm, setting widget.gtk.grab-pointer = 1 (not 
>>> >  0 , not 2) is what is needed for menus not to close/disappear upon 
>>> >  mouse1.release + mouse1.movement.

Thanks to Callum for enlightenment, I changed the Firefox setting, and it 
works a treat for firefox.

I still have to use the same workarounds RR posted earlier for things like
Zoom (cursor keys), but this is a big step forward.

ta muchly.

Re: [Vtwm-hackers] menus evaporate

[Kevin Vincent-S. {C. P. C. <ke...@jo...>]

way cool - thanks!

I tried running various dbus thingies, e.g.:

> # dbus-daemon --session &

but didn't work.

I seem to recall there being a gtk command to set this stuff.

Pardon my ignorance, I just turned a year older and forgot what the command was.

will give a try and report on 20.04.  If this works, I'll be moving from the 
horrible stuff in 22.04 on my laptop back to vtwm.

(wayland (now default) vs. Xorg makes that interesting.)

On Tue, 17 Oct 2023, Callum Gibson wrote:

> Oh wow, yes setting that to 1 fixes it.
>
> Thanks for the detective work.
>
>    C
>
> On 17Oct23 02:10, Fungilife can be eternal via Vtwm-hackers wrote:
>> Is dbus and dbus/user both running in your system?  I was under the perception the problem
>> comes from lack of proper dbus plumbing.  Although it is installed in my system I choose to not 
>> let it run unnecesseraly, and for browsing I think it needs not to run.
>> 
>> Not exactly a vtwm issue, it happens with openbox and jwm as well, and it appears some issues
>> of ff and sometimes its forks are affected.  In particular I like to use librewolf as a
>> cleaner ff and one edition (I think it was either 113/114) had the problem it was cured
>> by next release and never came back.  Also installing any addons even from local file without
>> dbus now fails.  Chrome forks may be ok for playing around/watching vids, but I don't trust
>> them with anything serious I'd have to login to.
>> 
>> > For reference, this how I now get around the "menu evaporates" bug in firefox 118.0.2 with vtwm:
>> > 
>> > For me, using ubuntu and vtwm, setting widget.gtk.grab-pointer = 1 (not 0 , not 2) is what is needed for menus not to close/disappear upon mouse1.release + mouse1.movement.
>> > 
>> > Longer version posted in
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1820542
>> > 
>> > (In reply to cervino from comment #47)
>> > 
>> > > Thanks for reporting / working on this bug! I am using openSUSE 15.4 / fvwm 2.6.9 (focus does not follow pointer) / Firefox 112.0.2. Navigating through my bookmark hierarchy was painful during the last few months. Setting widget.gtk.grab-pointer to 0 re-established the usual behavior of the Firefox menus.
>> > 
>> > Hmm, that is not what works for me with vtwm. For me, using ubuntu and vtwm, setting widget.gtk.grab-pointer = 1 (not 0 , not 2) is what is needed for menus not to close/disappear upon mouse1.release + mouse1.movement.
>> > 
>> > I just upgraded firefox from 109.0.1 to 118.0.2. For version 118.0.2, the bug is still there with vtwm when widget.gtk.grab-pointer = 0 or 2. In comment 43 and 46 it is indicated that there was a fix in 114.0a1. How is the fix then seemingly not in 118.0.2 ?
>> > 
>> > 
>> > 
>> > 
>> > 
>> > On Thu, Mar 9, 2023 at 6:41?AM Reik Reid <re...@gm...> wrote:
>> > 
>> > > Just a short report on how various suggested workarounds behave for me.
>> > > 
>> > > Workarounds I have tested (nothing works perfectly):
>> > > 
>> > > a. Hold mouse1 down and do not release until reaching desired menu item. May need to click again on the desired menu item.
>> > > 
>> > > This method cannot be applied to the list-all-tabs pulldown: Using mouse-scroll wheel does not work.
>> > > 
>> > > b. Hold mouse down and use cursor and tab keys, to cycle through menus. Then hit enter/return key to operate on the menu.
>> > > 
>> > > c. TRANSIENT FIX: Select rootwindow.mouse1.windowops.FOCUS, and then click on any xterm. After this, the next firefox window you use will work normally wrt. the menu problem. Have to repeat the focus operation for each firefox instance (if you run more than one instance/profile). Seems to lose the effect after some moving between firefox instances.
>> > > 
>> > > Failures:
>> > > 
>> > > a. about:config value ui.key.menuAccessKeyFocuses. Just something that caught my eye, not sure if it is relevant. Changing the value does not seem to help?
>> > > 
>> 
>> 
>> _______________________________________________
>> Vtwm-hackers mailing list
>> Vtw...@li...
>> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers
>
> -- 
>
>    Callum Gibson
>
>
>
> _______________________________________________
> Vtwm-hackers mailing list
> Vtw...@li...
> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers

Re: [Vtwm-hackers] menus evaporate

[Callum G. <cal...@op...>]

Oh wow, yes setting that to 1 fixes it.

Thanks for the detective work.

    C

On 17Oct23 02:10, Fungilife can be eternal via Vtwm-hackers wrote:
> Is dbus and dbus/user both running in your system?  I was under the perception the problem
> comes from lack of proper dbus plumbing.  Although it is installed in my system I choose to not 
> let it run unnecesseraly, and for browsing I think it needs not to run.
> 
> Not exactly a vtwm issue, it happens with openbox and jwm as well, and it appears some issues
> of ff and sometimes its forks are affected.  In particular I like to use librewolf as a
> cleaner ff and one edition (I think it was either 113/114) had the problem it was cured
> by next release and never came back.  Also installing any addons even from local file without
> dbus now fails.  Chrome forks may be ok for playing around/watching vids, but I don't trust
> them with anything serious I'd have to login to.
> 
> > For reference, this how I now get around the "menu evaporates" bug in firefox 118.0.2 with vtwm:
> > 
> > For me, using ubuntu and vtwm, setting widget.gtk.grab-pointer = 1 (not 0 , not 2) is what is needed for menus not to close/disappear upon mouse1.release + mouse1.movement.
> > 
> > Longer version posted in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1820542
> > 
> > (In reply to cervino from comment #47)
> > 
> > > Thanks for reporting / working on this bug! I am using openSUSE 15.4 / fvwm 2.6.9 (focus does not follow pointer) / Firefox 112.0.2. Navigating through my bookmark hierarchy was painful during the last few months. Setting widget.gtk.grab-pointer to 0 re-established the usual behavior of the Firefox menus.
> > 
> > Hmm, that is not what works for me with vtwm. For me, using ubuntu and vtwm, setting widget.gtk.grab-pointer = 1 (not 0 , not 2) is what is needed for menus not to close/disappear upon mouse1.release + mouse1.movement.
> > 
> > I just upgraded firefox from 109.0.1 to 118.0.2. For version 118.0.2, the bug is still there with vtwm when widget.gtk.grab-pointer = 0 or 2. In comment 43 and 46 it is indicated that there was a fix in 114.0a1. How is the fix then seemingly not in 118.0.2 ?
> > 
> > 
> > 
> > 
> > 
> > On Thu, Mar 9, 2023 at 6:41 AM Reik Reid <re...@gm...> wrote:
> > 
> > > Just a short report on how various suggested workarounds behave for me.
> > > 
> > > Workarounds I have tested (nothing works perfectly):
> > > 
> > > a. Hold mouse1 down and do not release until reaching desired menu item. May need to click again on the desired menu item.
> > > 
> > > This method cannot be applied to the list-all-tabs pulldown: Using mouse-scroll wheel does not work.
> > > 
> > > b. Hold mouse down and use cursor and tab keys, to cycle through menus. Then hit enter/return key to operate on the menu.
> > > 
> > > c. TRANSIENT FIX: Select rootwindow.mouse1.windowops.FOCUS, and then click on any xterm. After this, the next firefox window you use will work normally wrt. the menu problem. Have to repeat the focus operation for each firefox instance (if you run more than one instance/profile). Seems to lose the effect after some moving between firefox instances.
> > > 
> > > Failures:
> > > 
> > > a. about:config value ui.key.menuAccessKeyFocuses. Just something that caught my eye, not sure if it is relevant. Changing the value does not seem to help?
> > > 
> 
> 
> _______________________________________________
> Vtwm-hackers mailing list
> Vtw...@li...
> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers

-- 

    Callum Gibson

Re: [Vtwm-hackers] menus evaporate

[Fungilife c. be e. <fun...@pr...>]

Is dbus and dbus/user both running in your system?  I was under the perception the problem
comes from lack of proper dbus plumbing.  Although it is installed in my system I choose to not 
let it run unnecesseraly, and for browsing I think it needs not to run.

Not exactly a vtwm issue, it happens with openbox and jwm as well, and it appears some issues
of ff and sometimes its forks are affected.  In particular I like to use librewolf as a
cleaner ff and one edition (I think it was either 113/114) had the problem it was cured
by next release and never came back.  Also installing any addons even from local file without
dbus now fails.  Chrome forks may be ok for playing around/watching vids, but I don't trust
them with anything serious I'd have to login to.

> For reference, this how I now get around the "menu evaporates" bug in firefox 118.0.2 with vtwm:
> 
> For me, using ubuntu and vtwm, setting widget.gtk.grab-pointer = 1 (not 0 , not 2) is what is needed for menus not to close/disappear upon mouse1.release + mouse1.movement.
> 
> Longer version posted in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1820542
> 
> (In reply to cervino from comment #47)
> 
> > Thanks for reporting / working on this bug! I am using openSUSE 15.4 / fvwm 2.6.9 (focus does not follow pointer) / Firefox 112.0.2. Navigating through my bookmark hierarchy was painful during the last few months. Setting widget.gtk.grab-pointer to 0 re-established the usual behavior of the Firefox menus.
> 
> Hmm, that is not what works for me with vtwm. For me, using ubuntu and vtwm, setting widget.gtk.grab-pointer = 1 (not 0 , not 2) is what is needed for menus not to close/disappear upon mouse1.release + mouse1.movement.
> 
> I just upgraded firefox from 109.0.1 to 118.0.2. For version 118.0.2, the bug is still there with vtwm when widget.gtk.grab-pointer = 0 or 2. In comment 43 and 46 it is indicated that there was a fix in 114.0a1. How is the fix then seemingly not in 118.0.2 ?
> 
> 
> 
> 
> 
> On Thu, Mar 9, 2023 at 6:41 AM Reik Reid <re...@gm...> wrote:
> 
> > Just a short report on how various suggested workarounds behave for me.
> > 
> > Workarounds I have tested (nothing works perfectly):
> > 
> > a. Hold mouse1 down and do not release until reaching desired menu item. May need to click again on the desired menu item.
> > 
> > This method cannot be applied to the list-all-tabs pulldown: Using mouse-scroll wheel does not work.
> > 
> > b. Hold mouse down and use cursor and tab keys, to cycle through menus. Then hit enter/return key to operate on the menu.
> > 
> > c. TRANSIENT FIX: Select rootwindow.mouse1.windowops.FOCUS, and then click on any xterm. After this, the next firefox window you use will work normally wrt. the menu problem. Have to repeat the focus operation for each firefox instance (if you run more than one instance/profile). Seems to lose the effect after some moving between firefox instances.
> > 
> > Failures:
> > 
> > a. about:config value ui.key.menuAccessKeyFocuses. Just something that caught my eye, not sure if it is relevant. Changing the value does not seem to help?
> > 

Re: [Vtwm-hackers] menus evaporate

[Kevin Vincent-S. {C. P. C. <ke...@jo...>]

I kinda wondered about the lack of reply.  Was looking at my old Gmail account 
and....

It's ke...@jo... now.  I've forwarded this to reply from there, as I've
learned some things too.


On Tue, 7 Mar 2023, Callum Gibson wrote:

> Date: Tue, 7 Mar 2023 07:25:06 +1100
> From: Callum Gibson <cal...@op...>
> To: vtw...@li...
> Subject: Re: [Vtwm-hackers] menus evaporate
> 
> Yes I see what you mean. It didn't happen with 106. I've seen this previously
> for quite a while with libreoffice though. I've also seen it previously
> with firefox with the "Allow notifications" etc popups.
>
> I guess it's something to do with focus. I use focus follows mouse but
> increasingly software is written assuming the Windows or Mac model of
> click to focus (yuck). With the firefox popups I could always work around it
> by setting focus to the firefox window. This also works with the menus
> issue; interestingly it doesn't matter which firefox window (or any window)
> you set the focus to, and the menus will work properly.
>
>    C
>
>
> On 07Mar23 07:08, Callum Gibson wrote:
>> Hmm, I've just upgraded and about to reboot and pick up a FF 110. Let's see
>> what happens.
>>
>>     C
>> 
>> On 06Mar23 11:22, Reik Reid wrote:
>> > I have observed the same problem with firefox-110.0.1. It does not occur
>> > with firefox-103.2.
>> > 
>> > Something has changed. So far, firefox is the only program that I have
>> > observed exhibiting this problem with menus disappearing upon mouse motion.
>> > 
>> > RR
>> > 
>> > System environment:
>> > ubuntu-22.04.1
>> > vtwm/jammy,now 5.4.7-7 amd64 [installed]
>> > 
>> > 
>> > On Sun, Feb 19, 2023 at 12:09?AM Ian! D. Allen <id...@id...> wrote:
>> > 
>> > > Ubuntu 20.04.5 LTS running vtwm 5.5.0 and Firefox 109.0.1
>> > >
>> > > On Wed, Feb 15, 2023 at 02:51:26AM -0500, Kevin Vincent-Sheehan wrote:
>> > > > Now when I click on a menu, the menu pops up, but when I try to
>> > > > move onto it, it disappears.
>> > >
>> > > I have this problem in Zoom (5.13.7.683) but not Firefox.
>> > >
>> > > In Zoom, if I click and open the top left icon menu and hover the mouse
>> > > over, for example, "Do Not Disturb", it shows a menu of times on the
>> > > right.  When I move the mouse to the right to try to click on a time
>> > > in that other menu list, both menus vanish as soon as the mouse leaves
>> > > the first menu.  The first menu always closes when the mouse leaves it,
>> > > taking both menus down.
>> > >
>> > > If I click down on "Do Not Disturb" (using any of the three mouse
>> > > buttons), and hold the click, I can move the mouse off the first menu
>> > > onto the right menu, release, and neither menu disappears, and I can
>> > > select any item in that menu.
>> > >
>> > > In Dec 2021 I had a problem with image title hover text that
>> > > would disappear in Firefox and messing with vtwm NoTitle fixed
>> > > that.  (That fix doesn't appear to be necessary today.)  See
>> > > vtw...@li... thread "image title text vanishes
>> > > under VTWM" Dec 23-29 2021.
>> > >
>> > > --
>> > > | Ian! D. Allen, BA-Psych, MMath-CompSci  id...@id... Ottawa CANADA
>> > > | Home: www.idallen.com  Contact Improvisation Dance: www.contactimprov.ca
>> > > | Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com
>> > > | Improve democracy www.fairvote.ca and defend digital freedom www.eff.org
>> > >
>> > >
>> > > _______________________________________________
>> > > Vtwm-hackers mailing list
>> > > Vtw...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/vtwm-hackers
>> > >
>> 
>> 
>> > _______________________________________________
>> > Vtwm-hackers mailing list
>> > Vtw...@li...
>> > https://lists.sourceforge.net/lists/listinfo/vtwm-hackers
>> 
>> 
>> -- 
>>
>>     Callum Gibson
>> 
>> 
>> 
>> _______________________________________________
>> Vtwm-hackers mailing list
>> Vtw...@li...
>> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers
>
> -- 
>
>    Callum Gibson
>
>
>
> _______________________________________________
> Vtwm-hackers mailing list
> Vtw...@li...
> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers

Re: [Vtwm-hackers] menus evaporate

[Michael R. <mc...@sa...>]

Kevin Vincent-Sheehan {Consulting Poster Child} <ke...@jo...> wrote:
    > Also, "zoom" does this strange thing where it sizes as though chat was
    > on the right side (big, but no chat there).  That went away and I get a
    > smaller window with no blank space.

I strongly suggest not running the zoom "native" malware... ever.
The webrtc version works 99% of the time.

Re: [Vtwm-hackers] menus evaporate

[Kevin Vincent-S. {C. P. C. <ke...@jo...>]

Not sure what happened, but I had to re-plug my USB earphones.

For about 15 minutes, focus followed mouse (I didn't have to hold down
the mouse key to get thru menus).

Also, "zoom" does this strange thing where it sizes as though chat was
on the right side (big, but no chat there).  That went away and I get
a smaller window with no blank space.

So, there was something running that changed behavior, but it went away.
should have done "ps" :-)

Re: [Vtwm-hackers] menus evaporate

[Michael R. <mc...@sa...>]

Fungilife can be eternal via Vtwm-hackers wrote:
    > Another fix for firefox is to use librewolf instead, everything seems
    > to work and it is as good as palemoon or waterfox were in the early
    > days, without the mozilla spytools (telemetry/autoupdates...)

I guess it's not apt-get'able on default devuan, so I'll have to google how
to install it.

Re: [Vtwm-hackers] menus evaporate

[Michael R. <mc...@sa...>]

I'm also running dbus.  I do this by starting gnome-session in my .xsession,
I think, so I also have a dock bar at the top.  I wish I could find a way to
Nail it in all workspaces from .vtwmrc.  I reboot so seldom, having to click
once on it, isn't a burden :-)

Re: [Vtwm-hackers] menus evaporate

[Fungilife c. be e. <fun...@pr...>]

Another fix for firefox is to use librewolf instead, everything seems to work and it is as good as palemoon or waterfox were in the early days, without the mozilla spytools (telemetry/autoupdates...) 

Librewolf is made out of the late firefox code not from an old "legacy" version, 110.0 to be specific.

Re: [Vtwm-hackers] menus evaporate

[Kevin Vincent-S. {C. P. C. <ke...@jo...>]

On Tue, 7 Mar 2023, Callum Gibson wrote:

> I'm running dbus, so it seems not related to dbus in this instance.

I tried "dbus-daemon --session" suggested by one of the xfce folks once upon
a time and that never made a difference.

Still need to sort this solution out a bit.  I did "focus" from window ops, 
then moved my virtual screen (with Alt-Up) to where firefox lives.

firefox menu popped up and stayed up.  Celebratory muffin and coffee was 
consumed.

moved virtual screen back down to the where the xterm with alpine is, and
now I can' get focus to move to other xterms following the mouse, I have
to use the window ops/focus.

better, still not there yet.  And for the record, the other WM that are not 
Gnome often report similar problems.


>
>    C
>
> On 07Mar23 00:15, Fungilife can be eternal wrote:
>>
>>> Yes I see what you mean. It didn't happen with 106. I've seen this previously
>>> for quite a while with libreoffice though. I've also seen it previously
>>> with firefox with the "Allow notifications" etc popups.
>>
>> I remember something similar happening in the past with liboff and it was due
>> to not running dbus on the system.  Don't ask me how dbus relates to menus, I
>> would't have a clue.  with other mozilla forks the problem never materialized
>> but if you can worry about dbus/gdbus errors/warnings output on terminal
>> you can try firefox --no-dbus.
>>
>> Do you think this issue relates to vtwm for some reason, and the behavior
>> described is not experienced in other WMs?
>>
>
> -- 
>
>    Callum Gibson
>
>
>
> _______________________________________________
> Vtwm-hackers mailing list
> Vtw...@li...
> https://lists.sourceforge.net/lists/listinfo/vtwm-hackers
>