There are correctness issues with the information you put on the pasteboard. Here is one correctness issue, and one issue which could be improved.
The best way to see what is being put on the pasteboard is to use Pasteboard Viewer, a free app. Run it, right-click on a note in Bear.app, and from the context menu say “Copy Link to Note”. See what Pasteboard Viewer says that you’re putting on the pasteboard.
The correctness issue: you create two pasteboard items, not one. Both items have a net.shinyfrog.bear.note-uuid-pasteboard-type flavor, but only the second item has data in it. This makes me think that you have a bug where you are intending to populate that flavor on the first item, but accidentally creating a second item with that flavor. I’m not sure how it’s intended to be used, but that probably should be fixed.
Even better: select two items, and select “Copy Links to Notes”. The pasteboard gets three items! The first item has an emptynet.shinyfrog.bear.note-uuid-pasteboard-type, and the second and third items get valid net.shinyfrog.bear.note-uuid-pasteboard-types. You definitely have some off-by-one issue here.
The improvement issue: you have a flavor net.shinyfrog.bear.url-name. OK, but you should use the public.url-name flavor instead. It used to be an official Apple flavor, and while it’s not in the headers any more, it’s used by every major Mac web browser as well as the Finder. See my notes about it in the Chrome source repro.
If you have any questions, please feel free to send them my way.
I’m unsure if this is a PasteBoard or the app issue but I don’t see in Bear’s code a valid reason for the second item to be created. PB should contain only one element with 4 representations (Internal, URL, internal URL name, string). Two of those are only used internally by design because if you paste in Bear you get a [[wiki link]] but if you paste outside you get bear://x-callback-url/open-note.... The internal wiki link conversion can’t work if the internal representations of the items are empty.
IIRC this causes the link to no longer be pasted in some rich text applications as bear:// but as an RTF link and we don’t like this.
Are you trying to achieve something specific with Bear’s pasteboard?
I assume this is re the first issue. I’m not saying that you should create two items when saying “Copy Link to Note”. I’m saying that you currently do, and that it makes no sense and you should fix it. Whether or not you see where you’re doing it, you are doing it (as evidenced by the Pasteboard Viewer app that looks at what was actually put onto the pasteboard).
I’m not trying to achieve something specific, just general interoperability. If that’s what you’re seeing, then no worries.
Yes, I meant to say I checked the code, and the item should be one. Further investigations seem to indicate that 2 items are created by NSPasteboard’s writeObjects regardless of the number of items passed. I’m unsure if we can replace this API.
...and that it makes no sense and you should fix it.
Maybe. Based on my experience, pasteboard management is complex and often based on compromises. Sometimes we can work as expected while having the user experience we want and sometimes we don’t.