Accordance and the Pasteboard

[countach]

There are a number of Mac programs which keep track of a history of past copies to the pasteboard. Jumpcut is one such example:

http://jumpcut.sourceforge.net/

 

The way these programs work is that at short intervals, the program polls the pasteboard, and if it has changed then it adds the new entry to the history.

 

Something quite odd happens with Accordance that doesn't happen with any other program. Most of the time if one copies some text to the pasteboard, Jumpcut gets two entries. Seemingly, one entry is unicode, and the second entry is perhaps some other encoding.

 

This would seem to indicate that Accordance is interacting with the pasteboard twice.

 

Is there something odd about how Accordance does things?

[Helen Brown]

Yes, if you set Accordance to export to Unicode it puts that on the clipboard when you copy in case you leave the program, and it puts our usual non-Unicode text as well, in case you paste into Accordance.

[countach]

Yes, if you set Accordance to export to Unicode it puts that on the clipboard when you copy in case you leave the program, and it puts our usual non-Unicode text as well, in case you paste into Accordance.

 

Almost all mac programs put stuff on the pasteboard in different formats. At a minimum, NSstringPBoardType, and NSRTFPBoardType from memory, plus any other app specific types the app needs. But there still seems to be something different about what Accordance does. Normally a program like jumpcut would pick up the standard string or RTF entry from the pasteboard and ignore any app specific formats it doesn't know about. That it picks up the non unicode version seems to indicate accordance puts a non unicode string into the standard NSRTFDPBoardType slot rather than in an app specific slot.

[Scott Knapp]

Accordance is a Carbon application. When copying text to the clipboard with the Unicode Export option enabled two "flavors" of the copied text are added to the clipboard. One is a standard Mac plain text version(using MacOSRoman encoding), the other is a plain text Unicode version. Both are valid Mac plain text types; neither is an Accordance specific type. Cocoa applications like JumpCut support only one plain text type:NSStringPBoardType which conforms to both Carbon plain text types. So it's no surprise to see JumpCut list both flavors of the text as available for pasting.

 

HTH,

 

Scott.

[countach]

I don't know much about Carbon, but I don't think this accounts for what is happening.

 

Firstly, in any one slot such as NSStringPBoardType slot, you can only store one thing. If you want to store UTF and some other encoding, you would have to use a different slot.

 

Secondly, what Jumpcut sees at one instant is different to what it sees a fraction of a second later. The reason Jumpcut stores two different things is not because there are two different encodings in the pasteboard, but because the pasteboard is updated twice. I might note for completeness that both NSStringPBoardType AND NSRTFPBoardType are both updated within this fraction of a second, the first time with non-UTF and the second time with UTF.

 

My conclusion is that this is an Accordance bug. Maybe there is some obsolete code getting called to update the pasteboard one way, and then the newer code updates it with UTF and obliterates the work done with the first update. Nobody is likely to see this unless they are using a program like Jumpcut which can see what happens in this fraction of a second.

 

Could the Accordance Staff confirm if this is the case? I'd like to fix some code I'm working on to work properly with Accordance, but I don't think the problem is at my end.

[Helen Brown]

Accordance is a mature and massive program, first released in 1994. We have a team of programmers who are working through the code systematically to bring it all into line with the latest methods, but I agree that this is probably an example of legacy code. I do not know when they will get to it, so you can plan your workaround and assume that this is how Accordance works, at least for the time being.

 

We often feel as if we are running faster and faster just to stay in one place, as Apple changes its technologies and updates the system so often. We would rather get to all the exciting new features that we and our users have dreamed up, but instead we spend most programming time keeping Accordance current. The only alternative would be to stop development of the existing code, and rewrite the entire code from scratch over several years. That's what Nisus did, but we do not think that our users would be happy with such a plan.

 

Sorry, this little rant is rather off the topic of the pasteboard.

[Scott Knapp]

I don't know much about Carbon, but I don't think this accounts for what is happening.

 

Firstly, in any one slot such as NSStringPBoardType slot, you can only store one thing. If you want to store UTF and some other encoding, you would have to use a different slot.

This is not really correct. See below....

 

Secondly, what Jumpcut sees at one instant is different to what it sees a fraction of a second later. The reason Jumpcut stores two different things is not because there are two different encodings in the pasteboard, but because the pasteboard is updated twice. I might note for completeness that both NSStringPBoardType AND NSRTFPBoardType are both updated within this fraction of a second, the first time with non-UTF and the second time with UTF.

 

Again, you are talking about Cocoa Pasteboard types. Accordance uses Carbon Pasteboard types. Specifically 'TEXT' for MacRoman encoded text and 'utxt' for Unicode. These types may or may not have text style information with them in the pasteboard ('styl' and 'ustl' respectively). How these flavors get mapped to Cocoa Pasteboard types is up to Apple.

 

My conclusion is that this is an Accordance bug. Maybe there is some obsolete code getting called to update the pasteboard one way, and then the newer code updates it with UTF and obliterates the work done with the first update. Nobody is likely to see this unless they are using a program like Jumpcut which can see what happens in this fraction of a second.

 

Could the Accordance Staff confirm if this is the case? I'd like to fix some code I'm working on to work properly with Accordance, but I don't think the problem is at my end.

 

I'm sorry but I respectfully disagree with your conclusion. We follow a fundamental Apple principle when doing a copy to the clipboard: Put as many representations of the data that make sense into the clipboard. This is so that when pasting information into an application there might be a representation of the data the application can use. An analogous example would be copying an image to the clipboard. To fully support pasting into as many applications as possible it might make sense to add a PICT flavor, a PDF flavor, a JPG flavor, etc. of the image. These are not distinct and separate copies to the clipboard but a single copy of the data containing many representations. This is what we are doing when copying text to the clipboard. We are adding two representations of the text data: one is MacRoman encoded text and the other is Unicode.

 

You can also do the same thing with Cocoa pasteboards. Nothing prevents an application from adding text to the Pasteboard in two (or more) representations including NSStringPBoardType and NSRTFPboardType.

 

Scott.

[countach]

Nothing prevents an application from adding text to the Pasteboard in two (or more) representations including NSStringPBoardType and NSRTFPboardType.

 

Sure, but one doesn't usually find the pasteboard returning MacRoman now, and .05 seconds later returning UTF instead. Apple may map Carbon to Cocoa pasteboard types, one wouldn't expect them to be mapped and then momentarily remapped a different way.

 

As I said originally, most Mac programs add multiple types to the pasteboard, but they don't exhibit this inconsistent behavior. The question is why Accordance is odd boy out.

[Scott Knapp]

countach,

 

I went and downloaded the Jumpcut source code so I could look at what they are doing. I also reviewed the Accordance source code handling copying to the clipboard and drag and drop actions more carefully. I'm now convinced that this is likely an Apple bug. And here's why: We put the same information in the clipboard for a copy action and a drag and drop action. Both actions should put the same information into the pasteboard. A drag and drop of selected text (with Unicode exporting on) to another application will update the Jumpcut menu correctly but a copy to the clipboard will not. You can look for yourself with a tool like Pasteboard Peeker to verify that the information is the same in both cases.

 

That being said, we are using some older APIs for our copying and drag and drop actions to maintain compatibility with our 68K version of Accordance. There are some things we can do on our end to improve this experience and probably increase the compatibility with applications that rely on the Cocoa pasteboard. Thanks for pointing the issue out.

 

Scott.