Re: Unbreaking the gnome clipboard

[Philip Van Hoof <spamfrommailing freax org>]

Jody Goldberg wrote:

> The damn thing regularly screws Gnumeric to hell due to its
> overeager harvesting of content.  Anytime a KDE user files a
> clipboard related bug I can be fairly sure that the answer is to
> disable Klipper.   To be at all useful, a clipboard manager
> absolutely must handle

>    - not harvesting large selections
> 	eg someone does a 'select all' in gnumeric and does not not
> 	   immediately try to send 20 meg of xml to a clipboard manger.
>  
For such very large selections a Bonobo implementation like gClipboard 
should be introduced. Thats why I replied about gClipboard in this 
thread. A Clipboard Manager could handle larger clipboards but it's not 
the perfect tool for it. However, implementing a Bonobo Clipboard would 
mean that only GNOME (and Gtk+) applications will have support for it 
(because Happy Hippo people that don't want to work together dislike 
Bonobo and bla and bla and bla -you know the story: those are the ones 
that are making sure the Linux desktop will fail-)

IMHO a successful implementation would be to use the Bonobo interface 
for GNOME -and Gtk+ applications and introduce a Clipboard Manager to 
convert the clipboards of KDE -and other xlib applications to the Bonobo 
clipboard (like gClipboard). GNOME -and Gtk+ applications could then use 
a good medium to transfer large clipboard data to eachother and/or to 
their threads. For example in stead of using a selfish internally used 
medium like Mozilla, The GIMP and OpenOffice.org do .. such applications 
would use the Bonobo interface. All the non-adapted applications or 
applications that are not using GtkClipboard would have to go through 
that Clipboard Manager. This Clipboard Manager, knowing about both the 
Bonobo medium and the standard X medium (using CLIPBOARD, PRIMARY and 
SECONDARY), will transfer the clipboard of such applications to the 
Bonobo medium and the simple targets from the Bonobo medium to the 
standard X medium.

Note that you can also replace "Bonobo" with "Any other technology that 
can be used for this".

Or .. the clipboard will be broken for ever I guess (Note that this is 
probably how it will be).

>    - multiple representations
> 	eg the clipboard manger does not just suck in gnumeric's xml
> 	  format (our prefered form) when client applications actually
> 	  want xhtml, or OO style xml.
>
>  
GNOME Clipboard Manager will at this moment handle "any" format. 
Including compressed targets (like OpenOffice.org's targets) and 
text/html or text/xml (like Gnummeric). GNOME Clipboard Manager will 
also store "any" format in XML between sessions by UUEncoding the data. 
I have tested GNOME Clipboard Manager with large selections in 
OpenOffice.org. Mozillas Composer, however, chokes on +4000 bytes of 
clipboard data that is not being transfered internally (so from Mozilla 
Browser to Mozilla Composer it works; but from "Text Editor Abc" to 
Mozilla Composer you can forget it).


So to make this long story short : The Clipboard will be broken for ever 
and Clipboard Manager handles all formats and is not the application 
that fails on larger clipboard-data.

--
Philip Van Hoof