Pasteboard Source

13 views
Skip to first unread message

Peter N Lewis

unread,
Dec 6, 2016, 2:51:36 AM12/6/16
to nspast...@googlegroups.com
Is there any standard for specifying the source application?

I'm thinking of showing an icon for the application with the clipboards in the clipboard history, but the pasteboard does not appear to have any way to get the source application. Once can assume that it is the front application, but that would not be the case if it was, for example, Keyboard Maestro does it, or any other background utility.

It'd be nice to know the clipboard came from the Universal Clipboard of an iPhone, but that's probably being overly hopeful.

An obvious simple solution is simply a flavor (maybe org.nspassteboard.source?) that holds a Bundle ID of the source application.

Is there any such existing techniques? Or failing that, any objection to using org.nspassteboard.source in such a way?

Thanks,
Peter.

--
Keyboard Maestro <https://www.keyboardmaestro.com/> Editors' Choice Award winner.
Macros for your Mac <https://download.keyboardmaestro.com/>
Join us on the Keyboard Maestro forum <https://forum.keyboardmaestro.com/>

Günther Blaschek

unread,
Dec 6, 2016, 3:07:50 AM12/6/16
to nspasteboard Google Group, Peter N Lewis
Hi Peter,

No, I don't think there is any way to identify the application that put something on the clipboard.

Even if we (the "NSPasteboarders") agree on using a special flavor for that, most other applications would not supply such information. But maybe you can send a feature request to Apple? They could easily add information about the current process when the pasteboard is populated.

There is one more thing to consider: What would you expect as the "source" when the user did a Copy in application A, and then the clipboard was saved and later restored by B? I guess you would expect A (as the original or "logical" source), but if Apple added the information, they would not be able to distinguish original contents from restored contents.

Anyway, if anybody uses this new flavor, please do not copy/paste the flavor name "org.nspassteboard.source". It should be "org.nspasteboard.source", to avoid a repetition of the "referer" issue. :-)

All the best,
gue



--
gue = Günther Blaschek

Thomas Tempelmann

unread,
Dec 6, 2016, 6:09:56 AM12/6/16
to nspasteboard Google Group
I (speaking for iClip) agree with Günther and would support the use of a new flavor for that.

And if Peter makes the effort to file a radar for a request as Günther suggests, and posts that on openradar.me, I'd be happy to copy it and file a duplicate for support :)

Thomas

--
Thomas Tempelmann
Irradiated Software

Brian Bucknam

unread,
Dec 6, 2016, 2:20:12 PM12/6/16
to nspasteboard Google Group
Hi Group,

I don’t know of any way to determine the source application, but agree it could be very useful.

Getting Apple to add something seems like the definitive way, but since that may never happen, adding “org.nspasteboard.source” with the bundleID of the app makes sense to me. Glad to see others agree as well. Maybe little source icons in pasteboard history would become the useful tidbit that finally leads to more widespread adoption of NSPasteboard standards :-)

Cheers,
Brian

Peter N Lewis

unread,
Dec 6, 2016, 10:06:35 PM12/6/16
to nspasteboard Google Group
OK, good then.

So the assumption (in the general absence of any other information) is that the current foreground application is responsible for the clipboard, but if you are a background app, or if you want to make it explicit, you can use the flavour:

org.nspasteboard.source

(spelled correctly, sigh ;-)

which contains a bundle ID which is the Application Bundle ID of the source of the clipboard as a string.

Potentially down the track there might be special case bundle IDs for things like universal clipboards, but where possible (and for ongoing backward compatibility) it should be an application bundle ID as users will likely display the associated application icon as the responsible party.

There would generally be no need for most applications to set this flavour as they typically only change the clipboard while they are the foreground application anyway, but there is no harm in setting it universally if desired.

Can someone add that to the http://nspasteboard.org site?

I will start using it in a future version of Keyboard Maestro.

Once it is on the site as a spec, I will do a radar/openradar to ask Apple to support it, especially for universal clipboard, and post for duplication here.

Thanks,
Peter.

Peter N Lewis

unread,
Dec 7, 2016, 2:55:06 AM12/7/16
to nspasteboard Google Group
On 7 Dec. 2016, at 11:06, Peter N Lewis <pe...@stairways.com.au> wrote:
> which contains a bundle ID which is the Application Bundle ID of the source of the clipboard as a string.

Sorry, this should be more clearly specified since flavours are pure data, not typed, this should be "as a UTF8 string" (kCFStringEncodingUTF8, same format as public.utf8-plain-text). It will rarely make a difference since most bundle IDs are pure ASCII. But it should be clearly specified.
Peter.

Thomas Tempelmann

unread,
Dec 7, 2016, 5:28:36 PM12/7/16
to nspasteboard Google Group
On Wed, Dec 7, 2016 at 4:06 AM, Peter N Lewis <pe...@stairways.com.au> wrote:
if you are a background app, or if you want to make it explicit, you can use the flavour:

And, as suggested earlier, an app that records a clipboard's contents and later puts them back into the clipboard, should add the original app's bundleid, i.e. not insert its own bundle id, unless the content was modified or created by that app.

And to state the obvious: This is meant to be shown to the user by a supporting app, as an informational value only.

Agreed?

Greg Scown

unread,
Dec 13, 2016, 6:22:28 PM12/13/16
to Peter N Lewis, nspasteboard Google Group
Hi Peter,

We've gone ahead and updated nspasteboard.org as requested.

Regards,

==> Greg

Thomas Tempelmann

unread,
Dec 15, 2016, 7:28:34 AM12/15/16
to Greg Scown, Peter N Lewis, nspasteboard Google Group
On Wed, Dec 14, 2016 at 12:22 AM, Greg Scown <gsc...@gmail.com> wrote:
Hi Peter,

We've gone ahead and updated nspasteboard.org as requested.

> On Dec 6, 2016, at 7:06 PM, Peter N Lewis <pe...@stairways.com.au> wrote:
>
> org.nspasteboard.source

>
> which contains a bundle ID which is the Application Bundle ID of the source of the clipboard as a string.

I just wonder - what's an efficient way to learn an app's name from the bundle ID? As a clipboard recorder, I assume I can expect that the app filling the clipboard with this data would still be running, so I'd probably inquire about all running processes and check which one uses the given bundle ID. Using Launch Services would probably be disadvantageous because it may incur longer search times, or won't it?

Peter, how do you plan do implement this?

Thomas

Peter N Lewis

unread,
Dec 15, 2016, 7:44:05 AM12/15/16
to nspasteboard Google Group

> On 15 Dec 2016, at 20:28, Thomas Tempelmann <tho...@irradiatedsoftware.com> wrote:
>
> I just wonder - what's an efficient way to learn an app's name from the bundle ID? As a clipboard recorder, I assume I can expect that the app filling the clipboard with this data would still be running, so I'd probably inquire about all running processes and check which one uses the given bundle ID. Using Launch Services would probably be disadvantageous because it may incur longer search times, or won't it?
>
> Peter, how do you plan do implement this?

Keyboard Maestro builds a list of applications for other purposes already, so I already have an internal map.

By NSRunningApplications (broken API that it is) can be instantiated from a bundle ID with runningApplicationsWithBundleIdentifier, which I presume would work in most cases.

Otherwise Launch Services, possibly with a cache, would work. I imagine only a very very small number of apps will ever use this facility - most apps only ever change the lclipboard when they are the front app anyway.

Regards,

Thomas Tempelmann

unread,
Dec 20, 2016, 11:02:31 AM12/20/16
to nspasteboard Google Group
BTW,
would please everyone who adds support for this state that fact here on the list, with the app's name. That's way, us other can claim "works well with ..." in their own apps, which I'd certainly like to do.

Peter wrote:
Otherwise Launch Services, possibly with a cache, would work.  I imagine only a very very small number of apps will ever use this facility - most apps only ever change the lclipboard when they are the front app anyway.

I have users that also use PopClip or Yoink. I wonder if those are on this list, too?

Thomas
 

Nick Moore

unread,
Dec 20, 2016, 12:55:34 PM12/20/16
to NSPasteboard.org


On Tuesday, December 20, 2016 at 4:02:31 PM UTC, Thomas Tempelmann wrote:
I have users that also use PopClip or Yoink. I wonder if those are on this list, too?

PopClip dev here! I've only just joined the mailing list.
(*ducks* .... now you all know who to abuse when you get support requests from PopClip users)

Thomas Tempelmann

unread,
Dec 20, 2016, 2:34:06 PM12/20/16
to NSPasteboard.org
So, I assume that Keyboard Maestro will have this feature implemented by now? Is it out already, Peter?
Anyone else working on supporting it?

I have an update imminent for iClip, adding that key to the Info.plist in order to make my apps stop running on the GPU all the time. I plan to add support for this by then as well. iClip does already record the front app's bundle ID by default anyway.

Peter N Lewis

unread,
Dec 20, 2016, 8:50:33 PM12/20/16
to NSPasteboard.org
On 21 Dec 2016, at 03:33, Thomas Tempelmann <tho...@irradiatedsoftware.com> wrote:
> So, I assume that Keyboard Maestro will have this feature implemented by now? Is it out already, Peter?

It will be in 8.0, which wont be released for a long time yet.
Reply all
Reply to author
Forward
0 new messages