fixed: cappuccino pasteboad is always clobbered by system pasteboard

[daboe01]

previously, every native nativePasteEvent: compared the pasted content to [pasteboard _stateUID], which is always undefined in the current implementation of CPPasteboard. This resulted in a call to pasteboard declareTypes:[CPStringPboardType] owner:self, effectively removing all other representations during each paste.

This PR makes capp to only call [CPStringPboardType] owner:self if the system and capp CPStringPboardType actually differ. This makes the system and capp pasteboards cooperate. This is a prerequisite for proper copy/paste support of the new text system.

Fixes #2062 and
daboe01/CPTextView#109

[cappbot]

Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.

[daboe01]

-#new
+#needs-review

[daboe01]

+AppKit

[cappbot]

Milestone: Someday. Labels: #needs-review, AppKit. What's next? This issue is pending an architectural or implementation design decision and should be discussed or voted on.

[daboe01]

@aljungberg can you take a look please?

[daboe01]

@aljungberg are you still around?

[cappbot]

Assignee: aljungberg. Milestone: Someday. Labels: #needs-review, AppKit. What's next? This issue is pending an architectural or implementation design decision and should be discussed or voted on.

[cappbot]

Assignee: aljungberg. Milestone: 0.9.10. Labels: #needs-review, AppKit. What's next? This issue is pending an architectural or implementation design decision and should be discussed or voted on.

[aljungberg]

Hmm but if nothing was pasted into _DOMPasteboardElement, then value.length would be 0 and nothing would be written to the pasteboard.

And it the user did paste a string, wouldn't we expect the pasteboard to only have a string in it (and remove all other representations)?

[daboe01]

@aljungberg please consider this use case:
the user has plain and rich representations of the same text on the pasteboard (this can happen with the new CPTextView, see discussion in this issue: daboe01/CPTextView#109).

the user decides to paste twice, starting with a plain field and then into a rich text view. Without this patch, the first paste will remove the rich representation of the pasteboard and the user will never get the rich text pasted in.
With this patch, the rich representation is pasted into the rich text view as expected.

[daboe01]

from looking into _generateStateUID from CPPasteboard.j, comparing _stateUID and value does not make sense anyway.

[mrcarlberg]

Merged! Thanks!

If this PR creates problems we have to fix them later. It is needed for #2068.

[cappbot]

Assignee: aljungberg. Milestone: 0.9.10. Labels: #fixed, AppKit. What's next? This issue is considered successfully resolved.