Skip to content

Implement clickable moves in analysis variation & SPACEBAR for best engine's move + an important fix of the truncation problem - #109

Open
chessavidplayer wants to merge 10 commits into
Isarhamster:masterfrom
chessavidplayer:patch-1
Open

Implement clickable moves in analysis variation & SPACEBAR for best engine's move + an important fix of the truncation problem#109
chessavidplayer wants to merge 10 commits into
Isarhamster:masterfrom
chessavidplayer:patch-1

Conversation

@chessavidplayer

@chessavidplayer chessavidplayer commented Apr 28, 2026

Copy link
Copy Markdown

This change allows users to click individual moves within an engine's analysis variation. Clicking a move will add the variation to the game up to that specific move, rather than adding the entire line. Standard functionality for the [+] and [*] buttons remains unchanged. UPD! Chessbase-like feature SPACEBAR for pasting best engine's move into the notation implemented as well

This change allows users to click individual moves within an engine's analysis variation. Clicking a move will add the variation to the game up to that specific move, rather than adding the entire line. Standard functionality for the [+] and [*] buttons remains unchanged.
Added slotSpacebarPressed declaration and QShortcut header
Updated the AnalysisWidget constructor to initialize a QShortcut for the Spacebar. Refined slotLinkClicked and updateAnalysis to support clickable engine moves and instant variation insertion via keyboard
@chessavidplayer chessavidplayer changed the title Implement clickable moves in analysis variation lines Implement clickable moves in analysis variation & SPACEBAR for best engines' move Apr 28, 2026
@chessavidplayer chessavidplayer changed the title Implement clickable moves in analysis variation & SPACEBAR for best engines' move Implement clickable moves in analysis variation & SPACEBAR for best engine's move Apr 28, 2026
Fixing the problem with duplication of moves after stripping the moves from the beginning
Had to revert it back. The previous alleged improvement turned out to be buggy - it was fixing correct move numbers for White only, still adding one move for Black, and killing move numbers in engine analysis
This version truncates moves for White correctly, adds one additional move number for Black. Still an improvement. I am working on solution
Reverted back to the default ChessX version of the code - gamecursor.cpp turned out to have no impact on the truncation problem
The problem with wrong numbers after truncation finally fixed - just two strings of code got modified and problem is gone!
@chessavidplayer chessavidplayer changed the title Implement clickable moves in analysis variation & SPACEBAR for best engine's move Implement clickable moves in analysis variation & SPACEBAR for best engine's move + an important fix of the truncation problem May 18, 2026
@chessavidplayer

chessavidplayer commented May 18, 2026

Copy link
Copy Markdown
Author

In my humble opinion, the fix related to the wrong numbering after truncation should be implemented into the official version of ChessX, as it helps to get rid of the annoying bug. Other two functions implemented here ("clickability" and "pasteability" of engine moves + SPACEBAR for adding engine moves to the notation) look nice too, but those are just optional features

@limitedAtonement

Copy link
Copy Markdown

The last seven commit messages are bad. Please explain why each commit was introduced. (By the way, I'm not the maintainer of this project, so take my comments here accordingly.)

There are a good deal of editorial changes that have no good reason (if anything, they break from the existing style of the project, so should not be introduced). Also, many comments are removed. I agree that some of the comments are superfluous, but some are very useful to people new to the codebase. In short, don't just make changes without solid justification.

@chessavidplayer

Copy link
Copy Markdown
Author

The last seven commit messages are bad. Please explain why each commit was introduced. (By the way, I'm not the maintainer of this project, so take my comments here accordingly.)

There are a good deal of editorial changes that have no good reason (if anything, they break from the existing style of the project, so should not be introduced). Also, many comments are removed. I agree that some of the comments are superfluous, but some are very useful to people new to the codebase. In short, don't just make changes without solid justification.

You are absolutely right! But please don't be harsh on me - I am a vibe-coder (no jokes!) and it's my first pull request. Frankly speaking, I don't hope for the full implementation of the whole code I published. I just wanted @Isarhamster to look at some ideas potentially useful for the main project. For instance, the truncation problem is truly annoying in the official version and the small fix in the output.cpp solves it. That's actually all I hope for!

@limitedAtonement

Copy link
Copy Markdown

You are absolutely right! But please don't be harsh on me - I am a vibe-coder (no jokes!) and it's my first pull request. Frankly speaking, I don't hope for the full implementation of the whole code I published. I just wanted @Isarhamster to look at some ideas potentially useful for the main project. For instance, the truncation problem is truly annoying in the official version and the small fix in the output.cpp solves it. That's actually all I hope for!

Pardon me if I am direct and blunt and forego flowery language. No harshness intended.

It sounds like you have two goals with this PR: 1) to fix a particular bug, and 2) to provide some code changes to consider. For the first, you should issue a pull request that is of sufficient quality for the maintainer to be able to press "merge PR" with a clean conscience. The other is for the maintainer's general consideration perhaps without any intend of the pull request being pulled as is?

Thank you for contributing!

@chessavidplayer

Copy link
Copy Markdown
Author

You are absolutely right! But please don't be harsh on me - I am a vibe-coder (no jokes!) and it's my first pull request. Frankly speaking, I don't hope for the full implementation of the whole code I published. I just wanted @Isarhamster to look at some ideas potentially useful for the main project. For instance, the truncation problem is truly annoying in the official version and the small fix in the output.cpp solves it. That's actually all I hope for!

Pardon me if I am direct and blunt and forego flowery language. No harshness intended.

It sounds like you have two goals with this PR: 1) to fix a particular bug, and 2) to provide some code changes to consider. For the first, you should issue a pull request that is of sufficient quality for the maintainer to be able to press "merge PR" with a clean conscience. The other is for the maintainer's general consideration perhaps without any intend of the pull request being pulled as is?

Thank you for contributing!

Yes, you are right. Two features are just for consideration and one about fixing a particular bug. I simply didn't know how to let the project owner know about my ideas apart from making a pull request.

@chessavidplayer

Copy link
Copy Markdown
Author

To pity, the alleged fix also turned out to have a bug - moves in the notation widget start from move 1, after saving the file and closing the program. However, it seems I found the real fix, but now I need an advice what to do. This pull request became messy and I plan just to close it and open a new one with a clean single fix for that bug in output.cpp Is that what I should do @Isarhamster ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants