Control: clone -1 kwin-x11 Control: retitle -1 Wesnoth UI does not work properly if WM does not respect requested size. Control: retitle -2 KWin 5 does not respect resize requests if the application starts maximized.
(hopefully that control stuff works right ...) I have further isolated the bug, and not filed it upstream. What happens is that wesnoth starts in a window that is maximized (I'm running under kwin 5 at 1366x768), and then I use the kwin "fullscreen" option (either from the window corner menu or the keyboard shortcut - alt-enter by default) to change it to fullscreen. Any buttons that were not visible in the maximized window (off the bottom of the screen - I have both a top taskbar and a bottom one) are not clickable. I also observed that, when the window is maximized, going into preferences and requesting a resolution change does NOT work. This is likely related - wesnoth should only be drawing its UI in the resolution that the window manager gives it, regardless of whether or not that resolution is satisfying its request. I believe that other WMs typically implement "resize to native resolution" as an implicit request for fullscreen. Note: the reason I start Wesnoth in windowed mode and then switch it to fullscreen from the WM is that SDL1's fullscreen support steals all input focus from the WM and forcibly changes the resolution, whereas WM fullscreen is implemented as resize with no border. I *think* SDL2 supports the "nice" fullscreen (not sure by default?). Upstream documentation indicates that 1.13 should be switching to SDL2 eventually, but that doesn't seem to have been done yet for the version that Debian has packaged. Workaround: leave fullscreen, unmaximize the wesnoth window, then resize it (either from in-game or by dragging the corners in the WM - which will give a resize event that wesnoth recognizes), then enter fullscreen again. Note that merely unmaximizing (without resizing) will leave wesnoth in a buggy state, and is a simple way to make even *more* buttons unresponsive. Summary: I believe there are at least two bugs here: the KWin not respecting the application's request, and Wesnoth (or possibly SDL) not properly respecting it. I am fairly certain that the mouse-specific issue is merely a side effect of the resize-related bugs. -Ben On Thu, Oct 8, 2015 at 2:05 PM, Vincent Cheng <vch...@debian.org> wrote: > Control: tags -1 + moreinfo unreproducible > > Hi Ben, > > On Sat, Oct 3, 2015 at 12:45 AM, Ben Longbons <brlongb...@gmail.com> wrote: >> Package: wesnoth-1.12 >> Version: 1:1.12.4-1 >> Severity: important >> >> Dear Maintainer, >> >> A handful of the UI buttons cannot be clicked (tested with multiple mice). >> >> In particular I have noted: >> >> * The "End Turn / End Scenario" button (action menu or ctrl-space works) >> * The "OK" button in the Addons Manager (double-click or enter works) >> * The "Close" button in Help/Unit Description (escape works) >> >> This did not occur with wesnoth-1.10. >> >> Using the keyboard shortcuts or alternative mouse actions above still works, >> and the mouse works perfectly on all other buttons that I have noticed. >> >> (I normally use the keyboard, but was demoing the game for a friend, so >> this was quite embarrassing.) >> >> There is also something funny with clicking on a unit that has >> had the spacebar pressed to ignore its remaining move for the N key. It >> cannot be moved unless you press space again and *then* press the N key. > > Unfortunately I cannot reproduce this at all; UI buttons work as > expected for me. > > I have no idea what might be causing this issue; you may want to > report this directly upstream and see if they have any suggestions. > Instructions for filing a bug report for wesnoth can be found at [1]. > > Regards, > Vincent > > [1] http://wiki.wesnoth.org/Reportingbugs
