Bug 185101

Summary: Clipboard and selection do not synchronize after gitk actions
Product: [Unmaintained] klipper Reporter: Vivien Mallet <Vivien_Mallet>
Component: generalAssignee: Esben Mose Hansen <kde>
Status: RESOLVED NOT A BUG    
Severity: normal    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Vivien Mallet 2009-02-21 10:25:26 UTC 
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Ubuntu Packages

In its default configuration, gitk auto-selects the SHA-1 while moving from one commit to another. It changes the selection (mouse middle click), but klipper does not synchronize the clipboard then (except with the first SHA-1).

Illustration:
1) Configure Klipper so that clipboard and selection should be synchronized.
2) Launch gitk in a Git repository.
3) Check your selection and your clipboard. Both should contain the SHA-1 for HEAD.
4) Move to another commit (move down).
5) Check your selection and your clipboard. The selection has been updated to the SHA-1 of the selected commit, while the clipboard still contains the SHA-1 for HEAD.

Note: in 5), you need to have gitk still open. Indeed, if you open gitk, move to a given commit and close gitk, the selection will contain the SHA-1 for HEAD. The selection seems to be updated only if you actually paste it while gitk is still open.
Comment 1 Esben Mose Hansen 2009-11-28 12:21:45 UTC 
This is a bug in gitk.

X apparently isn't notified of the change, so Klipper cannot act upon it. It does, though, when if you select something else in gitk and then clicks on another revision. 

I agree it is highly annoying