https://bugs.kde.org/show_bug.cgi?id=279229 --- Comment #4 from Bryan 2011-11-08 20:01:27 --- "Checking for "manual undos" seems silly. If the user knows that a move is going to be a manual-undo, why don't they just hit Undo?" The checking to see if a move is manually undo-able (to the last position) was to save time, instead rechecking solve-ability; If a move can be manually undone(aka the card can go back to where it was before the move without the undo button), then the solve-ability would be the same after the move as before the move. It's like the "propagating solvability backward through the history and unsolveability forward through the history" except without hitting the undo button. For simplicity, it can check if the moved card can move back to where the card was before the move. If it can then it can, then the previously calculated solve-ability(if available) could be used. Of course, you'll still have the problem of the solver not being perfect. "The problem is that the solver isn't perfect; it produces both false positives and false negatives. Trying to extrapolate from false information only compounds the problem by increasing amount of false information." [idea only, might not actually improve things] Maybe a more exact solve-ability could be used, even if it takes more time, so that solve-ability propagation would make since. Or make solve-ability propagation optional, and add a warning about accuracy* if enabled, and/or add an option to do it both ways, aka propagate for immediate answer*, and recalculate for more accurate answer. *If the solver is inaccurate it might have an item in the past that says unsolvable, and an item in the future that says solve-able, maybe this could turn into saying 'unknown'? or even a submit to developer case? -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.