Name: rlT66838			Date: 05/02/2000


java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)

Right now, the standard cut, copy, and paste actions ask JTextComponent for the
last JTextComponent to have the focus, and call its appropriate cut, copy or
paste method. I need this capability in components that don't extend
JTextComponent.

For example, I've written a table, into which in which I can cut, copy and paste
a tab-delimited block of data, which is distributed across the cells. Since the
JTable doesn't (and can't) extend JTextComponent, the standard cut, copy, and
paste actions don't work on it, even though there's no reason why they
shouldn't.

I would define an interface like this:

package java.awt.datatransfer;
public interface ClipboardComponent
{
  public void cut();
  public void copy();
  public void paste();
}

(The name isn't important, but it should probably go into the datatransfer
package.)

JTextComponent should implement this interface. However, I would be free to
implement the interface in any of my components. The standard cut, copy, and
paste actions should then have a way of asking some focus manager which was the
last ClipboardComponent to have the focus  (rather than just the last
JTextComponent). This way, any of my own components that implement the interface
would automatically get access to cut, copy, and paste.

Furthermore, since the clipboard handling is done inside the cut, copy, or paste
method, this design works just as well for non-text data, such as images.

Finally, the java.awt.datatransfer package is a very useful way to describe the
different forms the transferred data may take, but it offers nothing to
determine if the focussed component is capable of receiving the data. None of
its interfaces are implemented by the JTextComponent classes or its subclasses,
so they can't be used as the needed generic interface. The Transferable
interface only describes the data, and the other two interfaces clearly don't
apply.

(There is a similar RFE, 4172946, which proposes a different solution, which I
don't like. This RFE is a clarification of an earlier RFE, 4318889, which was
closed because it didn't address the features of the datatransfer package. I
hope this RFE addresses those issues adequately.)
(Review ID: 103107) 
======================================================================