Re: Discontinuation of GNOME Clipboard Manager

[Philip Van Hoof <spamfrommailing freax org>]

On Tue, 2004-03-30 at 17:03, Murray Cumming wrote:


> > a) The clipboard implementation of X is not scalable enough to transfer
> > larger Clipboard data from one application to another. Look at the
> > Mozilla bug (about the 4000 bytes). It's probably both an issue in
> > Mozilla and an issue caused by the fact that actually..the mechanism is
> > just not suitable to copy-and-paste huge amounts of data. (And by huge I
> > mean: Up to 60 mb of data, why not?)
>
> So this is a performance issue? I have noticed that copy and paste of
> huge amounts of data is unusable in gnumeric too, though some visual
> feedback might help.

> Is there _any_ system on which this works? Maybe copying vast amounts of
> data is just fundamentally slow? I remember having exactly the same
> problems on Windows.

It doesn't have to be fundamentally slow. A mechanism to transfer huge
amounts of data from one application-instance to another is not 'very'
difficult to create at all. It is, however, pretty difficult to make all
applications agree on 'a' standard for this data-transfer process.

It's not because (of which I am not sure) Windows has a bad Clipboard
mechanism, that X or the Unix desktop should not try to have a better
one. I even dare to say: it's because Windows has a crap clipboard that
the Unix desktop SHOULD indeed implement a better clipboard mechanism.

After all, we are the geeks of this world, no? If we can't do it .. it
basically means that we are lazy. Not that we are incompetent.

> > b) When an application owning the clipboard shuts down, no application
> > cares about the clipboard content it is/was owning. It basically means
> > that the clipboard is lost with the application-instance. It's very hard
> > or maybe impossible to know when the application currently owning the
> > clipboard is going to be shut down (I have not tried this, yet).
>
> But a simple clipboard daemon (such as Hongli's) seems to deal with this
> quite well, in my opinion, even if it isn't a technically perfect
> solution. 


I prefer not to create yet another technically imperfect solution for
this problem. The problem should be solved at it's roots. We should not
want to create a fix on top of a problem, a patch on top of an
never-healing wound.. we should want to fix the wound, heal it. Period.


> > c) Not much applications agree upon each other clipboard formats (the
> > TARGETS Atom). Some very common formats should be agreed upon. For
> > example, every application should at least set a "TEXT" and a
> > "text/html" target.
>
> I thought that freedesktop.org was dealing with this. For instance:
> http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/
>
> I certainly think that freedesktop.org is the place for this. They have
> already greatly improved the copy/paste situation.

Indeed, and I am glad that somebody is actually worrying with me on this
one :)

> > For example: This has been fixed but even the formatting of the data
> > itself was not in sync between some applications. Some time ago
> > OpenOffice.Org used UTF-8 and Mozilla UTF-16 for the formatting (I can
> > be wrong here, I don't remember it very well). It rendered
> > copy-and-pasting text with layout between both applications impossible.
>
> I guess it would be worthwhile for someone to set up a project/web-page
> with a list of guilty applications, and the specific errors in their
> clipboard formats, in terms of open standards. That might be a first
> step to getting these data-format problems fixed. After all, they sound
> like application problems rather than platform problems.

It's not nice and even more nor easy to create such a page without
creating huge amounts of havoc and anger. I am, for sure, not a
candidate for it. However, most of the clipboard related problems are
indeed, problems in the applications. 

> > d) It is impossible to know when a change of the clipboard-ownership has
> > happened. You can only know when you loose clipboard ownership. This
> > makes it very difficult to ever create a Clipboard Manager.

> What problems does this cause in real life, for users, when using a
> simple clipboard daemon, such as hongli's?

None, except that clipboard histories and persistent clipboard data
between sessions will then always be or a horror to implement or just
plain impossible to do it correctly. Also clipboard-features like
sharing clipboards between networked computers is pretty difficult to
create. How are you going to know when you have to set new
clipboard-data on your server-type application (or send new clipboard
data to the peer) ? 

What about multiple such applications? Only one application should at
this moment be CLIPBOARD-MANAGER, else a logical endless loop would
start. But perhaps multiple clipboard-management-type applications could
run at the same time? Why not one for sharing a clipboard between a
peered network-setup and one for keeping a history of clipboards?
Perhaps it's overkill today, but will it be overkill in a new era?

The fact about this is: You cannot know that. And lets not make the same
mistakes of the past: designing while keeping in mind that hardware is
slow and stupid.

We should keep our interfaces rich and adapt our implementations to the
current hardware availability. Maybe we should not yet implement a
specific interface yet, but the possibility to implement it some day
should exist! It 'should' someday be possible! Because you nor we can
know what the users of the future want.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
work: Philip dot VanHoof at cronos dot be
http://www.freax.be, http://www.freax.eu.org