#22 grabs focus when I mouse over the map view subwindow

[Fabian Greffrath]

Hi Andrew,

the following bug has been filed in the Debian BTS:

"
Dear Maintainer,

I don't use focus-follows-mouse (because I find explicit focus control
far more congenial than implicit focus control).

All other GUI programs I can remember invoking on Debian have respected
this.

The map view subwindow in Eureka does not; it grabs focus (and,
consequently, raises Eureka's window) whenever I pass my mouse over it.

Based on the behaviour of a locally-built binary compiled from the upstream
source code, I believe this bug to also be present in 1.21.

I will therefore be uninstalling it shortly.

Have a nice day.
"

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883431

I can confirm this bug with the eureka_1.21-2 Debian package.

Cheers,

Fabian

[Andrew Apted]

I guess this behavior could be turned off (maybe as an option).

The main reason Eureka does this is because of keyboard event handling in the FLTK toolkit. When the main canvas does not have the focus then keyboard events can be sent somewhere where they get ignored. The TAB key is one example, FLTK would occasionally go into widget navigation mode instead of the key getting run as a Eureka command (toggling the 3D view) and it was not obvious what was going on. Quite annoying. That particular issue may be fixed now because FLTK introduced a way to disable the widget navigation system, but there could be other situations where a similar issue happens.

I will need to experiment to see if turning it off completely will cause any issues.

Thanks for the report.

[Andrew Apted]

This is probably extremely moot by now, but I have added a preference setting to disable stealing the focus.

I plan to try this setting for a while, see how much it interferes with normal workflow (if at all).

[Andrew Apted]

Re-opened this ticket, since the new setting does not work. Once you start editing one of the input boxes in the panel (like a tag number or a texture name), the keyboard focus is "stuck" and cannot be returned to the main program.

[Andrew Apted]

OK, I found a way to detect when our main window has/hasn't the "true" focus (i.e. when we or another application is active). Then the focus grabbing only occurs when we are the active window. This prevents "stealing" the focus from another application just from the mouse entering our window.

Hence I shall close this ticket again :-)