RE: Gnome FAQ:Cut & Paste (fwd)

[Liss Svanberg <lisss ydab se>]

In a previous letter Michael K. Fleming wrote:

> BTW, I care a great deal about the clipboard and have some opinions on 
its
> design.  I had hoped that I'd be able to start coding GNOME and helping
> the core project, but I haven't.

Same here.

> Clipboard and DnD should be combined.  I think once we get a strong
> clipboard, we should start evanglizing it so GTK apps start having "Edit"
> menus as part of the usual fare.

Of course. But the GTK uses X, and I want the clipboard to be alivable for 
all CORBA (Baboon) aware applications - not just those running under X. 
Thats why I have divided my design in a 'server' part and an GUI part. The 
GUI part should do the DnD lookalike stuff. The 'server' should be 
accessible by all code that are aware of it (even daemons - if CORBA 
objects can be handled by daemons).

> Ok, now the clipboard is *very* central to the NeXTstep OS and their
>design is very cool:
>
> 	o Typed contents (We can used MIME types)
>	o built in conversions for simple types
>	o Conversion between types can be expanded by applications
>	  installing "filters"
>	o An application can publish an item in several formats (eg EPS,
>	  TIFF), but it can do it in a lazy fashion so that it only needs
>	  to create rendered versions of the data for applications that
>	  genuinly need them in another format.

Hmm. My idea was to write a *very* simple 'clipboard server engine' which 
only does the 'store and retreive by filter' stuff.

(BTW: this is my idea. I have been working with it for a week or something 
- currently I havn't got anything that is usable by other than my test 
apps.)
Objects should be stored as data blob + attribute blob. Objects should be 
retreived in a two stage process: First you query for a number of objects 
with a filter (standard match would be last stored object) - returning a 
number of what I call 'clipboard streams'. Then you retreive the data from 
these 'streams' (so that the clipboard should be able to handle objects 
that don't fit into memory, or at least is too large to handle in one 
chunk)

CORBA objects would be passed as data (data blob) + object id (in attribute 
blob), and the retreiving app would create a new CORBA object reference 
from this id. (Possible problem: this means that a CORBA object needs 
sufficient private data stored in the clipboard to be able to recreate 
itself if the orginal object has been destroyed. If were dealing with files 
and animations, this can mean an awful lot of data!)

Of course most of this work should be hidden by some kind of clipbook 
library that applications could link to, in order to become 'clipboard 
aware'.

Is this a bad idea? If it is, I guess that I can throw my code away right 
now, because it's been build entirely upon this idea.
(Don't be shy to condemn this idea. I'd rather have it discarded now, than 
after I've finished it! :)

mvh
// Liss <rewenge of the mutant waffer bisquits>
liss@ydab.se