On 11/06/2013, at 18:01 , Thomas Tempelmann <
tho...@irradiatedsoftware.com> wrote:
> (Now that I read the rest of your mail I realize that Keyboard Maestro seems
> to do the same as you state that it records images as well, for instance.
> Haven't you run into cases where you wished you wouldn't have to read the
> entire contents because they're getting huge?)
Nope - its never been an issue. It's only one of potentially dozens of clipboards stored, so to read one more makes little difference in practice.
> My tool also adds the "RestoredType" marker when it restores a clipping (at
> user's request) that is from ist recording history, i.e. it is not just the
> same as the one before a transient clipboard.
>
> This "restored" marker tells others that they've seen this clipboard
> somewhere before and that it's NOT something new that the user just COPIED.
See, at this point I'm confused as to what's the point. In this case, there is no guarantee I can avoid reading the clipboard.
> IMO, a clipboard recorder is meant to preserve the clips a user has
> _created_ (i.e. mainly with the Copy command), so that he can later re-visit
> and recover them. A clipboard that a user picks from such a recording
> history is NOT a new clip in this sense, and this situation should be marked
> in the clipboard accordingly, and therefore I proposed the new type.
OK, well, clearly I have a different view on this, and unless we can reconcile what we mean by a "clipboard history", I'm not sure we can come up with a useful specification for any of these flavours. At best we can try to identify them and leave it up to the history apps to choose what to do, which is hardly an ideal for a specification.
To my mind, if a user sets the clipboard to something, whether by copying or by selecting a snippet, or a previously saved clipboard, or reading an image to the clipboard or anything else, that is now the head of the clipboard history.
The only exception I would make would be if something is placed temporarily on the clipboard solely for the purpose of immediately pasting in and then removing from the clipboard. Ideally, this would never even touch the clipboard - ideally the value would be inserted directly into the application (as I believe Text Expander does in some situations?), but since there is no practical way to say to an application "paste this specific value" except by setting the clipboard and then pasting it, we are left with this issue to solve.
What do you expect the clipboard history to do if the user elects to paste a previous value? To my mind, that value moves (or duplicates, that would be a matter of personal preference) to the head of the history. The same would be true no matter how the clipboard is set (presuming again it is not transiently set and then restored).
So unless we can get some sort of agreement on what we mean by a clipboard history and its behaviour, I think we're going to be hard pressed to produce a useful specification.
> In fact, the RestoredType is similar to the use of Keyboard Maestro's
> AutoGeneratedType - it marks the contents as something old that was put
> there not by a Copy. It's something that doesn't need saving as it can be
> recovered by other means.
Yes, see I would not be expecting to use the RestoredType for this purpose. You could use the AutoGeneratedType, which, as far as I can see is informational only, and might as well not exist. But if you're meaning for some different behaviour to happen, then that is where we disagree and that's going to be difficult to resolve.
> I also wonder: For apps that like to know if something _new_ (= copied by
> user) appears in the clipboard without keeping a history of 100s of previous
> clipboard contents, this marker will allow it to tell that this is not
> something the user just copied, and thus may not need processing. I don't
> know if such apps exist, maybe I'm unncessarily cautious here.
Again, this sounds more like what I would think of as AutoGeneratedType.
> Lastly, no one is required to interpret "RestoredType". You can still employ
> your own smart detection if you prefer (I wonder what makes you think that
> this type "break that detection."? Peter Maurer originally thought the same,
> and I didn't understand it then, either.) Adding this type is just a
> courtesy to make it easier for other tools not to require to read the entire
> clipboard data to detect dupes.
It breaks the detection unless it is actively ignored. The clipboards are no longer identical, now they differ by this flavour. The only reason it doesn't immediately lead to disaster is that the TransientType is (erroneously IMHO) also included in the newly restored value, despite it not being transient.
I'm thinking of adding code to actively exclude and ignore all org.nspasteboard.* attributes so no future ones can trip up existing code.
On 11/06/2013, at 17:41 , Thomas Tempelmann <
tho...@irradiatedsoftware.com> wrote:
>> * Do you need to distinguish clipboard restoration from other uses (such as 2a
>> and 3 above)?
>
> Yes. Several distinct cases:
> 1. User may ask to place a recorded clipping into the clipboard. In this
> case, we simply place the contents in there, with only the "RestoredType"
> marker.
Are you saying in the case where you place a saved clipboard (like a clipping or whatever you want to call it) on the clipboard, you add the RestoredType attribute? If that's the case, then I am completely at a loss as to the intended meanings of this attribute.
On 12/06/2013, at 3:26 , Brian Bucknam <
br...@smilesoftware.com> wrote:
> (Now that TextExpander includes a crash reporting facility, we see that a significant fraction of crashes occur while we are trying to read or restore the pasteboard, or while other apps are inquiring about the state of a pasteboard that we don't actually "own.")
that sounds entirely likely.
> Peter L. wrote:
> >org.nspasteboard.AutoGeneratedType: this clipboard is being put on by an application
> > for the purposes of pasting some text. The clipboard will retain this value. This value
> > should be stored on the clipboard history as it will quite possibly end up as the system
> > clipboard for some period of time. This entry should generally not affect any behaviour
> > and is informational only. Which begs the question as to why we have it at all.
>
> From the
nspasteboard.org site: @"org.nspasteboard.AutoGeneratedType": content was generated by an application; the user had no intention to Copy this content and may not expect to find it on the pasteboard.
>
> That is exactly the intention of AutoGeneratedType -- the user may not expect to see it in a clipboard history. I certainly don't want TextExpander expansions showing in my clipboard history, and I'm happy that Keyboard Maestro's clipboard function doesn't show them :-) (Of course, they're also marked TransientType, which is more likely the reason why they don't show).
Yes, I agree, my understanding of the type *as specified* is flawed. But I would content the *as specified* is more badly flawed for exactly the reason you state: if the clipboard is transient, its already marked that way.
The question is, if using a clipboard that is marked as AutoGeneratedType that is *not* marked as TransientType, what is the expect behaviour: when would a clipboard producer do this, and what is the expected behaviour of a clipboard history consumer (I like Günthers terms, but add "history" - is there any other type of "clipboard consumer" that cares about any of this?).
In Keyboard Maestro's case, as a clipboard producer, I never use TransientType as I never restore the clipboard, and I use AutoGeneratedType only in the case of Insert Text by Pasting.
As a clipboard history consumer, it is a good question as to what to do at this point. Keyboard Maestro currently would ignore it if anyone else did it (because it follows the specs better than my memory, and doesn't record entries that are marked AutoGeneratedType). However Keyboard Maestro itself doesn't ignore it because it is placed into the history when generated. And now thinking about it more deeply, I have, as stated, serious concerns about not recording a non-transient clipboard to the clipboard history, and the resulting disconnect between the head of the clipboard history and the current clipboard contents.
On 11/06/2013, at 17:41 , Thomas Tempelmann <
tho...@irradiatedsoftware.com> wrote:
> I also like to know whenever the contents are not the result of a user's
> Copy operation, e.g. if the contents are auto generated on the user's
> request. In this case, we do not want to record the data because it's not
> data the user would feel needs preserving.
See, this is where I start to get concerned about the use of AutoGeneratedType.
The serious concern I have about this is that if it is not also transient (as it never is in Keyboard Maestro) then not storing it on the clipboard history means you have a current clipboard value that does not appear in your clipboard history. So if the user looks at your clipboard history, and see the last entry is "Fred", and then the press Command-V and instead get "Generated". That seems completely broken to me. Do others disagree - see no problem in the clipboard history being out of sync with the actual contents of the clipboard?
Now, if the auto generated entry is transient, then there isn't any problem, that situation wont remain. But in that case, the clipboard entry would (also) have the TransientType attribute. Which again begs the question, what's the point in the AutoGeneratedType?
So again, I will propose the following spec:
org.nspasteboard.TransientType:
* this clipboard is being put on by an application solely for the purposes of pasting some text.
* the user had no intention to Copy this content and may not expect to find it on the pasteboard.
* the clipboard will promptly be restored to the value that was on the clipboard before the (compound) action started.
* There may be a sequence of these TransientType clipboards placed and used before the clipboard is restored.
* Its value should not be recorded in clipboard history
* the clipboard will soon be restored so that the head of the clipboard history will be restored to the clipboard.
* Ideally, clipboard history applications should not read the value of any data on the clipboard if this attribute exists.
* To facilitate not reading the clipboard data, this attribute should be placed on the clipboard before others.
* It is the responsibility of the clipboard history application to note that the restored clipboard is the same as the head already on the clipboard history and not duplicate the entry.
* Ideally it must be marked with the kPasteboardFlavorNotSaved if at all possible.
org.nspasteboard.AutoGeneratedType: [deprecated - just ignore this flavour]
* this clipboard is being put on by an application for the purposes of pasting some text.
* it should be treated the same as any other clipboard entry by clipboard history applications.
` * This entry should generally not affect any behaviour and is informational only. Which begs the question as to why we have it at all.
* If desired, the AutoGeneratedType and TransientType can both be used, assuming the clipboard is indeed transient.
* Ideally it must be marked with the kPasteboardFlavorNotSaved if at all possible.
org.nspasteboard. RestoredType:
* this clipboard is being restored from its value moments ago.
* It is otherwise identical to the clipboard as it was before a sequence of one or more TransientType are placed on the clipboard.
* To facilitate not reading the clipboard data, this attribute should be placed on the clipboard before others.
* It must never be marked as a TransientType.
* For backward compatibility, it must be marked with the kPasteboardFlavorNotSaved if at all possible.
So TransientType and RestoredType are mutually exclusive.
Sorry, this is rather long.