[clipboard] Linking/static pasting (was: Re: Bonobo Clipboard, try #3)

[ERDI Gergo <cactus cactus rulez org>]

On Mon, 28 May 2001, Michael Meeks wrote:

> On Wed, 23 May 2001, ERDI Gergo wrote:
> > Based on Michael's input, and a conversation on #gnome yesterday, here
> > is my next iteration.
> 
>         Just to let you know I havn't forgotten about this / you,

This possibility has never crossed my mind

> > 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 sheet and modify the region again, I     
> > still want to get the initial data when I paste it into another
> > application.
> 
>         In this scenario, if you quit without saving changes then 1 of two
> things can happen - we should pick 1 behavior.
> 
>         1. The application can revert the contents to the saved file on
>         disk, and thus retain a link
> or
>         2. The application can have some nicely complicated way of
> signaling this to the host app, so that when the app tries to serialize  
> the link it gets the contents and not just a plain moniker.
> 
>         Personaly I prefer 1. since I often discard changes in big,
> important documents before I quit - and do not wish my preference for     
> "paste as link" to be overridden by some accidental key-press in another 
> application. I also suspect that this is simpler and what MS do [ untested
> ].

I am not quite following you. My example was about pasting, and you seem
to be talking about linking. In the pasting case, I want the data target
to recieve the exact data I was selecting when clicking Copy in the data
source side. In the linking case, my selection at the time when I click
Copy only means this is the region of interest I want the data target to
recieve. So clicking Paste and Paste as Link in the data target app can
result in very different content to be pasted.

> > 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.
>
>         This sounds nice and elegant, lets expose 2 monikers though

Yes this is exactly what I meant -- both a pasting and a linking moniker.

> let the application just chose which one to resolve against eg. BonoboView
> depending on the users selection, and then just follow the same code path
> through for both - of resolution and serialization. ie. the data copying
> action happens in the client - in-proc and in-memory. ie. Paste [not as
> link] of a nice huge 'excel' data set into 'word' results in some memcpy's
> inside the 'excel' process [ that has to render the data anyway ]. [1]

Sure. 

>         Of course, for a buffer to exist after process exit we would need
> some way of signaling to the cut / paste daemon to serialize the data to
> some storage.

In case the application doesn't have its own
buffer-hangs-around-after-exit model, it can use the ClipboardStore, which
to the outside world would simply seem like putting new content to the
clipboard (because the pasting moniker changes)

> > but I think this could be implemented by having the Desktop Context   
> > implement PropertyBag, and a `pasting_moniker' and `linking_moniker'
> > property.
>         
>         This makes things rather less explicit and even less documented
> than they would be with a new interface unfortunately. Currently we don't
> have a good way of documenting bonobo property bags and the properties
> they contain ...

OK. By the way, is there documentation available somewhere on creating
singleton Bonobo components like the Clipboard would be?

> > Setting the pasting moniker would also resolve it for
> > PStream and save it in text/plain to the X clipboard.
> 
>         Ok, so we can work with the X clipboard, but this can be handled
> on demand when we get an X selection request. I agree, the main mechanism
> for handling the clipboard should be CORBA.

You are right -- the X clipboard should only be filled on request to avoid
superfluous traffic. This means it could also implement what the 
XClipboard application does, which I think would be a nice addition to the
desktop.

> Code?

Sure, as soon as I get some time in July I will create a prototype
implementation.

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus cactus rulez org =---'
Meddle not in the affairs of wizards, for <<poof>>...ribbit.