tomin1 / patience-deck

Patience Deck is a collection of patience games for Sailfish OS based on GNOME Aisleriot.

Patience Deck

Patience Deck is a collection of patience games for Sailfish OS. It reimplements game engine from GNOME Aisleriot and utilises its implementations of patience games including manual pages and artwork.

Github repository.

Building and installing

This application uses Guile. It is not packaged in Sailfish OS. You can find packaging specification files for it and its dependencies in rpm/misc/ directory.

Use either sfdk command from Sailfish SDK or Platform SDK to build Patience Deck and its dependencies. Below are instructions for building with sfdk command. Building with Platform SDK needs similar steps but you should follow its guides when building. These instructions are tested only on Linux and only using docker version of the build engine.

Before building, fetch GNOME Aisleriot sources and Patience Deck translations and apply patches:

$ git submodule update --init
$ sfdk apply

You need to do this step only once. After that aisleriot/ and translations/ directories contain assets for Patience Deck.

Building generic version

This version needs some support libraries that are built separately and must be installed to SDK target and device to build and run Patience Deck. While building support libraries can take a long time, following builds of Patience Deck are very quick to do.

The following instructions are for SailfishOS-4.1.0.24-aarch64 target but substitute your own depending on which version of Sailfish or which architecture you are targeting. If you switch targets, remember to clean up any build artifacts in source directories. If you build for i486 target, use SDK 3.9 or later.

First set your target:

$ sfdk config --push target SailfishOS-4.1.0.24-aarch64

Also set output-prefix for packages that you build:

$ sfdk config --global --push output-prefix "$HOME/RPMS"

Substitute your choice of directory at the end. You need to do this only once. This is important to allow the SDK to find the dependencies later.

Now it's time to build the support libraries. You need to do this only once if you are developing Patience Deck because future builds can use the packages that you have already built.

I recommend to create a common directory next to patience-deck/ directory where you init sfdk build directory:

$ sfdk -c target=SailfishOS-4.1.0.24-aarch64 build-init

Download the source package listed in each spec file and extract them to this directory. Enter each directory and run the respective sfdk build command as shown below.

Build support libraries starting with gc:

$ sfdk -c target=SailfishOS-4.1.0.24-aarch64 --specfile ../../patience-deck/rpm/misc/gc.spec build

Repeat for libunistring:

$ sfdk -c target=SailfishOS-4.1.0.24-aarch64 --specfile ../../patience-deck/rpm/misc/libunistring.spec build

And for guile which needs a little patch for wider version compatibility:

$ patch -p1 < ../../patience-deck/rpm/misc/guile-avoid-libcrypt-and-ncurses.patch
$ sfdk -c target=SailfishOS-4.1.0.24-aarch64 --specfile ../../patience-deck/rpm/misc/guile.spec build

Go to Patience Deck source directory and continue by building it.

Build the package:

$ sfdk -c target=SailfishOS-4.1.0.24-aarch64 build

You can find the built packages in the directory you specified in output-prefix step. In addition to patience-deck package you must install also gc, libunistring and guile22 packages to the device.

Building harbour version

Harbour aka Jolla Store compatible packaging can be built using --with harbour arguments. It builds all necessary libraries for guile and bundles them in a single package. It may take tens of minutes to build from scratch. Built libraries are cached so that rebuilding Patience Deck takes less time but if the files are removed, the following build will rebuild everything.

The following instructions are for SailfishOS-4.1.0.24-aarch64 target but substitute your own depending on which version of Sailfish or which architecture you are targeting.

Build the package:

$ sfdk -c target=SailfishOS-4.1.0.24-aarch64 build --with harbour

It will first install any missing dependencies. After that it will download and build support libraries one-by-one which can take a long time. Last it builds Patience Deck and packages everything into one package that can be installed on device. You may find the built package in RPMS/ directory or the directory you have set your output-prefix to point to.

If you need to do rebuilds, just repeat the building step. If you want to rebuild support libraries, remove libs directory or one of its target architecture subdirectories.

Installing

Depending on which version you built, the resulting package is called patience-deck or harbour-patience-deck. If you have added your device on your SDK settings and selected the correct device, you can deploy easily:

$ sfdk deploy --sdk patience-deck

Translations

Translations are hosted on another repository. Please go there to find more information about creating and updating translations.

patience-deck's Issues

Zoom cards on long press

It could be nice if player could zoom in cards with a long press. Currently it is a bit difficult to find cards in a stack. In GNOME Aisleriot player can right click cards to raise them on top of others to see them better and that works well with a mouse, but it wouldn't work on touch screen where fingers usually cover touched cards. Instead we could make the card grow upwards or to its left making the symbols on top left of the card to move next to the finger. Dragging enlarged cards should probably be allowed. This needs some experimentation to see if it is actually a feasible solution.

Allow dragging cards while magnifying table

Dragging cards would probably work okay even when table is magnified if touch handling was a bit different. It would require moving magnifying from QML code to C++ and then figuring out how the card's new position would be calculated.

Access to new game button is too difficult

Currently starting a new game is only possible from Options & Rules page but that requires using pulley menu to first open that page. In contrast Restart button requires only a press of a button on toolbar. I did not want to add new game button to toolbar since it is destructive, i.e. player cannot get back to the previous game if they press new game accidentally. This needs some thought to not break this rule while allowing easier access to new game action.

Add win animation

This is a very often requested feature: After a game ends, if the game was won it should throw cards around. Similar to what Windows' Klondike game has. I think the animation doesn't necessarily need to be the same and there could be even multiple variations of it. The difficult part is that Patience Deck supports a number of different games so animations would need to adapt to different positions of stacks in different games. Some games don't have any cards on the table at the end, so there might be need for an animation that works in this situation.

Disappearing cards on Patience Deck 0.5.1-1 ?

Dear @Tomin1

I'm having a lot of fun with Patience Deck 0.5.1-1 on SFOS 4.1 / Xperia 10 II (64 bits). Thank you very much for porting this game to SailfishOS :)

On some not so rare occurrences I stumble upon a bug where cards seem to disappear, making the current game impossible to complete (see screenshot below).

As per the screenshot, one can see that there's one deal left, yet the stock in the upper left corner is empty...

Please let me know if I could do something on my end to help you pinpoint this issue.

Best regards,

Samuel

Leaking texture file descriptors

Textures aren't correctly released. Currently it uses delete later but that can leave them hanging around if the delete doesn't happen in the GUI thread. Instead they should be removed on the GUI thread with a render job. That would also remove the need for pending texture as the old texture is guaranteed to stay around until after rendering.

This is easiest to test with lsof -p pid by checking the output, rotating the device and checking again (hint: piping to wc -l is a good idea). There should be more dmabuf file descriptors open when the issue occurs:

patience- 21899 defaultuser 50u a_inode 0,12 0 14008 dmabuf43704
patience- 21899 defaultuser 51u a_inode 0,12 0 14008 dmabuf43723
patience- 21899 defaultuser 52u a_inode 0,12 0 14008 dmabuf43724

At least I get these every time. Eventually the app would run out of file descriptors and crash.

Enable all games

Enable all games from GNOME Aisleriot and get rid of allowlist in GameList class.

Keep statistics of finished games

Currently there is no record of finished games. It would be possible to save finished games (lost and won) to sqlite database and then calculate statistics (number of games played and won, time) to display. Player finishing a game and then undoing a move should be also carefully considered when collecting the statistics. This also needs some UI design for another page in the application. There are also some performance considerations once the number of played games grows very large.

Building guile on i486 on sfdk fails

Building guile for i486 with sfdk fails and I have been trying to figure it out myself but it seems a bit too big of a challenge. Building guile package with the instructions on README.md fails with this error:

checking whether libunistring was built with iconv support... no
configure: error: No iconv support.  Please recompile libunistring with iconv enabled.

config.log tells a little bit more about the issue:

configure:47723: ./conftest
./conftest: error while loading shared libraries: libunistring.so.2: cannot open shared object file: No such file or directory
configure:47723: $? = 127
configure: program exited with status 127

This is different from the issue I had with mb2 and it does not happen with arm targets. At this point I'm not sure if this is an issue with my packaging or if it's bug in the SDK. I'll comment later here an easier way to reproduce the same issue.

Save state per game

Currently there is only one saved state for the game that has been played last. This could be improved so that the game state was saved per game so that selecting another game may continue from where the game was the last time.

While doing this it might make sense to move the state information and saved game options form dconf to sqlite.

Collect more won games to test data

Currently test data has 58 different games that have a winning play. That leaves 32 games that don't have any. I'd very much like to have successful plays for all of them to be able to check animations properly on all of them. You can help with this. Pick a game in this list, play it through (some are very tough to finish!) and use a script from this repository to collect a command that can replay the game. You can use it when the game is open in won state or if you closed the app just after beating the game.

• Accordion
• Agnes
• Auld Lang Syne
• Aunt Mary
• Backbone
• Camelot
• Canfield
• Clock
• Cruel
• Diamond Mine
• Easthaven
• Eliminator
• Escalator
• Fortunes
• Forty Thieves
• Gaps
• Kansas
• King Albert
• Lady Jane
• Odessa
• Pileon
• Poker
• Scorpion
• Scufflez
• Spiderette
• Thieves
• Thirteen
• Treize
• Valentine
• Wall
• Yield
• Yukon

While I'm really looking for finished won games, I would not mind having more game over plays too if such doesn't already exist in test data. You can submit your played game here, DM it me on Sailfish OS forum (user tomin) or send me an email.

You can use the script like this:

curl -o save_state.sh https://raw.githubusercontent.com/Tomin1/patience-deck/master/tools/save_state.sh
chmod +x save_state.sh
./save_state.sh won_game.txt

Copy that won_game.txt to a safe place. If you need the script again, you only need to repeat the last step.

Add translations of game rules

Currently game rules cannot have translations as the model doesn't support translating them. However GNOME Aisleriot comes with game rule translations for some languages. Taking these into use would allow translated game rules for some languages. Others should fall back into default language.

Locking screen leaves cards dragged

Locking screen while dragging cards leaves those cards being dragged still.

Steps to reproduce:

1. Drag some card(s), don't raise finger
2. Press power button on the other hand
3. Unlock the device

Cards are still being dragged although user is not touching them. The drag should have been canceled. Touching the dragged card will cancel the drag. Note that touching some other card will not help. Also now if the device is rotated the cards will not resize.

Shuffle in beleaguered castle

Please add ability to in-game shuffle cards not in foundation without restart current game or creating new game

Improvements to win animation

A basic version of win animation was implemented in #5 but that could be further improved. In particular I'd like to see more variation in the animations, perhaps different (selectable) animations, if there are enough viable ideas to implement. Feel free to tell about your ideas and experiment with the code. Note that there are some things you need to consider:

• Some games have stacks of cards per suit, like Klondike.
• Some games put those stacks to other positions on the table, like Beleaguered castle.
• Some games have single cards on the table, like Maze.
• Some games expanding stacks of cards, like Osmosis.
• Some games don't have any cards on the table at the end, like Helsinki.
• Some games have a combination of these, like Wall.

Yeah, it's a lot to consider. But any improvements, big or small are welcome to be discussed.

Support building from SDK's Qt Creator (shadow builds)

Support building from SDK's Qt Creator. Currently it is not possible because Patience Deck's build system doesn't support shadow builds. I think it should be possible to improve builds so that regular (non-harbour) version would support shadow builds. It wouldn't be quite out of the box builds as Guile and other libraries need to be built and installed first but it could make development more attractive for some developers. Harbour builds require complicated steps that might be a little too much to get working with shadow builds and rebuilding libraries takes a long time anyway, but even regular builds as shadow builds would be a good first step.