Subject: FvwmIdent problem

From: Michael Han <[email-masked]>
Date: Sat, 22 Apr 2000 11:36:27 -0700

Hi, I seem to be having some trouble with FvwmIdent. When invoked
outside of any window context, FvwmIdent is supposed to prompt me with
a crosshair cursor to select the window I want to identify. If I
invoke FvwmIdent with no window having focus, I get: 1) an Ident
window quickly mapped and unmapped, if FvwmIdent was invoked from my
window-ops menu; or 2) the crosshair cursor flashing quickly and
resuming its regular shape, if I run from a keybinding.

Is anyone else seeing anything like this? I'm using ClickToFocus,
ClickToFocusRaisesOff and ClickToFocusPassesClick, if those are
relevant.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
A double negative is a no-no.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 23 Apr 2000 00:08:49 +0300

> resuming its regular shape, if I run from a keybinding.

No, I can't reproduce this, although tried several times.
I have both menu entry and keybinding to FvwmIdent, both work as expected
with and without a window context. Probably it is configuration specific.

> ClickToFocusRaisesOff and ClickToFocusPassesClick, if those are

I use SloppyFocus for "*", but have some windows ClickToFocus, and I
experimented only with them.

I guess, you should investigate this problem more.

BTW, I accidentally removed a message from fvwm@ telling about a problem
with iconifying a shaded window, moving it to another page and restoring.
I have tested this several times as well and can't reproduce the problem.
Can someone, please, verify this too and answer to this message?

Regards,
Mikhael.

---

From: Michael Han <[email-masked]>
Date: Sat, 22 Apr 2000 14:23:00 -0700

Previously from Mikhael Goikhman
>with and without a window context. Probably it is configuration specific.

Fair enough. I'll try to determine what config is causing the problem.
Sometimes, when I think I've found a bug, I discover that some new
feature exists or an existing feature no longer exists or there's been
a change to some default behavior...
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"I was thinking of the immortal words of Socrates, who said, "I drank what?"
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Michael Han <[email-masked]>
Date: Sat, 22 Apr 2000 15:06:03 -0700

Previously from Michael Han
>a change to some default behavior...

Okay. I looked harder. It looks like for the problem of root
keybindings, I'd randomly picked the unfortunate binding

Key Escape A C Module FvwmIdent

This doesn't ever appear to work, since the Escape gets passed to
FvwmIdent, cancelling the selection process. Or that's my guess. Other
root key bindings seem to work. For my other problem (invoking from a
menu), it appears to be caused only when you use a key selection in
the menu. Clicking the menu seems to be fine. The following minimalist
config should do it:

AddToMenu Window Ident Module FvwmIdent
Key F1 A N Menu Window

Regardless of focus policy, etc., if you popup the menu from the root
context and attempt to select this item using menu-based key
navigation (space or enter to select), FvwmIdent doesn't wait for you
to select a window. It does work if I assign a hotkey like "&Ident"
and select using "I".

So... after experimenting with FvwmIdent in "crosshair window select
mode" is that escape, space and return all end the selection process.
Escape cancels and space/return mimic Button 1 (select whatever's
under the cursor). Now, this means that in the configs I describe
above (maybe all?), Key Events that selected FvwmIdent to run are
"bleeding" into FvwmIdent's event queue... Can anything be done about
this? I'm chiefly concerned about the case of selecting FvwmIdent out
of a popped-up menu from the root context, using standard fvwm
key-based menu navigation.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"How can someone with glasses that thick be so stupid?" - Bart
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 23 Apr 2000 02:10:04 +0300

Ok, Michael, you are lucky. :) This problem bugged me a lot too (I have
Ctrl-Shift-F10 bound to FvwmIdent, so I needed to hold modifiers to be
able to read FvwmIdent window), but I had no time to take a look.

I didn't fixed Ctrl-Escape starting and immediately canceling crosshair;
this can be done, but this is in the libs and I don't want to touch this.

Regards,
Mikhael.

---

From: Michael Han <[email-masked]>
Date: Sat, 22 Apr 2000 17:06:34 -0700

>able to read FvwmIdent window), but I had no time to take a look.

Ooh, in the process of testing I forgot that this was bugging me!
Thanks.

>this can be done, but this is in the libs and I don't want to touch this.

I see what you mean. Still, I think it's a bad model that menus appear
to invoke their bound actions on KeyPress yet
fvwmlib_get_target_window() watches KeyReleases. It allows
menu-bindings that cause fvwmlib_get_target_window() to be invoked to
have their KeyRelease events be picked up by the module that was
invoked. I can't imagine this is desirable. It appears that
FvwmDragWell and FvwmScroll also use this function, but no others. Can
we patch this?
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
A closed mouth gathers no foot
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]