Package: xbomb Version: 2.2b-1 Severity: normal This is without any xbomb specific configuration of i3.
When I start i3 on a desktop where only my i3bar is present, it starts in a window that takes up the entire desktop (that is as i3 is supposed to make it). xbomb starts in easy/squares mode but the individual fields of the playing board are scaled so badly that I can only see the first 5½ row, that makes the game impossible. Changing to medium/squares I can see the first 11 rows (and a tiny fraction of the 12th), in hard/squares I can actually see the entire board. Changing game type just leaves a white area where the menu was (after changing desktops = redrawing windows) the entire playing area is white, and changing level doesn't change that, but it is remembered if I change back to squares. When i3 splits the desktop horisontally between xbomb and another window, the hexagons and triangles mode still doesn't work, but easy/squares is scaled better, I can see all 8 rows and 7½ columns (the window is wide enough that the rest of the eight column could have been there, but it's cut. Similarily medium/squares is scaled so that the 16'th column is needlessly cut, the numbers that appear in (some of) the squares in that column is also cut, but you can see enough to tell them apart. In hard/squares only the first 20 columns are visible. Other configurations of additional windows and thereby other sizes for the xbomb window is possible, but I don't see any value in testing more. It doesn't seem to make a difference whether I make the window floating after starting the program, or by putting 'for_window [class="XBomb"] floating enable' in i3's config. When trying to resize the window (in floating mode, the only option is using the keybindings) the window size doesn't change, probably because xbomb refuses the new size (that is probably the same issue as reported with ratpoison in #456031). It's possible that defining other keybindings to resize the window in both directions simultaneously and other increments might give other results, but that seems like a poor strategy (I can't define keybindings for every program that might need special behaviour). At first, when xbomb starts in easy/squares, everything looks good, and the game is playable. Changing to medium/squares, the window becomes significantly smaller (not what is expected), it becomes so narrow that the "Hi-Scores" button is cut with the first column (or two) of the second "s" visible, and the "Quit" button is not in the window. If I start playing, the numbers that appear in the squares are higher than the squares giving a rather confusing look, but the game is playable. Changing back to easy/squares, the window does not change size, but the smaller number of squares means everything looks fine, but the button bar is still cut, in particular the "Quit" button is missing from view. Changing to hard/squares (it seems not to matter whether the change was from easy or medium), the window is resized to a wider variant to accomodate the number of squares, but the individual squares are too small for the numbers inside (the same as described above), changing from hard to easy, gives the window the initial size where the "Quit" button is visible. In hexagon iand triable modes it's much the same, except that going from medium to easy make the window smaller than it was from the start, and going from difficult to easy make it a larger than it was from the start. Going from floating to tiled mode, you can continue the game in both hexagon and triangle modes, but the fields of the board is not scaled, just placed with lots of space between them, and in triangle modes the numbers appear outside the fields. Trying to go from traibles to hexagons or vice versa in a tiled window, produces some strange graphic effects. ----- Some conclusions: Basically only squares modes work when the window is tiled, but scaling is weird and means only some levels are playable. When the window is floating, all modes work, but on medium or hard levels scaling is very poor. ----- I would suggest making xbomb allow any window size, with some minimums based on game mode and the width of all the buttons. And then just scale the area that is actually used for the playing field. That might results in windows with quite a lot of whitespace, but I guess it will make it work better with window managers that try to affect the size of the window. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xbomb depends on: ii libc6 2.19-18+deb8u4 ii libx11-6 2:1.6.2-3 ii libxaw7 2:1.0.12-2+b1 ii libxt6 1:1.1.4-1+b1 xbomb recommends no packages. xbomb suggests no packages. -- no debconf information
