Version: unspecified (using KDE 4.5.0) OS: Linux As seen in Eric's Ultimate Solitaire. Grab a card (or stack) and "flick" it in the general direction of the intended destination. The program guesses where you intended to move the stack and moves it there. Reproducible: Didn't try Steps to Reproduce: Hold down LMB on a card and quickly move the selected stack towards it's destination. While rapidly dragging, release the mouse button. Actual Results: Releasing the mouse button mid-drag sends the stack back to it's origin. Expected Results: After release, the stack will "fly" the rest of the way, landing in the spot the user most likely intended. Can use the solver to find the closest match with the drag actions' trajectory.
Created attachment 89472 [details] Patch to drop card on "best" location by double click and bug fix for spider solver This patch implements an alternative solution to the "card tossing" suggested here: It basically enhances the double left click and (single) right click mouse bindings, so that they can not only used to move a single card to the foundation, but to be also able to move any number of cards (as long, as legal) to another pile or to an empty slot. As implemented in detail in the patch for the games "Simple Simon" and "Spider", the method checkAdd() is superceded by checkPreference(), which returns an integer, determining how well the card fits into the given location. Generally, Preference should be highest for Foundations and lowest for limited ressources like empty spaces. For spider, for example, the preference is higher to put a card on a pile with a matching suit (because then the old cards there and the new cards may be moved together in the next move) than on a pile with a non-matching suit. Lowest preference is for empty spaces. Some patience games already have a single click binding for the left mouse button, namely "Golf" and "Idiot" (the German name of the later is "Asse hoch" - "Aces up"), that have restricted move possibilities. Spider allows complex moves, but the "best guess" algorithm above does determine the right destination in 80 to 90% of the cases. Therefore, "click playing" spider is much faster than conventional drag & drop. Therefore, I have also added a binding for single click on the left mouse button to "spider". Many smartphone/tablet Apps for playing spider, that I have seen, have a similiar binding. For other games, that binding could easily be added, to, by putting the line: connect( this, SIGNAL(cardClicked(KCard*)), this, SLOT(tryAutomaticMove(KCard*)) ) into the function GAME::inititalize() In addition to enhancing automove, this patch also contains a completely new implementation of SpiderSolver::get_possible_moves() . The old implementation tended to errenously claim winnable positions as unwinnable (see for example Bug Reports 326932 und 336233). This was due to optimizations in get_possible_moves(), that return only a subset of the possible moves to favour what were considered "good" moves. Unfortunately, sometimes the "bad" moves were required to win. The new implementation of get_possible_moves() decides about the "bad" moves on a different basis: If a "good" move (like one, that turns a card or frees a space) can directly follow a "bad" move (one, that splits up a set of already arranged cards), then the bad move is still considered. Otherwise, it is disregarded. There are some scenarios, where this concept might still claim false losses, especially, when "bad" moves are required to arrange the cards in such a way, that the next deal fits nicely onto the cards. However, considering those types of alignment with the cards to be drawn next would cause a HUGE expansion to the search tree and consideration of many more moves, that have also been disregarded for good reason (like moving a set of cards to the second or third empty space, or moving sets forth and back between spaces). I have seen the new solver report spider games as solvable at very early stages in the game, when two dozens cards were still face down and four more decks to be dealt out. I have never seen the old solver see a solution that early in the game. I also have not seen wrong "unsolvable" messages, so I believe, the new solver is a big step ahead.
Kai, thanks for the patch. Given its size, it is hard to review within this bug tracker. Would it be possible to split it per feature/bug and post a review request for them individually on https://git.reviewboard.kde.org/ ?
Kai, any success with reviewboard?
*** Bug 249812 has been marked as a duplicate of this bug. ***