Re: Bonobo Clipboard, try #1

[ERDI Gergo <cactus cactus rulez org>]

Based on Michael's input, and a conversation on #gnome yesterday, here is
my next iteration.

First, my opinion about linking. I got the impression that Michael wants
to support linking only, but I disagree. Static pasting can be very
useful, and `static' doesn't only mean static on the target side, but
static on the source side as well - i. e. if I select a cell region in
Gnumeric and select Edit/Copy, then modify the region, exit Gnumeric with 
saving the changes, start it again, load up the same spread sheat and
modify the region again, I still want to get the initial data when I paste
it into another application.

Now, for a more moniker-based approach: the idea is to separate
the clipboard server and the clipboard contents storage. The clipboard
server manipulates monikers only -- a set of two monikers, one for pasting
and one for linking. The data source application is responsible for
providing (1) a pasting moniker that is guaranteed to last for the
lifetime of the clipboard contents, and (2) an optional linking moniker
that is guaranteed to be permanent. (2) is a wholly application-specific
thing (in the gnumeric example, selecting a cell region would put a
filename!sheetname!CiRj:CkCn moniker in the linking clipboard). (1) can
either be implemented in the application, or by the clipboard contents
storage, which would be basically the clipboard server from my previous
mail, i.e. the following interface:
interface ClipboardContentStorage
{
	void fetchStream (in PersistStream content_store);
	void fetchStorage (in PersistStorage content_store);
};

it would then do the state-and-IID-storing magic and then create a moniker
pointing to itself and pass this as the pasting moniker to the clipboard.

When the data target resolves the pasting moniker (which points to the
ClipboardContentStorage) the content storage resolves the stored IID for
the requested interface, QI's it for either PStorage or PStream (depending
on how the original component preferred to save itself) and fills it up
with the previously stored state.

This approach is basically Michael's
the-app-is-responsible-for-the-clipboard-data-hanging-around idea, but
with a shipped implementation to make it easier to do this. The API would
be something very simple like
	bonobo_clipboard_copy_storage  (Bonobo_PersistStorage state,
				  	Bonobo_Moniker linking_moniker);
	bonobo_clipboard_copy_stream   (Bonobo_PersistStream state,
					Bonobo_Moniker linking_moniker);
	bonobo_clipboard_copy_moniker  (Bonobo_Moniker pasting_moniker,
					Bonobo_Moniker linking_moniker);
so most apps would use #1 or #2, but the possibility is there to use #3
for more flexibility (the linking_moniker can be CORBA_OBJECT_NIL)

This cuts down the clipboard IDL to something like
	void setClipboard (in Moniker pasting_moniker,
			   in Moniker linking_moniker);
	Moniker paste ();
	Moniker link ();
but I think this could be implemented by having the Desktop Context
implement PropertyBag, and a `pasting_moniker' and `linking_moniker'
property. Setting the pasting moniker would also resolve it for PStream
and save it in text/plain to the X clipboard.

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus cactus rulez org =---'
If you don't know what's wrong with C++, try writing a C++ parser.