As of cairo-1.17.8, gnome-mahjongg-3.38.3 is 100% unplayable, as tiles in the game's playfield cannot be selected at all. The primary debug thread was on gitlab.gnome.org: https://gitlab.gnome.org/GNOME/gnome-mahjongg/-/issues/37 which demonstrates the problem very clearly with concise debug output. However, it lacks the fix. I presented a working fix at: https://forums.gentoo.org/viewtopic-p-8786401.html#8786401 but cannot create a gitlab.gnome.org login to promote it upstream. Can someone with a gitlab account post this to the original thread and try to get it pushed upstream? The problem begins with cairo and ends with gnome-mahjongg itself. Cairo expects "double" types for translation coordinates (one might question why cairo feel it deserves floating point resources?) and has recently changed how it clamps these values. And so it is likely this bug has existed a long time, but it wasn't evident because somehow we got lucky with the results until this clamping behavior changed. The real bug is in gnome-mahjongg itself. game-view.vala takes in "uint" type coordinates, then incorrectly negates them and presents them to cairo without any typecast operation. This is how small integer coordinates suddenly bloat up to big 4 billion values. Folks on both forums.gentoo.org and gitlab-gnome.org have either been hacking away at cairo to remove the clamping or downgrading cairo to bypass this problem, and that is not the correct solution. Since the game is utterly, 100% unplayable as-is, we definitely need to fix gnome-mahjongg itself. My single-line patch will fix this bug. I request that: 1. Someone make a patch release of gnome-mahjongg in gentoo. 2. Someone present this patch upstream to gitlab.gnome.org in my stead as I cannot create an account there. --- /tmp/broken/gnome-mahjongg-3.38.3/src/game-view.vala 2020-11-01 01:39:32.693650200 -0800 +++ /var/tmp/portage/games-board/gnome-mahjongg-3.38.3/work/gnome-mahjongg-3.38.3/src/game-view.vala 2023-04-16 19:32:22.772192877 -0700 @@ -332,7 +332,7 @@ var cr = new Cairo.Context (surface); cr.set_source_rgba (255, 255, 255, 255); cr.paint (); - cr.translate (-x, -y); + cr.translate (-(double)x, -(double)y); draw_game (cr, true); /* The color value is the tile under the cursor */ Reproducible: Always Steps to Reproduce: 1. emerge gnome-mahjongg against cairo-1.17.8 (which is now default) 2. Run gnome-mahjongg and try to click on any tiles in the playfield. (You can click on the help icon and it will show you 2 tiles to select, but you cannot select those tiles in the playfield with the mouse. The game is dead in the water even as it runs fine otherwise.) Actual Results: Although the game runs, and you can select settings icons and help icons and so on, you cannot select any tiles with the mouse in the game playfield itself. In other words, the game runs but is absolutely unplayable. Expected Results: Tiles should be selectable (you can use the help icon to show 2 tiles to select and these should be selectable with a mouse click).
Created attachment 860260 [details, diff] Proposed patch that should also be presented upstream to someone. This patch adds typecasting to ensure the uint is treated as a double before being negated. It has been tested locally.
Created attachment 860261 [details] Proposed ebuild to consume the patch. Proposed -r1 ebuild to consume this patch.
Chris, given you're in the thread, would you mind sending this upstream if it looks ok to you?
(In reply to fjmccloud from comment #0) > And so it is likely this bug has existed a long time ... Yes it has, and thank you for your simple fix :)
Created attachment 860337 [details, diff] Fix selecting a tile since cairo 1.17.8 Ah, I did put a few doubles in to try and fix but not there. I have submitted a patch upstream: https://gitlab.gnome.org/GNOME/gnome-mahjongg/-/merge_requests/35 I went with a slightly different approach - the click event coordinates were already doubles (OK gdoubles but that is just an alias as far as I can see) that were being converted to uints and not used for anything else. I suggest not doing that initial conversion. Anyone do say if you see a problem (I'm really a Python person!). Attached here is a backport of that patch, upstream master has already moved on to GTK 4.
I pinged folks in #gnome-hackers and got Chris's MR merged. ebassi said he'll make a release within a week or so.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79ee53516493c3b5f3857ab41f251710a7c4e09c commit 79ee53516493c3b5f3857ab41f251710a7c4e09c Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2023-05-31 16:33:33 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2023-05-31 16:41:10 +0000 games-board/gnome-mahjongg: Version bump to 3.40.0 Closes: https://bugs.gentoo.org/904476 Signed-off-by: Matt Turner <mattst88@gentoo.org> games-board/gnome-mahjongg/Manifest | 1 + .../gnome-mahjongg/gnome-mahjongg-3.40.0.ebuild | 46 ++++++++++++++++++++++ profiles/features/wd40/package.mask | 1 + 3 files changed, 48 insertions(+)
