Re: GNOME Clipboard Manager status.

[Philip Van Hoof <spam pvanhoof be>]

Hey Jonay,

I forwarded your question to some of the gtk/gnome application
development mailing lists.


On Fri, 2005-08-19 at 10:35 +0200, Jonay Gomez wrote:
> Philip Van Hoof <pvanhoof gnome org> wrote:
> > On Fri, 2005-08-19 at 06:17 +0200, Jonay Gomez wrote:
> >
> > > What are we the users to expect from GCM in the future?
> >
> > The project is discontinued (since three years now) because it solves
> > a problem in the wrong way.

> Thanks for your answer.

> I don't know about the software design point of view, or the GNOME
> infrastructure point of view.

> As a user, I can say GCM's user interface is extremely useful to me,
> and the functionality it provides "to the user" is unmatched (in fact,
> other than xclipboard, which cannot handle UTF-8 nor has scrollbars for
> long text, etc., and uses the ugly plain X libraries for its "widgets",
> there is no alternative).

> I was using xclipboard until recently, but GCM is better because it
> supports UTF-8 and you can scroll when you clip a long text, and has
> more functionality in general (and it consumes 10 times the memory, but
> I am more than willing to trade that memory for the extra functionality).

> What is going to be the supported alternative "in the right way" for
> GNOME regarding an applet to manage several clipboard selections?

By answering this question and putting some mailing lists in CC, I
forwarded the question to some of the desktop application development
mailing lists.

(for clipboard developers: I'm calling a TARGET a "format" in this
E-mail to a desktop "user". "TARGET" is way to cryptic)

Storing the clipboard in a "history" or "shelve" is not the correct
solution because the format of the clipboard can be "generated on the
fly" by an algorithm deployed in the application that "gives" the
clipboard to another application that "requests" it. Often such
"clipboard owning" applications implement a lot such algorithms.  A
spreadsheet application can, for example, implement algorithms that can
generate the clipboard in XML, Plain text, XHTML, comma separated value
and possibly also a binary format only the authors of that software know
about.

OpenOffice.org has such specialized formats. They are publicised and
well known, but only the OpenOffice.org components deals with such
clipboard formats.

The application "Klipper" (on KDE) solves the problem of storing
clipboards incorrectly. In fact it shouldn't store the clipboards on a
shelve for later usage. An application can't solve this, a standard
might solve it. What we need is a standard for a (few) common clipboard
formats, or a macro language for it (like xslt).

If Klipper (or GCM) would like to store the clipboard of OpenOffice.org,
it would in essence have to store ALL available formats. Not the
algorithms but a "copy" of the available formats. This is an insane
waste of memory resources and will cause an incredible amount of inter
process communication using X (And the Xserver might be running on a
different computer on the network, so all data goes over the tcp/ip
link).

You can read more about it in a blog from Sven, the maintainer of The
GIMP. They finally implemented the clipboard of The GIMP correctly!
Klipper made sure their STANDARD and CORRECT implementation is
incompatible with KDE.

http://svenfoo.geekheim.de/index.php/2005-06-18/why-klipper-is-bad/

I stopped GNOME Clipboard Manager because I realized that we need a
standard, not just a piece of shit application (like Klipper or GNOME
Clipboard Manager: Yes I just said that).

The problem is that there's no real standard for clipboard formats.

> Thank you very much for your attention.

These references will give you some more information about all this:

http://www.pvanhoof.be/files/Problems%20of%20the%20X11%20clipboard.pdf

http://pvanhoof.be/blog/index.php/2005/05/24/29-combatting-the-many-x11-clipboard-issues
http://pvanhoof.be/blog/index.php/2005/05/25/31-the-save_targets-atom

http://mail.gnome.org/archives/gnome-devel-list/2004-March/msg00046.html


Short version of this E-Mail: Ad hoc solutions, like Klipper and GCM,
are not the solution.


-- 
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be