2

xterm*VT100.Translations only when mouse is over the window with focus

Is this a bug or a feature?

For me, it's a serious problem.

(click to focus)

ONLY CYGWIN

In particular, I'm talking about the function keys. In this case, these are NOT mapped in fvwm, but in xterm.

Pressing a function key, like F1, always writes to the window with focus, but only performs the X11/xterm translations with the mouse is hovering over the window with focus.

So, I always have to move the mouse to the window to be able to write to the window. Otherwise, \e[P is written to the window, for example

Note that I can visit various windows with keyboard shortcuts, so there's no natural correspondence with mouse position and window focus.

This failure to do the X11/xterm translation only occurs with x11/cygwin xterms. Windows opened locally via sshd (port forwarded) behave normally, performing the translation to the focused window, no matter where the mouse is.

fvwm 2.6.6 compiled on Oct 10 2016 at 00:25:52 with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS

n952162
  • 21
  • 1
  • NOT ONLY CYGWIN! I just realized this is the same behavior that's been irritating me for decades: function keys also send untranslated keycodes if the mouse is positioned over the scroll bars or window frame - in LINUX, too! But LINUX sends the properly translated keypress if the mouse is anywhere else. – n952162 Mar 09 '22 at 14:19
  • Please help me determine if this problem is in fvwm, xterm, or something else. – n952162 Mar 09 '22 at 14:24
  • I'm glad you were able to reproduce it on a GNU/Linux system in the scrollbars. That's where I also encounter it on those systems. On cygwin systems, I get the same behavior also outside the window completely. I'm thinking, this is BOTH a X11 and FVWM bug - and the cygwin implementation of the X11 server has it worse. – n952162 Mar 09 '22 at 16:46

1 Answers1

1

Translations when the mouse cursor is on the scroll bar

The scroll bar has its own translations. Under a “native” X11, they apply when the mouse cursor is on the scroll bar, but not when it's outside the window. You can set them through XTerm.vt100.scrollbar.translations (or variants using classes). You should probably set identical translations for keyboard keys, but not for mouse buttons.

If you don't have mouse event translations that are undesirable in the scroll bar, and you aren't using the keymap(…) action, you can set translations that apply to both with

XTerm.vt100*translations: #override …

or even

XTerm*translations: #override …

Translations when the mouse cursor is outside the window

I haven't observed different translations when the mouse cursor is outside the window under a native X11, including with FVWM. I suspect that when xterm is running remotely or in a non-native X11, there are cases where the library that xterm uses doesn't properly track the mouse cursor when it's outside the window, and may end up believing that the mouse cursor is at the last position it was inside the window, or in the top left corner ((x,y)=(0,0), which is in the scroll bar if it's on the left side). If so, setting translations for the scroll bar as above should resolve the problem. If not, I have no idea what could help.

P.S. Back when I had to use a desktop Windows, I preferred to run Cygwin command line applications in mintty, and I didn't run an X server. But this was a long time ago (Windows XP days).

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • Thank you for the scrollbar solution!!! Works perfectly for me, just changing the "." to a "*". Unfortunately, it didn't help with the rest of the desktop, but it may be an important hint. – n952162 Mar 10 '22 at 08:55
  • I've used cygwin on and off over the years, and it was always a life-saver, but it's gotten more and more perfect. Except for this one issue. Not that I'd willingly buy Windows, but I could live with it, if not for this issue. – n952162 Mar 10 '22 at 09:15
  • Funny thing, I had already tried changing `XTerm*vt100.Translations` to `XTerm*Translations`, but with mouse on scrollbar it still wouldn't work. `XTerm*translations` does work though. It is also interesting that Editres thinks there is no scrollbar widget. – Quasímodo Mar 10 '22 at 17:54
  • 1
    @Quasímodo The precedence order for [X11 resources](https://www.x.org/releases/X11R7.5/doc/man/man7/X.7.html#toc13) is well-defined and somewhat logical, but not really intuitive. There must be some applicable default for `XTerm.vt100.scrollbar.translations` that takes precedence over `XTerm*Translations` but not `XTerm*translations`. I don't know how to find this default (I don't think it's necessarily listed in `appres XTerm xterm`). Editres is moribund. I think Xt (which xterm uses) can still support it, but it doesn't work on e.g. a modern Ubuntu out of the box. – Gilles 'SO- stop being evil' Mar 10 '22 at 18:11