Re: Bonobo Clipboard, try #3

[Michael Meeks <michael ximian com>]

Hi Gergo,
  
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, I
thought I ought to reply, but havn't managed to read the whole thread -
sorry.

> First, my opinion about linking. I got the impression that Michael
> wants to support linking only, but I disagree.

        Not the case.

> 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
].

> 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 - and
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]

        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.

> This cuts down the clipboard IDL to something like
>       void setClipboard (in Moniker pasting_moniker,
>                          in Moniker linking_moniker);
>       Moniker paste ();
>       Moniker link ();

        This looks really nice.

> 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 ...

> 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.

        So, it's looking good to me ... code ? :-)

        Regards,

                Michael.
        
[1] - although arguably the point is rather moot since the Stream to
transfer the data would be in-proc anyway.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot