Bug 185101 - Clipboard and selection do not synchronize after gitk actions
Summary: Clipboard and selection do not synchronize after gitk actions
Status: RESOLVED NOT A BUG
Alias: None
Product: klipper
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Esben Mose Hansen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-21 10:25 UTC by Vivien Mallet
Modified: 2009-11-28 12:21 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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