Re: Bonobo Clipboard, try #1

[Michael Meeks <michael ximian com>]

Hi Gergo,

        Firstly, thanks for putting the time in to think about this, not  
only is it a good thing to stimulate debate in this area, but you come up
with some interesting ideas.

        So, firstly here is a suggested alternative approach:

interface Bonobo::Clipboard {
        void    setMoniker (in string moniker);
        Storage getStorage ();
        Stream  getStream  ();
}

        to bear in mind as I comment; firstly I think the primary means of
doing cut and paste should be via. the Moniker mechanism for efficiency   
and speed reasons.

        Furthermore, a Moniker resolution maps perfectly to the task in
hand, ie. one of context - instead of trying to figure out what component
handles x-application/gnumeric-cell-range or whatever [1] you just ask for
the control interface...

> 4, What it does and doesn't solve
> I was careful to come up with requirements this solution solves:) You
> may think it is a lot heavier than storing a stringified moniker on
> the clipboard
   
        :-) You got me started thinking about the requirements which is
excellent, and I'm not somewhat less convinced that the problem is as hard
as I thought it was initialy :-)
                
> I can't really think of a way to represent temporary but
> somewhat-persistent data in a moniker. Sure, if the document you're
> copying from is saved somewhere (for example, it is a cell region in a 
> saved Gnumeric sheet), it is very easy to come up with a stringifyable
> moniker pointing to it, which the data target could read from the X
> clipboard and then resolve to the PersistStream interface,

        Yes, sure - and this is ideal - it is a link.
 
> but what if the user modifies the spread sheet
 
        By the miracle of linking, we want all the linked versions to
change - so this is no problem - assuming that we can get all gnumeric's
to launch new views of the same spreadsheet when asked to load a
spreadsheet - NB. this probably has some interesting issues with shared
storage - but they are for another day.
  
> selects some cells from it, modifies them, and then copies them to the
> clipboard, then exits Gnumeric without saving
 
        Ok, this is an interesting question - I think the answer has to be
that when you quit the applicaiton [ without saving 'are you sure' <Yes> ]
then gnumeric doesn't really quit [ agreed ? ], since it is still
rendering the linked version. At this point gnumeric has to revert the
changes back to the last saved state - and thus magicaly you see the
correct thing in any linked views.

        Yes, yes I know I'm just foisting the problem off onto the poor
application developer - but frankly that's where it belongs :-)
        
        So, there's just 1 final issue - why have a clipboard process -  

        Firstly it would be tempting not to, and just stringify various
monikers to the X clipboard, _however_ this may have issues, since when
some other app copies, it overwrites our stringified moniker but doesn't
unref the implementation.
        
        Secondly, if we have the moniker stored there, we can also hand
out Streams and Storages in order to seralize unsaved documents to allow
pastage without having first saved the file.

> What about Storages? Well, if your component can only store itself
> fully in a storage, it should serialize this storage into an EFS
> stream -- this should be implemented in the libbonobo storage
> providers I think (i.e. a Storage implementation should also be a
> PersistStream implementation).

        There should be no problem with implementing an in-memory storage,
and certainly apps that can handle compound documents should really be
seralizing to Storages anyway - ie. gnumeric serailizes to a storage,
creating sub-storages / streams for its sub components.

        We just need to write an in-memory storage implementation, I'll
add this to the gnome-love todo, just to cheer them up.
   
> Linking to unsaved data is meaningless, so I think this is a problem 
> monikers could solve 100%.

        I think this is a problem that monikers 100% don't solve :-) ie. I
do:

                create new sheet
                A1 = 3,
                copy A1
                A1 = 5

        paste A1 elsewhere, and I want to see '3', not get a moniker that
resolves to '5' :-)

> OK this is your `Random Bonobo toughts of the day from Cactus' for
> Tuesday. You can get back to your regular life now:)

        Stimulating thoughts, good input - what do you think of my
alternative ?

        Regards,

                Michael.
 
[1] - I have no clue how mime types are formed, or made up.

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