Community
Participate
Working Groups
Would it be possible to have a clipboard listener interface that can be notified of clipboard put and get events just before the action take place? This would allow people to write extensions to the clipboard, such as mulit-item clipboards.
VI to investigate and advise.
Looking for clarification: Listener for get events: Do you mean a deferred mechanism for setting the data on the clipboard? That is, the source of the data does not actually provide the data until some target requests it? Note that you can already put multiple items on the Clipboard (call setContents with more than one data type in the array) - the deferring of the request for data will not change this. You will still have to inform the clipboard ahead of time of what types of data you are going to provide. Are you looking for the ability to put multiple items of the same type? How would you know which one the target was interested in? Listener for put events: Do you mean notification each time a new data type is added to the Clipboard? Please provide a scenario of how this mechanism would be used.
What I am basically trying to do is to add a view to eclipse that shows a list of clipboard contents. Each time an item is added to the clipboard, I want it to be added to my view. I can then select which of these items is pasted using the normal paste function, giving multi-clipboard support throughout Eclipse.
Any updates on the possibility of this? I'm told it's fairly commonplace in competing platforms. As mentioned in comment 3, I want to know when data is put onto the clipboard so I can reuse it later. This means both the Object[] and Transfer[] arrays sent into setContents(). Would this be possible for 3.1?
The GEF team is also interested in receiving notification when something is put on the clipboard. This will allow us to update the Paste action's enablement properly.
It is not be possible to implement this for UNIX on X servers without XFixes support. http://www.freedesktop.org/Software/FixesExt However, we currently have a lot of problems where views update their state too often, causing performance problems and hangs on Linux (see bug 84870 and bug 78450, for example). A good solution for platforms where notification is not available is to simply make paste always enabled. If we had notification where supported, and a flag when not supported, we could implement this workaround on Linux in a clean way.
Notification is supported on Windows through SetClipboardViewer. Notification does not appear to be supported on Mac OS X - I have checked both Scrap Manager and Pasteboard Manager and have found no callback mechanism.
*** Bug 204659 has been marked as a duplicate of this bug. ***
FYI Mac/Cocoa doesn't appear to support a system-wide notification of when the clipboard has changed with another application. However, it does support a means of finding out if the clipboard has changed since the last time, so when the application receives focus, it might be possible to broadcast an event in SWT then. But you'd only get it when the SWT app received the focus back; it wouldn't happen immediately.
For the purpose of implementing a multi item clipboard there's no need for a listener (even though this would be a nice thing to have), the only thing needed is a way to know when a specific item was added to the clipboard. So there's no need to even add a listener that is notified when focus is regained, but simply supply a mechanism to check the time-stamp of the last item added to the clipboard. This way, instead of changing the active item in the multi-item clipboard when an event occurs, we can change it just before a paste is done.
> a mechanism to check the time-stamp of the last item Will you poll then?
(In reply to comment #11) > > Will you poll then? > Well, what I had in mind was a clipboard with an array of elements instead of one, and an index to this array that will point to the item that is going to be pasted. Whenever the user copies/cuts something, it enters the array and the index is set to point to it. A view of some sort will be given to the user in which he/she will be able to select the item the index points to. The idea is that if the user doesn't manually change the index, the mechanism should act and feel like a regular clipboard. My problem started when I realized that I cannot implement my own clipboard in conjunction with the system clipboard. If I use the system clipboard, I have no control of what will be pasted. On the other hand, if I implement my own clipboard I cannot synchronize it with the system clipboard. What I want to do is to create a class that has the functionality described above, i.e. it checks the system clipboard before paste (or before showing the view) and can tell whether a copy to the system clipboard has occurred after the selection of the item to paste (in which case the user would expect the item from the system clipboard to be pasted). Having said that, if adding a listener was an option, this would make things a lot easier, since I could listen to the system clipboard and set the active item to the system clipboard's item every time its being updated (no checks,tests etc.).
I have another use case for this. I'm investigating a performance issue related to pasting clipboard contents. For example, when there are several MB text data stored on the clipboard, calling Clipboard.getContents (TextTransfer) spends takes a while. My first thought to address it was to cache this data so we don't need to hit getContents if there's a cache hit, and to clear the cache when the clipboard data changes. What I've found though is that neither Java or SWT provides an API to do so - the closest is to use the AWT Clipboard and FlavorListener introduced in Java 5. (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4259272). However, this only notifies when content type changes, not the content itself. My next thought was to use some combination of window activation and funnelling all SWT Clipboard requests so that the cache would be cleared in those cases - however, it turns out not all widgets implement "copy" by going through the SWT clipboard - objects like the Text widget implement it by calling the OS directly... Another idea was to poll the clipboard on a background thread, but alas the SWT Clipboard can only be used on the Display thread... Upon further investigation, it seems that Windows does provide this notification, and the reason that it isn't provided in Java is because it's not provided on all platforms. This is where I think SWT can provide a solution: One of the original suggestions for the AWT bug was to provide a "Clipboard.areContentsChangeNotificationsSupported()" type function, to which content change listeners can be added. To be most useful, this type of listening should be able to be attached independent of the Clipboard object itself. Thoughts?
I was looking for this too when trying to add feature to Java Stacktrace Console to popup to the front when the clipboard contained something that looked like a stacktrace and let the user easily access it. Any chance of this making it into SWT ?
