[PATCH] macdrv: Don't update clipboard if its content didn't change

[Ken Thomases]

On May 25, 2017, at 5:26 PM, Piotr Caban <piotr at codeweavers.com> wrote:
> 
> 
>> Unfortunately, -[NSPasteboard changeCount] isn't incremented for all changes to the pasteboard.  For example, if the owner replaces the data for an existing type, it doesn't change.  I'd have to check again, but I think it doesn't even change if the owner adds a new data type.  I think it only changes when the pasteboard is cleared and rebuilt by -clearContents or -declareTypes:owner:.
> 
> I wonder if applications that are doing it are using pasteboard API correctly.
…
> I’ve also checked the code of open source clipboard manager that works on Mac (Flycut) - as far as I can see it's looking for clipboard changes this way.

Well, I suspect that the vast majority of the time, apps work with the pasteboard in a way which does allow another app to poll the change count to be informed of the changes.  I'd even go so as to say that that's the "normal" way of working with the pasteboard.  However, the API allows for the operations that in fact change the data on the pasteboard but which don't increment the change count.  I don't think such uses of the API are incorrect, just uncommon.

> The documentation says that “application can determine whether the current data in the pasteboard is the same as the data it last received” by checking changeCount value.

The docs also say, "The change count … increments every time the contents of the pasteboard changes (a new owner is declared)"[1] and, "The change count … increments each time the pasteboard ownership changes."[2]  Those suggest it's tied to the methods which specifically take ownership of (and clear) the pasteboard.

[1] https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/PasteboardGuide106/Articles/pbConcepts.html#//apple_ref/doc/uid/TP40008101-SW6
[2] https://developer.apple.com/reference/appkit/nspasteboard/1533544-changecount?language=objc


I'll have to run some tests again to see exactly which operations do and don't increment the change count.  I'll let you know what I find.

It may be that your patch is better for the vast majority of the cases such that we should commit it.  We'll just accept incorrect behavior for the (hopefully) rare aberrant uses of the API that I'm concerned about.  Or maybe we can take a belt-and-suspenders approach and check both the change count and the list of types.

-Ken