Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Question about Focus in fvwm2

147 views
Skip to first unread message

root

unread,
Mar 25, 2017, 1:03:59 PM3/25/17
to
A couple of months ago I decided to move up to a more modern
window manager from the fvwm95 I had been using since sometime
around 1991. It took a while to make fvwm2 function in a
manner similar to what was familiar to me.

Except for browsing with Chrome, all my use of X involves
launching a keyboard application under an Xterm. This
application serves like a menu by which I can invoke other
keyboard applications which when finished return to the menu.

For example, the menu application might display a list of
movies which can be selected by up/down and pressing enter
to invoke mplayer. When mplayer finishes control is returned
to the menu application.

The focus problem comes up with what happens when control
is passed from the menu. Under fvwm95 keyboard control
is passed to the application selected by the menu regardless
of where the mouse cursor is. Under fvwm2, keyboard control
is not passed to the application unless the mouse cursor is
within the window brought up by the application. This means
that if I press any key before the mouse cursor is positioned
that key gets sent to the menu application instead of the
intended program.

One menu consists of a list of pdf articles. If I bring
up Okular to view an article and press page down when
Okular is showing the article the page down will go
back to the menu application instead of to Okular
unless I put the mouse cursor into the Okular window.
This causes me to lose my place in the list of articles.

I have tried the different Focus options with fvwm2, but
none seem to produce the desired result.

If I have described my problem sufficiently well to
spark a suggestion from can you let me know?

Thanks.

Rich

unread,
Mar 25, 2017, 3:43:51 PM3/25/17
to
root <NoE...@home.org> wrote:
> ...
> Except for browsing with Chrome, all my use of X involves
> launching a keyboard application under an Xterm. This
> application serves like a menu by which I can invoke other
> keyboard applications which when finished return to the menu.
>
> For example, the menu application might display a list of
> movies which can be selected by up/down and pressing enter
> to invoke mplayer. When mplayer finishes control is returned
> to the menu application.
>
> The focus problem comes up with what happens when control
> is passed from the menu. Under fvwm95 keyboard control
> is passed to the application selected by the menu regardless
> of where the mouse cursor is. Under fvwm2, keyboard control
> is not passed to the application unless the mouse cursor is
> within the window brought up by the application. ...
>
> If I have described my problem sufficiently well to
> spark a suggestion from can you let me know?

My first thought is that you'd be best served by learning how to use
fvwm2's ability to generate dynamic menus from scripts to replace your
console menu app. with fvwm2 menus, then you can easily use fvwm2's
focus and mouse warp commands to move focus and move the mouse cursor
to the various windows that appear.

But I surmise you'll likely want to stay with your console menu setup,
in which case you should investigate the 'FvwmCommand' command. If you
configure your fvwm2rc to launch the command server (see FvwmCommand
man page) then you can use the FvwmCommand command to send fvwm2 the
necessary instructions to move focus and move the mouse to the windows
that appear as a result of your console menu system having launched
something for you.

root

unread,
Mar 25, 2017, 5:38:09 PM3/25/17
to
Thanks for responding. My actual interest is more complex than my
example. I chose the example because it was easier to describe
the real situation. In fact, the menus and applications are
dynamic and there may be several such running in separate Xterms.
Although I referred to them as menus, in fact they are applications
or mini-oses in themselves. Picture a number of emacs instances
running in a number of xterms. The situation today my not resemble
that of tomorrow.

I developed most of the programs I use under a console. In each
case when a task is switched out it is to a child process that
maintains control until it terminates and control is passed back
to the parent. This behavior is maintained by fvwm95, but not
by fvwm2. For my interest, the mouse plays too dominant a role
in fvwm2.

Rich

unread,
Mar 25, 2017, 6:00:34 PM3/25/17
to
Your response implies that you did not read my response. It gave you
an option that would work with your existing menu setup provided you
can modify that existing setup to run Unix commands as part of its
operation (I did assume this menu setup was 'adjustable' by you, maybe
that was an incorrect assumption). Since those 'menus' as you call
them can launch other programs, this means they can run Unix commands.
Since they can run Unix commands, the FvwmCommand system can be used to
control the focus when one of them launches.

The reason why things worked the way you want with fvwm95 is that it is
very likely that because fvwm95 was trying to emulate windows95
behavior, that it also emulated the (in my opinion) awful windows focus
method of "whatever is on top gets keyboard focus, and whatever has
keyboard focus must be on top". Your new windows, when newly created,
would likely have been "on top" and so the awful windows focus system
would then have given them focus by default.

But if you were to read the fvwm2 man page (as I just did, although I
searched for mentions of "focus" rather than reading straight through)
you would have found these two fvwm2 style options mentioned therein:

New normal or transient windows with the FPGrabFocus or
FPGrabFocusTransient style automatically receive the focus when they
are created.

So, it looks like if you configure fvwm2 to apply the FPGrabFocus
and possibly FPGrabFocusTransient styles to the windows that appear
from your menu launcher, if the documentation describes the behavior
properly, you'll get your old fvwm95 behavior. When the windows
appear, they will get the focus.

root

unread,
Mar 26, 2017, 12:34:34 PM3/26/17
to
Rich <ri...@example.invalid> wrote:
>
> Your response implies that you did not read my response. It gave you
> an option that would work with your existing menu setup provided you
> can modify that existing setup to run Unix commands as part of its
> operation (I did assume this menu setup was 'adjustable' by you, maybe

Everything that is invoked is a Unix command of one sort or another.



> that was an incorrect assumption). Since those 'menus' as you call
> them can launch other programs, this means they can run Unix commands.
> Since they can run Unix commands, the FvwmCommand system can be used to
> control the focus when one of them launches.
>
> The reason why things worked the way you want with fvwm95 is that it is
> very likely that because fvwm95 was trying to emulate windows95
> behavior, that it also emulated the (in my opinion) awful windows focus
> method of "whatever is on top gets keyboard focus, and whatever has
> keyboard focus must be on top". Your new windows, when newly created,
> would likely have been "on top" and so the awful windows focus system
> would then have given them focus by default.
>
> But if you were to read the fvwm2 man page (as I just did, although I

The man page is 9,031 lines.

> searched for mentions of "focus" rather than reading straight through)
> you would have found these two fvwm2 style options mentioned therein:
>
> New normal or transient windows with the FPGrabFocus or
> FPGrabFocusTransient style automatically receive the focus when they
> are created.

I do see these in a block of instructions having to do with styles.
Then I look in the styles file of .fvwm and that has to do with setting
a style for individual applications. I need a global style setting.

>
> So, it looks like if you configure fvwm2 to apply the FPGrabFocus
> and possibly FPGrabFocusTransient styles to the windows that appear
> from your menu launcher, if the documentation describes the behavior
> properly, you'll get your old fvwm95 behavior. When the windows
> appear, they will get the focus.

Apart from the man page, I can't find FPGrabFocus anywhere in the
files in the .fvwm directory or in the files of usr/share/fvwm

The question is addressed here:
http://fvwmforums.org/phpBB3/viewtopic.php?t=2949

but they don't mention how to assert FPGrabFocus.

I added this line to ConfigFvwmDefaults:
Style * FPGrabFocus FPGrabFocusTransient

under default styles.

And that did not fix the problem. When I pull up an application
with the mouse cursor outside the new window, the keyboard does
not go to the new application.

I appreciate the effort you have gone through to help me.


>

Rich

unread,
Mar 26, 2017, 1:40:17 PM3/26/17
to
root <NoE...@home.org> wrote:
> Rich <ri...@example.invalid> wrote:
>> But if you were to read the fvwm2 man page (as I just did, although I
>
> The man page is 9,031 lines.

How is that relevant, unless you stop reading before the entire
sentence is finished, you overlooked this critical bit of context:
'although I searched for mentions of "focus"'.

>> searched for mentions of "focus" rather than reading straight through)
>> you would have found these two fvwm2 style options mentioned therein:
>>
>> New normal or transient windows with the FPGrabFocus or
>> FPGrabFocusTransient style automatically receive the focus when they
>> are created.
>
> I do see these in a block of instructions having to do with styles.
> Then I look in the styles file of .fvwm and that has to do with setting
> a style for individual applications. I need a global style setting.

If you again bothered to do the research, you would next have
investigated the options for the "Style" command, where you would have
found this:

stylename can be a window's name, class, visible name, or resource
string. It may contain the wildcards '*' and '?', which are
matched in the usual Unix filename manner.

Which means using a style name of just * produces a global setting.

>> So, it looks like if you configure fvwm2 to apply the FPGrabFocus
>> and possibly FPGrabFocusTransient styles to the windows that appear
>> from your menu launcher, if the documentation describes the behavior
>> properly, you'll get your old fvwm95 behavior. When the windows
>> appear, they will get the focus.
>
> Apart from the man page, I can't find FPGrabFocus anywhere in the
> files in the .fvwm directory or in the files of usr/share/fvwm
>
> The question is addressed here:
> http://fvwmforums.org/phpBB3/viewtopic.php?t=2949
>
> but they don't mention how to assert FPGrabFocus.
>
> I added this line to ConfigFvwmDefaults:
> Style * FPGrabFocus FPGrabFocusTransient

Incorrect syntax, the 'list' is supposed to be comma separated:

Style * FPGrabFocus, FPGrabFocusTransient

The lack of a comma may have made fvwm2 ignore it. You do have your
fvwm2's stdout/stderr being redirected to a log file so you can see if
it complains about anything, right?

> And that did not fix the problem.

Did you restart fvwm2? Merely editing the config file does not change
anything unless you also restart fvwm2.

root

unread,
Mar 26, 2017, 2:51:26 PM3/26/17
to
Rich <ri...@example.invalid> wrote:
>> I added this line to ConfigFvwmDefaults:
>> Style * FPGrabFocus FPGrabFocusTransient
>
> Incorrect syntax, the 'list' is supposed to be comma separated:
>
> Style * FPGrabFocus, FPGrabFocusTransient
>
> The lack of a comma may have made fvwm2 ignore it. You do have your
> fvwm2's stdout/stderr being redirected to a log file so you can see if
> it complains about anything, right?
>
>> And that did not fix the problem.
>
> Did you restart fvwm2? Merely editing the config file does not change
> anything unless you also restart fvwm2.

Thanks again. I added the comma to the ConfigDefaults file:
# Default styles
Style * FPGrabFocus, FPGrabFocusTransient

I shut X down and restarted X and then fvwm2. There was no change
to the behavior. If the cursor is outside the window that is
brought up keyboard input still goes to the parent program.


For what it's worth, let me try to describe in more detail how valuable
this menu thing is to me. When I am sitting in an Xterm I can type
a command line something like this:
menu archive stochastic market

While the actual command is a little different, this is a good
example. This command goes to the online archive, searches
for papers having both stochastic and market in the title,
then downloads a list of these papers, which then appears
with each paper on a single line, with the first line
highlighted.

I can move the highlighted line up or down, and press enter
to cause the abstract or complete paper to be fetched from
the archive, and then (most often) Okular is started to display
the downloaded paper/abstract.

Then I use the page controls to page through the article
say PgUp/PgDn. Here is where the problem comes up. If the
mouse cursor is outside the Okular window Okular doesn't
see the PgDn key which is sent to the menu program
instead. However, I can move the mouse cursor over to the
Okular window and hit PgDn again and Okular responds. However
when I return to the menu program after closing Okular I
have lost my place in the list of documents.

I use the same concept to fetch data from online repositories
and then I use some other program to play with the data.

That same menu program drives everything I do. The menu program
creates commands that I can execute. These commands are as
general as I can make them. Everything is taken care of by
the menu program.

From time to time I have tried to interest usenet people in the
idea but I have been unable to convey the value.

Thanks again.

Rich

unread,
Mar 26, 2017, 4:13:10 PM3/26/17
to
root <NoE...@home.org> wrote:
> Rich <ri...@example.invalid> wrote:
>>> I added this line to ConfigFvwmDefaults:
>>> Style * FPGrabFocus FPGrabFocusTransient
>>
>> Incorrect syntax, the 'list' is supposed to be comma separated:
>>
>> Style * FPGrabFocus, FPGrabFocusTransient
>>
>> The lack of a comma may have made fvwm2 ignore it. You do have your
>> fvwm2's stdout/stderr being redirected to a log file so you can see if
>> it complains about anything, right?
>>
>>> And that did not fix the problem.
>>
>> Did you restart fvwm2? Merely editing the config file does not change
>> anything unless you also restart fvwm2.
>
> Thanks again. I added the comma to the ConfigDefaults file:
> # Default styles
> Style * FPGrabFocus, FPGrabFocusTransient
>
> I shut X down and restarted X and then fvwm2. There was no change
> to the behavior. If the cursor is outside the window that is
> brought up keyboard input still goes to the parent program.

And yet, if I send "Style * FPGrabFocus" to my running fvwm2 via
FvwmTalk, the setting works exactly as advertised in the documentation.
All newly opened windows (from an xterm) all get given keyboard focus
the moment they pop on screen.

Do you have another style setting elsewhere in your config file that
would conflict with these settings? Also, what version of fvwm2? I
have 2.6.5 here.

> For what it's worth, let me try to describe in more detail how valuable
> this menu thing is to me.

I understand. You have a whole system that works for you, and you'd
like it to integrate properly with the rest of the X setup so that it
continues to work for you. I don't discount the value of this setup.
I built an entire simulation (as closley as I could get it) of
QuarterDeck's DesqView's keyboard launching and focus selecting system
for myself in fvwm2 when I transitioned from a DOS machine to a Linux
machine at work. I still use a small fraction of it even now, although
much less than I used to.

If you can't get the "Style * FPGrabFocus" to work (and I don't
understand why it fails, unless you've got another overriding style
setting somewhere) then your check item to look into is the FvwmCommand
I pointed you to. That would let your menu system, after it launches
something, to remotely command fvwm2 to give the new window focus and
to even warp the mouse cursor to sit inside the window as well.

JohnF

unread,
Mar 26, 2017, 4:43:36 PM3/26/17
to
root <NoE...@home.org> wrote:
> A couple of months ago I decided to move up to a more modern
> window manager from the fvwm95 I had been using since sometime
> around 1991. It took a while to make fvwm2 function in a
> manner similar to what was familiar to me.

I made the fvwm95-->fvwm2 switch years ago, and found some
config stuff for it that really makes it fvwm95-like.
Sorry, I don't recall (and didn't document) the original site,
but download http://www.forkosh.com/fvwmtwo.zip and unzip
it in an .fvwm/ directory under your ~/ home directory
(and move any .fvwm2rc stuff you already have to some other place).
Then startx and see if you like the look-and-feel(-and-behavior).
(left-click mouse to bring up "root menu", which you can modify
to taste by editing the .fvwm/menus file in an obvious way by
viewing it)
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

root

unread,
Mar 26, 2017, 6:28:28 PM3/26/17
to
Rich <ri...@example.invalid> wrote:
>>
>> I shut X down and restarted X and then fvwm2. There was no change
>> to the behavior. If the cursor is outside the window that is
>> brought up keyboard input still goes to the parent program.
>
> And yet, if I send "Style * FPGrabFocus" to my running fvwm2 via
> FvwmTalk, the setting works exactly as advertised in the documentation.
> All newly opened windows (from an xterm) all get given keyboard focus
> the moment they pop on screen.

Ok, that does work. But if I touch the mouse and the mouse is outside
the window, the keyboard input goes away. For the record of anyone
following this thread other than the two of us: You go to the Module
entry in the pull down menu, and go to Talk to Fvwm. Then I had to do
some extra mouse moves to get the keyboard to go to the window that
came up.




>
> Do you have another style setting elsewhere in your config file that
> would conflict with these settings? Also, what version of fvwm2? I
> have 2.6.5 here.

While trying to solve this problem myself, I tried changing the Focus
option among the three things: sloppy, click, focus follows mouse. I think
the last thing I tried was the sloppy thing. I didn't change any other
config options.

I am running Slackware 14.2 64bit, and fvwm is 2.6.6

>
> If you can't get the "Style * FPGrabFocus" to work (and I don't
> understand why it fails, unless you've got another overriding style
> setting somewhere) then your check item to look into is the FvwmCommand
> I pointed you to. That would let your menu system, after it launches
> something, to remotely command fvwm2 to give the new window focus and
> to even warp the mouse cursor to sit inside the window as well.

Thanks for all your help. You couldn't have done more if you were the
author of fvwm2.

root

unread,
Mar 26, 2017, 6:38:10 PM3/26/17
to
JohnF <jo...@please.see.sig.for.email.com> wrote:
> root <NoE...@home.org> wrote:
>
> I made the fvwm95-->fvwm2 switch years ago, and found some
> config stuff for it that really makes it fvwm95-like.
> Sorry, I don't recall (and didn't document) the original site,
> but download http://www.forkosh.com/fvwmtwo.zip and unzip
> it in an .fvwm/ directory under your ~/ home directory
> (and move any .fvwm2rc stuff you already have to some other place).
> Then startx and see if you like the look-and-feel(-and-behavior).
> (left-click mouse to bring up "root menu", which you can modify
> to taste by editing the .fvwm/menus file in an obvious way by
> viewing it)
>

Thanks for the suggestion. I renamed my .fvwm to .FVWM, created
a new .fvwm, and unziped the file there. Upon starting
X and fvwm, the appearance was much like fvwm2 out of the box.
However, I couldn't bring up an xterm, nothing appeared on the
task bar at the bottom. Something was in the upper left corner
of the screen, but nothing responded to any keyboard input.

I am coming to believe that mouse behavior in fvwm2 is so
fundamentally different from fvwm95 that I cannot achieve what
I need.
>

Rich

unread,
Mar 26, 2017, 6:45:09 PM3/26/17
to
root <NoE...@home.org> wrote:
> Rich <ri...@example.invalid> wrote:
>>>
>>> I shut X down and restarted X and then fvwm2. There was no change
>>> to the behavior. If the cursor is outside the window that is
>>> brought up keyboard input still goes to the parent program.
>>
>> And yet, if I send "Style * FPGrabFocus" to my running fvwm2 via
>> FvwmTalk, the setting works exactly as advertised in the documentation.
>> All newly opened windows (from an xterm) all get given keyboard focus
>> the moment they pop on screen.
>
> Ok, that does work. But if I touch the mouse and the mouse is outside
> the window, the keyboard input goes away.

Below you mention you've got sloppy focus turned on. You'll get this
exact effect if you have sloppy focus on while using FPGrabFocus.
Moving the mouse will give focus to another window underneath the mouse
cursor. That is because only focus changes with FPGrabFocus, the mouse
position does not move.

You'll likely be happier with "click" focus (which requires you
actually click the mouse on the window to give it focus) if you don't
want a slight mouse move to change the focus for you.

>> Do you have another style setting elsewhere in your config file that
>> would conflict with these settings? Also, what version of fvwm2? I
>> have 2.6.5 here.
>
> While trying to solve this problem myself, I tried changing the Focus
> option among the three things: sloppy, click, focus follows mouse. I think
> the last thing I tried was the sloppy thing. I didn't change any other
> config options.
>
> I am running Slackware 14.2 64bit, and fvwm is 2.6.6

>> If you can't get the "Style * FPGrabFocus" to work (and I don't
>> understand why it fails, unless you've got another overriding style
>> setting somewhere) then your check item to look into is the FvwmCommand
>> I pointed you to. That would let your menu system, after it launches
>> something, to remotely command fvwm2 to give the new window focus and
>> to even warp the mouse cursor to sit inside the window as well.

The "FvwmCommand" method, where your menu scripts remotely control
fvwm2, would let you not only move focus but also move the mouse
pointer so it is sitting inside the new window, at which point small
movements of the mouse would not change keyboard focus at all (unless
the small movement moved the pointer outside of the window and you had
one of the "follows mouse" focus styles setup).

> Thanks for all your help. You couldn't have done more if you were the
> author of fvwm2.

You are welcome.

JohnF

unread,
Mar 26, 2017, 8:55:20 PM3/26/17
to
Sorry to hear it's not working quite right for you.
I left-click anywhere (rather than on the "Start" button that
comes up in the lower-left corner), and then click "Terminal"
at the top of the "Root Menu" that appeared wherever I first
clicked. That runs /usr/bin/terminal which is symlinked to
konsole. And that works fine. You can edit that .fvwm2/menus
file to run whatever you want. But if you don't like the
look-and-feel, it's probably not worth the bother.

root

unread,
Mar 26, 2017, 10:36:39 PM3/26/17
to
Thanks for responding. When I first turned my attention to fvwm2
it took me a long time, weeks, to learn how to configure fvwm2 to
look exactly like my version of fvwm95. My wife and members of
alt.os.linux.slackware were very helpful. The suggestions made
by Rich bring fvwm2 as close as possible to the mouse behavior
of fvwm95 as I can expect.

I have several friends using my menu/program system and I will
offer them the fvwm2 alternative.
0 new messages