That still a bug in boswars
- "Focus follows mouse" is a valid option
for a window manager

And yes, editing engine/ui/mouse.cpp
does fix it.

Also, on unrelated note: there should be
a way to control the speed of scrolling
the map as mouse moves.

Reported to http://bugzilla.libsdl.org/show_bug.cgi?id=933

This bug happens because SDL 1.2.14 (but not 1.2.13) somehow reports two SDL_ACTIVEEVENT events before each SDL_MOUSEBUTTONDOWN event: first one event about losing SDL_APPMOUSEFOCUS, and then another event about getting it back.  The first SDL_ACTIVEEVENT makes Bos Wars think the mouse pointer of X has left the Bos Wars window and move its own mouse cursor to the center of the window.  Bos Wars then does not move its mouse cursor back to the original position on the next SDL_ACTIVEEVENT, and ignores the coordinates reported in SDL_MOUSEBUTTONDOWN and instead uses the previously set coordinates of its mouse cursor at the center of the window.

There seem to be two workarounds:

- Better: If you compile Bos Wars from the source, edit engine/ui/mouse.cpp (HandleMouseExit) and comment out the CursorX and CursorY assignments.  This has the side effect that moving the mouse pointer of X out of the Bos Wars window will leave the mouse cursor of Bos Wars in its last position, rather than at the center of the window.  However, Bos Wars will correctly abstain from scrolling the viewport even if that position is near an edge of the window (as it usually is).

- Worse: Edit boswars.lua and change SetLeaveStops(true) to SetLeaveStops(false) in boswars.lua.  This has the same side effect as above and Bos Wars will not stop scrolling either.

Can you point to the decsription in guichan where they talk about this ? Thanks.

Do you mean this happens only in the menu screens and not while playing ?

When fullscreen, mouse works correctly.
But if boswars is running windowed,
it seems that button press event is sent
at wrong coordinates.

I suspect the bug may be commimg from guichan,
(as it seems they had a bug, which description
fits this problem)
however it went through to many changes to
upgrade internal version without serious effort
(or at least a deeper understanding than only casual)
(it handles keyboard quite differently).

xorg-server-1.7.1
xf86-input-evdev 2.3.0