Since the last update, a solitarire game I play has begun disabling the mouse, leaving me unable to click anywhere in the game's client area. I can still click on the [X] in the title bar in order to kill the game.

When I start gnome-mahjongg, it plays normally, with mouse clicks immediately taking effect. When the game ends, if I start a second game without restarting the app, mouse clicks take effect only after 1/3 or 1/2 second. Click, wait, tile is selected. Click again, wait, a second tile is selected. Wait, tiles are removed.

The alternative sometimes happens instead. I click, the tile is selected, after which the game's client area becomes totally unresponsive to the mouse. Anywhere I click, nothing happens at all. As I mentioned, the system areas still work okay, so I can click [X] to close the game. Then, upon restarting, all works fine again.

SUSPECTED ROOT CAUSE: When playing additional games without restarting the application, something continues to build up -- undo stack? -- until behavior is affected, and eventually game play stops. Restarting the app begins with empty data structures, after which the build-up begins again.

So, this doesn't stop me from playing Mahjongg, but it's incredibly annoying. Anybody else seeing this?

    Works perfect for me.
    But i installed it just yesterday after i noticed your comment about it on the other thread.
    So afdter the update.

      MikeK61 So afdter the update.

      Thanks for letting me know! Perhaps it happened to me prior to the last update, but hadn't annoyed me enough to make an issue of it until now. It may be time for more details. DE: KDE Plasma. SESSION: X11. But I'm about to change that, and log in to a Wayland session, to see whether it happens there as well.


      Yep. The DE apparently makes no difference. I played one game with mouse activity happening at the high speed I'm accustomed to with Wayland. Then, without doing anything else, I clicked to start a new game. Performed just one mouse click, and the whole application client area locked up. The system area was again responsive, so I was able to kill the stalled game.

      tflovik Do you run it from Gnome or KDE?

      KDE. The only thing I ever do in GNOME is apply updates to my GNOME VM.

      I'm going to try re-installing gnome-mahjongg, after cleaning it out of my home directory. That should renew not just the application, but any remaining configuration from the previous installation. Here goes ...

      Didn't help. Played the first game normally, and started another. The mouse didn't fail completely, but after clicking on one tile, there was a small, but noticeable, delay before the tile took on its "clicked" appearance. Those small delays accompanied every subsequent mouse click until finally there were no more moves available, and I clicked to start the third game.

      After the first mouse click of that third game, the application client area locked up tight. Again, the system area was still responsive, so I was able to click [X] to remove the stalled game. At this point, I don't know what else I can remove/clean/restart or whatever else to get gnome-mahjongg working correctly on this laptop.

      (I've tried everything I can think of to remove the formatting on the first part of this message, but flarum has failed me once again. Sorry if it's making this message hard to read.)

      TO SUMMARIZE:

      • This issue happens in both X11 and Plasma sessions.
      • I could find nothing identifiable as gnome-mahjongg in ~/. or in ~/.cache. If present, it's hidden well.
      • After installing again with --reinstall, and playing Mahjongg again, there was no change.
      • The same sequence of actions that locked up the client area earlier, did so again.

      SYSTEM INFO:


      I thought of one final test, to eliminate any influence from my laptop. I fired up my KDE Plasma VM, installed gnome-mahjongg, and played a game there. When I got to a "no more moves" notification, I started a new game. In the second game, I removed one tile, and then the client area was non-responsive, exactly as when I'd tried to debug this on my laptop.

      So there was nothing -- no history of any kind, no configuration of any kind, nada -- involved from the laptop. The VM had never seen gnome-mahjongg until I just now installed it. But the results were the same as on the laptop. So there is definitely, without a doubt, positively something wrong with the gnome-mahjongg package.

      And I strongly suspect that it's what I suggested several messages ago: an accumulation of some kind -- like an undo stack -- that's not cleared out when a new game is started. It continues growing until something gives.

      Debugging finished.

        Have you tried kmahjongg, by the way? I'm not sure how it differs to gnome-mahjongg, but it might work better on KDE!

          synth-ruiner Have you tried kmahjongg, by the way?

          Good question! Yes, not to see whether it's subject to this same issue (I suspect it's not affected), but about a year ago I got the idea that since all my Linux computers use KDE Plasma for a DE, it would be more consistent for me to use the KDE versions of whatever applications I can. Maybe it would also reduce non-KDE dependencies.

          One of those applications was Mahjongg. I was totally underwhelmed by KMahjongg, and gave up on the idea of using the KDE version of everything I could. Today, given a choice of using KMahjongg without the problem I've been describing, or instead using gnome-mahjongg and restarting it after every game, I'd still prefer the latter.

          I've even tried to remove kmahjongg from my system, but doing so would also remove kshisen, the Shisen-sho game, for which I've found no non-KDE version. (They both use the same set of Mahjongg tiles.) Unlike kmahjongg, kshisen is a joy to play, and I've never had a problem with it.

          I had hoped that this week's sync might include a version of gnome-mahjongg that doesn't have this issue, but no such luck. Today's version also locks up after a few partial games. 😮‍💨

          WetGeek And I strongly suspect that it's what I suggested several messages ago: an accumulation of some kind -- like an undo stack -- that's not cleared out when a new game is started. It continues growing until something gives.

          Sounds like it might be connected to this recent fix (not yet implemented in the current release): https://gitlab.gnome.org/GNOME/gnome-mahjongg/-/commit/575a3aa37c0a1a5f993cb49d1477fb3a0ff05152

          update: opened a PR that adds this patch to our package: https://github.com/getsolus/packages/pull/374
          For me it fixes all issues with gnome-mahjongg slowing down and eventually freezing in longer play sessions (or when repeatedly pressing the "Hint" button)

            Staudey Sounds like it might be connected to this recent fix

            That sounds great! I've gotten so used to quitting and restarting the game that it's not really a big issue. I'll be glad to wait for the fix to show up in a future sync. Thanks for letting me know.

            Using the Budgie desktop, I confirm that I also encountered problems similar to those reported by @WetGeek , except that when I started a new part, the application screen remained frozen, even after a long wait.
            I had waited for today's update (53 packages, 0.99 GIB) before writing this post. I am happy to learn that this problem will be resolved soon.
            PS. Thanks to @WetGeek for making me discover the game Shisen-Sho, a variant of the interesting Mahjongg.

            Yeah I too have noticed bad behavior from gnome-mahjongg. It's been getting into fights at school and is failing history class! Must be all those video games being a bad influence

            6 days later

            Confirming that after this week's gnome-mahjongg upgrade, the game is working fine again. I just played two game with mouse action quite normal, and started the third, again with normal mouse behavior. Until today's upgrade, I never could have done that.