I'm trying to copy some strings into the clipboard with the mentioned action. When I try to paste it afterwards (e.g. CMD+V) the value is there, but any third party clipboard manager I use (I'm now using the one in BetterTouchTool) doesn't "see" the value there. It's like if the "Set System Clipboard..." actions are copying the value in some different way that they don't detect them.
To overcome this, I'm manually setting a variable and copying from within an AppleScript action, like this:
set executionInstance to system attribute "KMINSTANCE"
tell application "Keyboard Maestro Engine" to set varKM to getvariable "Local_VarKM" instance executionInstance
set the clipboard to varKM
It works and the clipboard managers pick up this "save", but I'd much rather use the native action than having to put this in every Macro where I need to copy something (and track it in the clipboard manager; as everything else that is copied in the system)
May I ask a stupid question, which is why not use the clipboard manager built into Keyboard Maestro? Are there features in BTT's manager that KM's doesn't have?
As for the specific issue, I don't use BTT so I can't really say, but perhaps the issue is that there's no such thing as a multi clipboard on macOS, so every app that offers one has to create their own solution for saving and listing clipboards. Perhaps whatever method BTT uses doesn't see the changes KM makes to System Clipboard (for who knows what reason), but does see changes made via AppleScript? That's a SWAG, though, as I have no real idea—only @peternlewis could answer that one.
But if you use KM's multi-clipboard manager, it'd be a moot point.
Does checking "Record concealed or application specific clipboard contents" in the History window's options help? It may be that BTT considers the KM action to be a "concealed" change.
Not a BTT user, just extrapolating from this thread.
Thanks for your replies @griffman and @Nige_S. Will try to answer your questions
I'm using BTT Clipboard Manager as I consider it to be less intrusive, smaller footprint, faster, and even can apply my own JavaScript (or GPT) transformations from there
I understand that using Keyboard Maestro Clipboard Manager would probably solve this, but that wouldn't be the right approach in my mind, as I consider its actions for "Copy" should work the same as any other macOS app and be agnostic to how any other Clipboard Manager work
As I commented, this is not a specific issue with that Clipboard Manager. It happens with others (e.g. PastePal) that I've tried, that don't pick up what Keyboard Maestro saves in the System Clipboard
After posting, while going to bed , I imagined someone would ask me if I had disable clipboard monitoring for the app or something similar, as I didn't specified it. Thanks for asking though; clipboard monitoring for the Keyboard Maestro app is enabled, it's not considering the data copy as "secure" (hence why it wouldn't show up), as manually copying (CMD+C) any text from the macros put them on the Clipboard Manager; as well as why my AppleScript, that runs within Keyboard Maestro, also "forces" the update of the Clipboard Manager
Thanks again for chiming in and hopefully there is a way to make it natively work
The text appears as expected. My only conclusion from this is that there must be something different about the clipboard manager for BTT (and the others you tested), as it seems to work fine here.
Did I put the values on the clipboard exactly as you did? If not, can you tell me the exact actions you used so I can replicate here?
Hi @griffman, thanks again for taking the time to look into this!
I recorded a quick video to try to answer your questions and show this strange behavior.
I've also simplified the AppleScript... now it's as simple (and silly) as:
set the clipboard to (the clipboard)
By running that "force" set of the clipboard, after the native Keyboard Maestro action, the Clipboard Manager is able to pick it up. What comes to mind is that maybe Keyboard Maestro is saving in a different entity that the clipboard AppleScript is referencing? I'm not sure how to articulate it better, but I think the video will clarify a little bit
No, it's being put onto the (one and only) System Clipboard. As I understand it, every time the System Clipboard changes a new index is generated and a change in index is the "usual" way to monitor the Clipboard -- an app has to check for that change, there's no "pasteboard has changed" event broadcast by the OS. Not a developer, so I could be very wrong!
Have you asked your question the other way round on the BTT forum? Why doesn't BTT detect when a Keyboard Maestro action changes the System Clipboard? That may shine more light on the issue.
In the meantime, you might want to consider this an unexpected feature! Instead of your BTT clipboard manager being overwhelmed with an entry for each and every KM-mediated clipboard change, you now get to pick and choose what gets recorded -- only use your AppleScript after those actions and you can control what does or doesn't become available to BTT.
Great idea! I just posted this issue there too. I would have to go and post in every community of the other Clipboard Managers I've been trying, but since I'm trying to size down, I'll probably stick with BTT by now, so that would be it.
I like your optic that now I get to pick and choose what values I keep in the Clipboard Manager . I think I'll have to get used to that, even though I'm capturing any and all captures (except passwords!) at the OS level, if neither @peternlewis or Andreas from BTT are able to see what is going on.
I'm surprised this hasn't come up before, considering how popular these two suites are with us automation freaks!
Keyboard Maestro seems to be marking everything as sensitive; hence why the Clipboard Managers I have been using aren't picking this up. I could disable this from BTT, but that would be crazy, as it works at OS level and would start picking up other sensitive information too.
@peternlewis could you please confim this is the expected behavior? Is every "Save to Clipboard" action marking the data as sensitive? Could you comment on the reasoning behind that?
@peternlewis are you marking everything as Transient maybe? Shouldn't only these Actions That Use The Clipboard be the Transient ones, and not the Actions that the user added to Save to Clipboard?
Still not a developer, but after a bit of futzing with this old sample code and Xcode, here's a screenshot immediately after copying a password from 1Pass:
Note the ConcealedType, which I assume is what Andreas means by "sensitive". After ~60 seconds of doing nothing except hit the "Reload" button, Viewer shows:
...and it's still there 5 minutes later, suggesting it isn't "transient".
"Application Specific" would also be surprising, given that I can paste that item into all sorts of apps -- unless clipboard managers are the only apps that honour that setting!
I have no idea what any of the above actually means, and will immediately defer to anyone who does! I would also again note that "Clipboard Viewer" is an old (Mac OS 10.7) demo Project, so may not be showing everything (or even be correct in what it does show), so pinches of salt all round.
But it has been a fun little rabbit hole to jump down...
BTT might be misinterpreting one of the pasteboard types in a voluntary pasteboard standard put together by a number of developers.
org.nspasteboard.source, which KM sets as seen above in @Nige_S' post, seems a likely candidate; BTT should check to make sure they're handling each pasteboard type correctly.
Thanks for all this research, guys! I already went back with this to Andreas from BTT, to check on his comments about this information, so I'd update back here when I hear back
Thank you for opening this discussion @Timmy256! I am not currently using the BTT clipboard manager, but remote desktop software – Citrix Viewer and Amazon Workspaces – which don't seem to pick up clipboard changes reliably in all situations, which has been puzzling me for quite a while already.
It is interesting that something as simple as set the clipboard to (the clipboard) apparently can make a difference; I will give it a try. Let's keep this thread updated with findings!
Indeed; it works with that! It's like it "forces" macOS to re-set the clipboard, maybe uses a different event, trigger, API; whatever. I have no idea what is going on, but the content appears in the Clipboard Manager after that