New clipboard proposal

[Philip Van Hoof]

On Sat, 2005-01-01 at 14:55 +0100, Lubos Lunak wrote:
> Dne čt 30. prosince 2004 20:21 Philip Van Hoof napsal(a):

> > o. A clipboard manager will, using the new Xfixes extensions,
> >    catch clipboards that will be lost if the selection-owner
> >    gets destroyed. That same clipboard manager will persist
> >    the clipboard when the session is about to get shutdown.
> >
> > o. Whether or not to support a clipboard history is an option or a
> >    plugin for that clipboard manager.

>  These two points are nothing new.

I hadn't yet replied on this one ;-). My reply is pretty lengthly. This
time, however, it talks more about the concept rather than the technical
implementation itself. I know, for sure, it's technically possible.

The concerns you are expressing look to me about the concept of altering
the todays clipboard mechanism of X. Such concerns are okay. So I'll
address this. (Not that the proposal means altering it. But it could
render it "unused by newer applications" indeed).

Okay. They aren't new indeed. But they have been implemented on
different desktop environments in a (for the end-user) incompatible
way. 

A GNOME desktop user will dislike installing and using Klipper just to
fix some issues with the clipboard. A KDE desktop user would most
certainly dislike using gcm for the same purpose (being it's author, a
long time ago, I discourage anybody to use gcm).

So there's a common feature which doesn't need a visible user interface
per se. Of which it's need is shared by most windowing systems. It at
least sounds like a good idea (to me) to build a windowingsystem
independent tool thats doing to job correctly. Since from then on we
have a common tool, we can also let it address other issues.

And one such issue (I repeat myself now, I know) is the transferring
speed or the fact that it's hard or impossible to asynchronously
transfer clipboard data between two applications without the need to go
to through a 3th component (the xserver, which can be running on a
different host, while often the two applications who are going to share
that data will be running on the same host).

It's possible to copy/paste a clipboard of multiple hundreds of
megabytes from one application to another. But I've noticed that doing
so will freeze both applications during the process. It even gets worse
when the xserver is running on a different location, it's basically --
for the end user -- the same as letting both applications crash. I'll
explain using an example:

Try doing this:

Create a textfile of 50 MB plaintext (UTF-8) (I an confident a textfile
of 50 megabyte is a very very common filesize for many tasks. If only
textfiles of less than a megabyte where supportable, I'd use another
Operating System which isn't using X for it's windowing and graphical
stuff. My target is to support clipboard larger than 100 megabytes in
size per format -- one target MIMEtype --).

Go to another host and startx. Login from that host from your original
host and use DISPLAY=original:0 (you know the drill). Start gedit (or
any other xclient editor) twice. So both will be using the xserver of
the computer you are using, but both will run (consume their memory and
cpu cycles) on "one" other computer.

Open the textfile. Select all, copy. Paste in the other xclient editor.

First you'll see the xclient from whom you're copying stop responding
for a few seconds (perhaps a minute depending on the converting-task).
Thats probably because the application doesn't convert it's original
format using asynchronously programming techniques (it should, this is a
lengthly process and the user isn't notified about this. The window
isn't being redrawn during the whole process!!).

Now start laughing as you suddenly feel both systems go down on their
knees while causing a full network utilisation on a 100Mbit link (tested
on my local network). I'm guessing this is the part where the data goes
over the link for the first time.

Now you'll notice the application to whom your pasting starting to stop
responding. And again it's causing a full network utilisation on a
100Mbit link for minutes. Actually, during the whole process right after
the originator stopped with not responding, network utilisation goes to
100%. Also, both the xserver and the receiver are using lots of CPU from
now on.

And the really funny thing is: in the end it works!! It's hilarious to
watch it work after really really really minutes of performing stuff,
sending data over the network, making applications stop responding for
lengthy periods.

Another funny thing is that the copypasting used a lot more time than a
secure copy from one host to another of the same file would. You must
know that secure copy is encrypting this data for it's transfer. So
copypasting is more difficult for the CPU than encrypting? Howcome? In
the end it's just a copy of data from one process to another. Nothing
difficult here.

I can assure you the common Joe Sixpack user has been trying to shutdown
both xclients. And the really funny thing is that also "that" is nearly
impossible since the xserver will get pretty slow and the xclients won't
respond to the "close window" command very fast. What did work was "Alt
+Ctrl+Backspace". 

(I like to point out that my tests where on two Fedora Core 3 hosts. Of
which have both have all packages upgraded to their very latests
versions)

While actually the only thing that happened was gedit (a process on host
a) that has send around 50 megabytes to another gedit (another process
on host a). While it had been displaying a very very small portion of
the text. Which is the "only" data of the file that ever needed to get
copied to and from the xserver (a process on host b who's best friends
are the keyboard, the mouse and the videocard) during the whole session
in the situation that I'm imagining: In case the proposal would succeed.


It would work like this:


gedit a (has 50 meg text thats copyable) -> hey xserver, I have a
clipboard!

xserver -> cool! gedit a has a clipboard! Lets tell the other xclients
about this great event!

clipboard manager -> (low voice. Like an old man). Cool, xserver tells
me gedit a has a clipboard. I'll just watch that application and if it
dies I'll use our common IPC to rescue it's data.

gedit b -> I want that clipboard. Who's owning it again? xserver?

xserver -> It's gedit a dude! go get it! Gedit a is serving it using our
common IPC. Here's the targets, which one would you like? The one with
the info about the IPC?


Situation 1 (most common, same hosts)

gedit b -> Cool. I've noticed it's on the same host as I am! I'm so
lucky! I'll use our common IPC to get it from gedit a. Gedit a, can you
please give me that clipboard using this format (gedit b has it from the
original TARGETS target or it can re-request it over the IPC of course).

gedit a -> Converting it

gedit a -> Hey gedit b! Here's my stuff

gedit b -> Receiving (over the ipc) . . .


Situation 2 (less common, different hosts)

gedit b -> Damn. Gedit a is on another host. I'll take the UTF8_STRING
mister xserver.

xserver -> Okay, letting gedit a know that it should start converting
that for you.

gedit a -> Converting it

gedit a -> Sending it to the xserver

xserver -> Sending it to gedit b

gedit b -> Receiving (over the link with the xserver) ...


.
.
.

Thats the target I'm aiming at. And I know that for common tasks it
isn't necessary. And I know that it works well, heh, fast enough if all
components are running on the same host. The thing is, however, that I'd
like to build something that would outperform todays standards.

I'm not satisfied with the current situation for the very simple reason
that it's not the most ideal solution. This type of thinking about
problems is what has driven opensource developers for years now. Right?

There's only one problem. Others must also think it's a good idea. The
people who get to decide about this aren't large in numbers. I'm
guessing most of them are for sure reading this mailinglist.

I'd like to ask them: Is this a good idea? Could it succeed? Would the
effort be worthless nomatter how perfect the resulting solution is in
itself? Do we want to fix the issues? Don't we or do we care?



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org