FVWM: a problem in windows focus

[source liu]

Hi,
I've recently picked up the pace of fvwm2, (v2.6), and i enjoy the
style of fvwm
style in getting the focus of windows by mouseover, except for i'm setting up
my cedet for emacs. before i'm into fvwm, i used KDE, whose method is
ClicktoFocus by default.

In the ClicktoFocus case, when my trying to call the *speedbar*, which
would generate
a window companied by the opened emacs window, and auto get focus.
after key stroke, the *speedbar* lost it focus by default, (without close it).
thus, one can call it back and forth, whenever need.

But the case is different as the focus method changes, still i can
call up the *speedbar*
by key stroke, but it would no longer get focus as soon as it came
out. (as i should keep the mouse
in the region of emacs to keep emacs to hold focus). so every time i
have to move my cursor
to get the focus of the speed bar, and after i finished the stroke,
the emacs again didnt caught
focus.

The problem remains when multiple windowed application such as *Gimp*
is launched, but it never
come to so critical as mouse is widely used in them. I've enjoyed so
much in keeping my hand free of
mouse when editor text with emacs.

I would not change back to the way ClicktoFocus, as i'm lovin it, is
there any way or suggestions to drive
away the problem bother me in which i mentioned above to get rid of
moving the mouse back and forth... back
and forth.

I hope i've described my dilemma clear enough for you to understand,


FYI

B/R

Sincerely

[Thomas Adam]

But the case is different as the focus method changes,  still i can
call up the *speedbar*
by key stroke, but it would no longer get focus as soon as it came
out. (as i should keep the mouse
in the region of emacs to keep emacs to hold focus).  so every time i
have to move my cursor
to get the focus of the speed bar, and after i finished the stroke,
the emacs again didnt caught
focus.

Have you changed focus policies in FVWM? Because I suspect a whole
lot more given the changes in Emacs that I've seen, that they've
decided to do something which changes how this used to work, or more
likely, it's a subtle issue with GTK3.

The problem remains when multiple windowed application such as *Gimp*
is launched, but it never
come to so critical as mouse is widely used in them.  I've enjoyed so
much in keeping my hand free of
mouse when editor text with emacs.

Oh look. Another GTK program.

I would not change back to the way ClicktoFocus, as i'm lovin it,  is
there any way or suggestions to drive
away the problem bother me in which i mentioned above to get rid of
moving the mouse back and forth... back
and forth.

Well, applications can decide for themselves which windows to focus.
And I suspect that's exactly what was happening before. Certainly
there's nothing inherent in the way FVWM is handling window focus
which would cause the symptoms you're describing. It could more
likely be that the windows you're describing, such as the speedbar,
are no longer transient. This would explain the behaviour you're
seeing almost.

There is no way though to know why focus was stolen, although if you
wanted to run:

xprop -spy -d $FOO

Where $FOO represents the windowid of the speedbar, then let the focus
change, I might be able to gleam something.

But I am not yet in a position to think this is FVWM's fault.

-- Thomas Adam

[source liu]

But the case is different as the focus method changes,  still i can
call up the *speedbar*
by key stroke, but it would no longer get focus as soon as it came
out. (as i should keep the mouse
in the region of emacs to keep emacs to hold focus).  so every time i
have to move my cursor
to get the focus of the speed bar, and after i finished the stroke,
the emacs again didnt caught
focus.

Have you changed focus policies in FVWM?  Because I suspect a whole
lot more given the changes in Emacs that I've seen, that they've
decided to do something which changes how this used to work, or more
likely, it's a subtle issue with GTK3.

Hey, i cant tell exactly policies i'm using, i configured my fvwm up
following Knuth's way
(http://www-cs-faculty.stanford.edu/~uno/programs.html ), i though it
might be Sloppy.

The problem remains when multiple windowed application such as *Gimp*
is launched, but it never
come to so critical as mouse is widely used in them.  I've enjoyed so
much in keeping my hand free of
mouse when editor text with emacs.

Oh look.  Another GTK program.

yes, indeed, i'm using chromium, and i find --geometry parameter is
suppressed. but the conflict never came out before i embrace FVWM(
before that, i never try to place a window as my wish when it
initiate).

I would not change back to the way ClicktoFocus, as i'm lovin it,  is
there any way or suggestions to drive
away the problem bother me in which i mentioned above to get rid of
moving the mouse back and forth... back
and forth.

Well, applications can decide for themselves which windows to focus.
And I suspect that's exactly what was happening before.   Certainly
there's nothing inherent in the way FVWM is handling window focus
which would cause the symptoms you're describing.

do you mean, FVWM is a *wm*, and it treat window as window, rather
than looked into the group how there were organized, or in another word
it's our responsibility to tell her *do it in that way*?

It could more likely be that the windows you're describing,
such as the speedbar,
are no longer transient.  This would explain the behaviour you're
seeing almost.
There is no way though to know why focus was stolen, although if you
xprop -spy -d $FOO
Where $FOO represents the windowid of the speedbar, then let the focus
change, I might be able to gleam something.
But I am not yet in a position to think this is FVWM's fault.

I couldnt agree more !
The combine of several application make things complex.


A lot of information, though a little hard for me to understand
all behaviors.

Thanks so much for you attention.

-- Thomas Adam

[Jaimos Skriletz]

Post by source liu
Hey, i cant tell exactly policies i'm using, i configured my fvwm up
following Knuth's way
(http://www-cs-faculty.stanford.edu/~uno/programs.html ), i though it
might be Sloppy.

Searching through Knuth's fvwm2rc for the word 'Focus' I see the following.

He uses FocusFollowsMouse as his default focus policy.

For XTerm and Emacs he uses SloppyFocus and for XOsview he uses ClickToFocus.

So from his config the focus policy is dependent on the actual window (which can be useful in certain circumstances).

jaimos

[source liu]

On Thu, Nov 3, 2011 at 11:59 AM, Jaimos Skriletz

Post by Jaimos Skriletz

Hey, i cant tell exactly policies i'm using,  i configured my fvwm up
following Knuth's way
(http://www-cs-faculty.stanford.edu/~uno/programs.html ),  i though it
might be Sloppy.

Searching through Knuth's fvwm2rc for the word 'Focus' I see the following.
He uses FocusFollowsMouse as his default focus policy.
For XTerm and Emacs he uses SloppyFocus and for XOsview he uses ClickToFocus.

I see, then my emacs must be SloppyFocus, same as his, and still have the
problem i mentioned at the beginning.

maybe i should change the method to ClicktoFocus in Emacs Style.

I'll post my feedback as soon as possible.

Thanks very much, indeed i didnt notice that Knuth's defines several
styles in the .fvwmrc file

Post by Jaimos Skriletz
So from his config the focus policy is dependent on the actual window (which can be useful in certain circumstances).
jaimos

[Thomas Adam]

Post by source liu

But the case is different as the focus method changes,  still i can
call up the *speedbar*
by key stroke, but it would no longer get focus as soon as it came
out. (as i should keep the mouse
in the region of emacs to keep emacs to hold focus).  so every time i
have to move my cursor
to get the focus of the speed bar, and after i finished the stroke,
the emacs again didnt caught
focus.

Have you changed focus policies in FVWM?  Because I suspect a whole
lot more given the changes in Emacs that I've seen, that they've
decided to do something which changes how this used to work, or more
likely, it's a subtle issue with GTK3.

Hey, i cant tell exactly policies i'm using, i configured my fvwm up
following Knuth's way
(http://www-cs-faculty.stanford.edu/~uno/programs.html ), i though it
might be Sloppy.

You can tell, because it will be in the Style lines (most likely -- although
not always) in the config file.

Post by source liu

The problem remains when multiple windowed application such as *Gimp*
is launched, but it never
come to so critical as mouse is widely used in them.  I've enjoyed so
much in keeping my hand free of
mouse when editor text with emacs.

Oh look.  Another GTK program.

yes, indeed, i'm using chromium, and i find --geometry parameter is
suppressed. but the conflict never came out before i embrace FVWM(
before that, i never try to place a window as my wish when it
initiate).

And you can still do this. GTK programs in general like to think they know
best by remembering their geometry. But you can do things like:

Style Chromium NoPPosition, PositionPlacement +x +y

Note that you'll need to fill in the values for PositionPlacement correctly,
etc.

Post by source liu

I would not change back to the way ClicktoFocus, as i'm lovin it,  is
there any way or suggestions to drive
away the problem bother me in which i mentioned above to get rid of
moving the mouse back and forth... back
and forth.

Well, applications can decide for themselves which windows to focus.
And I suspect that's exactly what was happening before.   Certainly
there's nothing inherent in the way FVWM is handling window focus
which would cause the symptoms you're describing.

do you mean, FVWM is a *wm*, and it treat window as window, rather
than looked into the group how there were organized, or in another word
it's our responsibility to tell her *do it in that way*?

There's actually a very lengthy reply I could give here about how focus
works between clients (including the window manager which is just another
XClient), but suffice it to say that the short answer to your question is
that we can tell FVWM which focus policy to apply to the window it creates
for the application, and then the application itself may or may not use
things like XSetInput() to throw a spanner in the works.

FVWM is not a tiling window manager, although again, an application if it
sets things like WM_ROLE may well have some logic in there to dictate how
focus is applied to {sub,transient}windows.

-- Thomas Adam

[source liu]

yes, indeed,  i'm using chromium,  and i find  --geometry parameter is
suppressed.  but the conflict never came out before i embrace FVWM(
before that, i never try to place a window as my wish when it
initiate).

And you can still do this.  GTK programs in general like to think they know
Style Chromium NoPPosition, PositionPlacement +x +y
Note that you'll need to fill in the values for PositionPlacement correctly,
etc.

Good, i've figure it out that it can store its geometry, but i failed
to find its handle,
This would help a lot

another question, how to handle the multiple windowed application
such as *Gimp*

There's actually a very lengthy reply I could give here about how focus
works between clients (including the window manager which is just another
XClient), but suffice it to say that the short answer to your question is
that we can tell FVWM which focus policy to apply to the window it creates
for the application, and then the application itself may or may not use
things like XSetInput() to throw a spanner in the works.
FVWM is not a tiling window manager, although again, an application if it
sets things like WM_ROLE may well have some logic in there to dictate how
focus is applied to {sub,transient}windows.

Thanks so so so much,
yet, i'm afraid my knowledge is poor enough to misunderstand your
reply on X, :),
it's nessary for me to take a look at Xlib manual to comfirm we are
in the same channel
before we can begin this topic. next time would be a proper time, i supposed.

i've never came to a domain in which the variety manual and knowledge
burst out,
could you give me some advice on how to survey through the X ( or
FVWM, or any application
or modular simple enough yet reflect the structure and design of the
whole building),

I'm overjoyed here to pick up a direction for me to forward.

-- Thomas Adam
--
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.

[Thomas Adam]

Post by source liu

yes, indeed,  i'm using chromium,  and i find  --geometry parameter is
suppressed.  but the conflict never came out before i embrace FVWM(
before that, i never try to place a window as my wish when it
initiate).

And you can still do this.  GTK programs in general like to think they know
Style Chromium NoPPosition, PositionPlacement +x +y
Note that you'll need to fill in the values for PositionPlacement correctly,
etc.

Good, i've figure it out that it can store its geometry, but i failed
to find its handle,
This would help a lot

Use FvwmIdent to identify its class name. You can also use wininfo, xprop,
etc.

Post by source liu
another question, how to handle the multiple windowed application
such as *Gimp*

Handle it how? FVWM honours the WM_ROLE attributes which AFAIK the Gimp
still uses. What is it you're wanting to do?

Post by source liu

There's actually a very lengthy reply I could give here about how focus
works between clients (including the window manager which is just another
XClient), but suffice it to say that the short answer to your question is
that we can tell FVWM which focus policy to apply to the window it creates
for the application, and then the application itself may or may not use
things like XSetInput() to throw a spanner in the works.
FVWM is not a tiling window manager, although again, an application if it
sets things like WM_ROLE may well have some logic in there to dictate how
focus is applied to {sub,transient}windows.

Thanks so so so much,
yet, i'm afraid my knowledge is poor enough to misunderstand your
reply on X, :),
it's nessary for me to take a look at Xlib manual to comfirm we are
in the same channel
before we can begin this topic. next time would be a proper time, i supposed.

No, it's not necessary to understand Xlib.

-- Thomas Adam

[source liu]

first of all, sorry for the delayed reply.

Use FvwmIdent to identify its class name.  You can also use wininfo, xprop,
etc.

another question,  how to handle the multiple windowed application
such as *Gimp*

Handle it how?  FVWM honours the WM_ROLE attributes which AFAIK the Gimp
still uses.  What is it you're wanting to do?

I'm afraid i'm a little lost into the variety definition, but it
doesn't matter much.

I wanna use an example to illustrate what would happen when i try to
destroy an mutiple
windowed program( Scilab for instant, Gtk-based).

The main window is console windows , as we all know
and i type
---> figure(1)
---> figure(2)
---> figure(3)
...

it would generate several plot window of course, as we expected. and
such window would
be independence, when i try to destroy(yes, *destroy*, not *close*,
close seem to be fine) one of them, all would be destroy( so is the
console window)

and this result is not the case i suppose to get.

That may be the problem for me to *handle* the multiple windowed application.

I dont know whether it is a feature rather than abnormal actions.

in fact, it hasn't brought critical results for me, up till now, but
i though it is a potential
risk

No, it's not necessary to understand Xlib.

then, what's the shortcut to the point. Just a little daze in which
way start.

-- Thomas Adam

[Thomas Adam]

Post by source liu
first of all, sorry for the delayed reply.

Use FvwmIdent to identify its class name.  You can also use wininfo, xprop,
etc.

another question,  how to handle the multiple windowed application
such as *Gimp*

Handle it how?  FVWM honours the WM_ROLE attributes which AFAIK the Gimp
still uses.  What is it you're wanting to do?

I'm afraid i'm a little lost into the variety definition, but it
doesn't matter much.
I wanna use an example to illustrate what would happen when i try to
destroy an mutiple
windowed program( Scilab for instant, Gtk-based).
The main window is console windows , as we all know
and i type
---> figure(1)
---> figure(2)
---> figure(3)
...
it would generate several plot window of course, as we expected. and
such window would
be independence, when i try to destroy(yes, *destroy*, not *close*,
close seem to be fine) one of them, all would be destroy( so is the
console window)
and this result is not the case i suppose to get.
That may be the problem for me to *handle* the multiple windowed application.

No -- you asked for what you got here, when you said "Destroy". So I am not
surprised the application closed all its windows. It did exactly what you
asked it to.

-- Thomas Adam

[source liu]

No -- you asked for what you got here, when you said "Destroy".  So I am not
surprised the application closed all its windows.  It did exactly what you
asked it to.

I see, maybe i should repent myself, i regarded *destroy* as the
enforced version of *close*.
and it also enforced the number of windows :) should i cheer for the
result which i got that that i
expect?

btw, if you use emacs M-x into the shell mode, and type emacs to
start another emacs,

and when you perform the *destory* on the latter one, the first one
remains ( of course, perform *destory*
on the first one would destory the latter one, as expected),

what is the difference between the case i mentioned earlier( for
scilab), and this case.



Thanks again

B/R

-- Thomas Adam

[Thomas Adam]

Post by source liu

No -- you asked for what you got here, when you said "Destroy".  So I am not
surprised the application closed all its windows.  It did exactly what you
asked it to.

I see, maybe i should repent myself, i regarded *destroy* as the
enforced version of *close*.

Nope. That's backwards.

Close in FVWM terms, first sends a Delete and then a Destroy. Delete is
defined in the ICCCM spec which some applications can feel free to ignore.
So in your case, by issuing a Destroy command you're doing more damage
because in that case the result is often to get the process managing that
window to be killed, or some other undefined behaviour I can't tell you
without looking at the source to a program.

Post by source liu
and it also enforced the number of windows :) should i cheer for the
result which i got that that i

See above.

Post by source liu
expect?
btw, if you use emacs M-x into the shell mode, and type emacs to
start another emacs,
and when you perform the *destory* on the latter one, the first one
remains ( of course, perform *destory*
on the first one would destory the latter one, as expected),
what is the difference between the case i mentioned earlier( for
scilab), and this case.

See above. You want to always use "Close" which will always try and Do The
Right Thing (tm).

-- Thomas Adam

[source liu]

Close in FVWM terms, first sends a Delete and then a Destroy.  Delete is
defined in the ICCCM spec which some applications can feel free to ignore.
So in your case, by issuing a Destroy command you're doing more damage
because in that case the result is often to get the process managing that
window to be killed, or some other undefined behaviour I can't tell you
without looking at the source to a program.

and it also enforced the number of windows  :)  should i cheer for the
result which i got that that i

Thanks, you are pulling me back when i stepping into the abyss,

all the document i've read are saying, *close* is a more peaceful way
to kill a window,
which made me though it did less thing than *destroy*.


thus, the *destroy* acts as to turn of the computer by cut the power supply,
yet it would harmless if the computer is a laptop with a battery.
and the *close* is something like sending a halt signal to OS, then
turning off the power.

this make sense, great!

seen i'm on the left side of you ( this means you are always on the
right side :) )

[Bert Geens]

Post by source liu

No -- you asked for what you got here, when you said "Destroy".  So I am not
surprised the application closed all its windows.  It did exactly what you
asked it to.

I see, maybe i should repent myself, i regarded *destroy* as the
enforced version of *close*.
and it also enforced the number of windows :) should i cheer for the
result which i got that that i
expect?
btw, if you use emacs M-x into the shell mode, and type emacs to
start another emacs,
and when you perform the *destory* on the latter one, the first one
remains ( of course, perform *destory*
on the first one would destory the latter one, as expected),
what is the difference between the case i mentioned earlier( for
scilab), and this case.

I'm assuming (I don't use/know scilab) that it launches these plot
windows in the same process as the main application, so if you end up
destroying the entire application. Starting emacs from emacs otoh
creates a subprocess (I'm probably butchering terminology here, but I
hope the idea is clear) so you end up only killing that subprocess
whereas if you kill the parent process the child processes also get
killed.

Kind regards,

Bert Geens

[source liu]

Post by Bert Geens
I'm assuming (I don't use/know scilab) that it launches these plot
windows in the same process as the main application, so if you end up
destroying the entire application. Starting emacs from emacs otoh
creates a subprocess (I'm probably butchering terminology here, but I
hope the idea is clear) so you end up only killing that subprocess
whereas if you kill the parent process the child processes also get
killed.

actually i've tried *gimp*, it act the same as the *scilab*.

on which, you perform *destory* on toolbox window(for instant), it
would close whole *gimp*;
but the *close* would close toolbox window only.

Which Thomas told me is really interesting, and i still need time
to get it through.

B/R.

Post by Bert Geens
Bert Geens

[Bert Geens]

Hello,

Post by source liu
Hi,
I've recently picked up the pace of fvwm2, (v2.6), and i enjoy the
style of fvwm
style in getting the focus of windows by mouseover, except for i'm setting up
my cedet for emacs. before i'm into fvwm, i used KDE, whose method is
ClicktoFocus by default.
In the ClicktoFocus case, when my trying to call the *speedbar*, which
would generate
a window companied by the opened emacs window, and auto get focus.
after key stroke, the *speedbar* lost it focus by default, (without close it).
thus, one can call it back and forth, whenever need.
But the case is different as the focus method changes, still i can
call up the *speedbar*
by key stroke, but it would no longer get focus as soon as it came
out. (as i should keep the mouse
in the region of emacs to keep emacs to hold focus). so every time i
have to move my cursor
to get the focus of the speed bar, and after i finished the stroke,
the emacs again didnt caught
focus.
The problem remains when multiple windowed application such as *Gimp*
is launched, but it never
come to so critical as mouse is widely used in them. I've enjoyed so
much in keeping my hand free of
mouse when editor text with emacs.
I would not change back to the way ClicktoFocus, as i'm lovin it, is
there any way or suggestions to drive
away the problem bother me in which i mentioned above to get rid of
moving the mouse back and forth... back
and forth.

Are you perchance using MouseFocus (FocusFollowsMouse), this iiuc gives
focus to whatever window is under the mouse. Switching to SloppyFocus
(assuming you are indeed using MouseFocus) might fix the issue you're
having.

Kind regards,

Bert Geens

[source liu]

Post by Bert Geens
Are you perchance using MouseFocus (FocusFollowsMouse), this iiuc gives
focus to whatever window is under the mouse. Switching to SloppyFocus
(assuming you are indeed using MouseFocus) might fix the issue you're
having.

My method acts similarly as your described, that is, the window
would not lost focus, if the cursor is on the root window. Thanks,
the information your gave may help a lot, i'll look through the
Sloppy describe for further information, hope it could lighten my
path in configure it up.

:)

Post by Bert Geens
Kind regards,
Bert Geens