I haven't. It won't run on my Sierra system, but I'll probably install it on my MacBook Air (Mojave) box and give it a look.
-Chris
@peternlewis, can you confirm or refute that setting the KM Clipboard History to zero may cause problems? If so, can you please describe these problems?
Set the clipboard history to 0 simply means that Keyboard Maestro will not read the system clipboard when it changes - instead it will read it only when you perform an action that explicitly reads it (eg using the SystemClipboard token, or an action that has the system clipboard as an input).
However, if you set the Clipboard History size to zero, or you exclude an application from Keyboard Maestro’s clipboard history, then the Copy action will fail because it simulates a Command-C and waits for the clipboard to change, and the clipboard will not change because Keyboard Maestro will not read the clipboard.
It could be argued either way as to whether this is a bug in the Copy action or Keyboard Maestro behaving exactly as you have explicitly told it to. I'd probably lean towards the former, but this situation only happens if you explicitly tell Keyboard Maestro not to read the clipboard. You can use Command-C instead, since that is all the Copy action does - perform Command-C and wait for a clipboard change.
I will ponder whether to the behaviour of the action should change.
2 Likes
Wow! this is huge!
So, then the user should ==never set KM Clipboard History to zero==.
And, IMO, KM should prevent this from happening.
So if a user wants to minimize the storage used by the KM Clipboard History, then he/she should set to ==no lower than 1.==
I will update the KM Wiki to add this notice/alert.
Managing the KM Clipboard History
To all KM Users, here is my suggestion:
- Set the KM Clipboard History to a max of 100, unless you have some very specific workflow that needs more than 100. Honestly, I can't imagine what that would be. The KM default is 200 Clipboards.
- If you set the Clipboard to a large amount of data, then delete that Clipboard as soon as you don't need it any more. I almost always do this in the same Macro that created the Clipboard by using the Delete Past Clipboard action at the end of my macro.
If you find that either the KM Editor app and/or KM Engine is running much slower than previously, then double-check both the KM Clipboard History, and the KM Global Variables for large entries, and delete them if at all possible.
2 Likes
Hey Peter,
I have two specific comments.
-
A user should not have to troubleshoot this problem – there should be no problem. We've had this come up 3 times or so on the forum in the last year, and it's been a pain to diagnose.
⠀⠀a. The curious thing is that one or two of the users had NO
⠀⠀idea this setting had been changed on their system. (One did know.) -
In my opinion this is one place you need to overcome your reluctance to add new preferences. All good clipboard managers I've ever used have had such a setting. It's a disservice to the user to not let them adjust the setting without having to jump through hoops – most will NEVER even know there IS such a setting.
-Chris
1 Like
No, this is specifically the point, to disable Keyboard Maestro from reading the clipboard in general.
Setting it to 1 does not accomplish that, since Keyboard Maestro will still read the clipboard every time it changes, which for some badly behaved applications causes undesirably consequences. Generally it would be better to exclude them than set the history to 0, but the results would be the same either way.
This is exactly why I do not have a preference for this setting, and if I did it would only be within a range, and not down to 1 or 0.
Once people configure private settings they are off in the wilderness on their own, with consequences that cannot be predicted.
I think a range would be fine as long as it was flexible enough.
I despise the way Objective Development does LaunchBar's Clipboard History:
I want to be able to enter a specific number of items or days and not be limited to what they think is relevant. Unfortunately they haven't listened to my arguments over the years.
I have my Keyboard Maestro Clipboard History set to 500, and it's saved me from myself more than a few times.
-Chris
1 Like
Peter, this is very confusing, and somewhat contradictory.
I sincerely doubt that the large majority of KM users would want to cause the KM "Copy" Action, or the "Type a Keystroke of ⌘C" to ALWAYS fail.
I'm going to guess that the "Copy" Action, or some type of Clipboard processing is one of the most used functions of KM.
What does this mean? Are you referring to setting of KM Preferences by command line?
If that be the case, then you should provide a BIG WARNING at the top of that section of the KM Wiki that clearly states the danger of setting these preferences.
All of this points to the need to provide for setting of ALL KM Preferences via UI in the KM Preferences Window. There you could control and ensure valid settings, as well as provide a popup warning if the user is making a change that can have a major impact.
Why not put all of the preferences you currently provide via command line in the Preferences UI, in an "Advanced" tab that hides it from the user unless the user specifically clicks on that tab.
I never said that fails.
The Copy action times out because as far as Keyboard Maestro is concerned, the clipboard never changes.
The Command-C works in both cases, the clipboard is copied, Keyboard Maestro has just been instructed not to read it and so it does not change.
Yes. Any of those preferences can change at any time, or can have unexpected consequences. That is why they are not in the application.
And I have no desire to do that because that locks me in to what I can change in the future, which again, is why these preferences are not part of Keyboard Maestro proper.
Preferences and ancillary features have long term costs that have to be managed to ensure Keyboard Maestro can grow and change with minimal restrictions, and the hidden preferences are part of this, providing things that people want to do now, but without guaranteeing their support in the future.
Peter, I don't understand.
How does providing the preference in the Preferences Window lock you in any more than providing it in via command line?
Obviously you can change the preferences exposed in the UI any time you want to.
If you need to make a KM update that requires that the preference be changed or eliminated, then you can obviously also do that as part of the update.
By providing the preferences as part of the UI, you do this:
- Make it much, much easier for the user to make changes
- Provide a much more controlled environment for changing preferences, preventing the user from make invalid or improper changes.
By providing the "hidden" command line preferences in the Wiki, you make it much harder, and much more dangerous for the user to change preferences.
What happens if the user has made a change to the "unofficial" command line preferences, and you make an update to KM that requires that preference to be eliminated or changed?
I have adjusted the behaviour of the Copy action so that it does not timeout when the clipboard is not read (either because the application is excluded from the clipboard history or the clipboard history is limited to 0 entries). The clipboard is still not read by Keyboard Maestro in this case, not until it is actively used by an action.
2 Likes
So, after a Copy Action, if we have a Set Variable to Clipboard, will that work as expected?
Yes. It already does except that the Copy action will timeout, if you disable the timeout or use Command-C instead it would work fine now.