Re: Unbreaking the gnome clipboard

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]