Hi, there is a long-standing demand for an API support for clipboard operations. Currently people use dispatch commands as a workaround but that's very tedious.
What does "API support for clipboard operation" mean? Well, IMHO it means to have a new interface that perhaps could be named css.datatransfer.XTransferableSupplier for reasons that might become clear from the following text. This interface will have: (1) A method that retrieves an object from the current "selection" (see below) that can be either inserted into the system clipboard (that already is available as a service) or kept referenced somewhere else. Such an object needs to implement the css.datatransfer.XTransferable interface. Such objects are already available for all our applications, they are used internally to feed the system clipboard service when the clipboard dispatch commands are used. (2) A second method that is able to receive such an object (that either has been retrieved from the clipboard or came from somewhere else) and hands it over to the current "selection" to do a "paste" (insert) operation. So what is the "selection"? If you have a document view and its controller it is quite obvious that this should be what you get back when you call "getSelection" on its css.view.XSelectionSupplier interface. For several reasons I wouldn't bind the new interface to the object returned from "getSelection", mainly because this can be more than one object. I would bind it to the same object that implements the SelectionSupplier, means: the Controller object. I had a first look into the Writer and Edit Engine code, implementing this in the Writer Controller object would be easy (just to soothe concerned developers ;-)). I don't see any reasons why it should be much harder in the other applications. To find an object in the core model that is suitable for a "TransferableSupplier" is not so easy and I also assume that an implementation might take more time because there is more than one object that needs to support the new interface. But IMHO that is something we can introduce later. A natural choice could be any object that is used for document navigation on the core model level (text ranges from cursors, a single shape etc.). Opinions, anyone? Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
